In my previous interview experience, in addition to being often asked about HTTP related knowledge, I was also asked about the difference between HTTP and RPC. In addition, I often deal with some DSF applications of the company in my work, and then I think of Dubbo, so the keywords to be combed today are: HTTP, RPC, DSF, dubbo.

HTTP and RPC

First of all, the question of how HTTP differs from RPC is a bit of a loose end, since the two are not on the same level.

HTTP

Is this familiar to you? I am afraid that the most common HTTP protocol interface.

Yes, HTTP is a protocol.

Other here is not going to spread out, before sorting out some content, there is a need to jump to look at:

  • HTTP introduction, TCP/IP protocol family
  • Two, IP, TCP and DNS, three handshake
  • Three, HTTP protocol basis, four wave
  • Four, HTTP disadvantages
  • Introduction to encryption and certificates in HTTPS, and the reason why HTTPS is not always used

RPC

RPC is a synonym for remote procedure call.

The remote? Is there a local procedure call as well?

That’s right. Here’s an example:

  • Local procedure call: when A service A is started on your computer, the various methods in service A are called to each other when the program is run.
  • Remote procedure call: and next door xiao Wang also started a service B, he also said that he provided a very powerful function of the method, you also want to call, this is remote.

And as for how you call the method in xiao Wang’s server, that is an implementation of the problem. You can just go HTTP for simplicity. If HTTP does not meet the requirements, you can also customize a protocol based on TCP.

Remote call procedure

The remote call process should look something like this:

Second, the DSF

In my work, I found that the company has many applications whose names start with DSF. DSF (Distributed Service Framework) actually refers to Distributed Service Framework.

Two brief points: why use the distributed, DSF package.

Why distribute

Why use distributed services? Another way to ask this question is: what problem does distribution solve?

First of all, distributed architecture evolved from single architecture, and our business system is no exception. In the early stage of a business, in order to reduce the development cost and achieve rapid launch, a single architecture is usually used, and all business modules are in the same application.

As the scale of the business expands, the disadvantages of individual applications are exposed, such as:

  • System coupling is high. When more and more functions are added later and the amount of code increases greatly, the module boundary demarcated in the mind of a main program may become more and more fuzzy, leading to confusion in the call relationship.
  • There are more and more changes in one to give two, often there is a change in the development of a feature, and lead to problems with other features.
  • If one function fails, the whole thing rolls back.
  • Single language, can not choose a more appropriate language according to the scene. For example, there is a module system focused on big data analysis, which is more appropriate in Python because it has a rich class library.
  • The system is not easy to expand deployment, for example, there is a function in the system traffic is heavy, can not withstand the machine, then deploy the whole application on the new machine, can not independently deploy the heavy traffic service, will cause a certain waste of resources.

.

To solve these problems, the former business was split vertically into multiple systems. Each system processes services through network interaction. Each system is independent of each other and can be deployed independently. This form of multiple components cooperating to provide services is called distribution.

But distribution also has its drawbacks:

  • Instead of single application invocation, multiple applications now interact directly. The invocation link becomes longer, bringing network overhead and increasing difficulty to locate problems.
  • To make your application more reliable, there are other exceptions to consider, such as call failures, high frequency calls due to certain problems, such as limiting traffic, circuit breakers and so on.
  • Problems may involve rolling back multiple services that affect each other.
  • The environment becomes more complex, increasing the complexity of testing.

.

In short, distribution helps us overcome singleton bottlenecks, but there is more to consider for the stability of distributed services.

What DSF contains

Then what are the contents of a set of distributed service platform? Here is a brief list (taking our company’s own research as an example) :

  • Service registration: the service provider uploads contract information, which includes service group information, service information, API information, etc.
  • Service discovery: Service consumer addressing where needs can be found based on some granularity.
  • Service invocation: You can customize the timeout period and retry times for synchronous and asynchronous invocation.
  • Load balancing: Such as support for polling policies.
  • Gateway: You can also make some REST API calls externally through the gateway.
  • Health check: Perform a health check on the service provider instance.
  • Service topology: Topology of upstream and downstream links for application calls.
  • Service monitoring: displays service running status and invocation indicators.
  • Alarm: When the number of abnormal instances of a service exceeds the threshold, an alarm is triggered.
  • Current limiting: Protects the system.
  • Web front Desk: convenient to view all kinds of information, a variety of common functions of the entrance.

.

Third, Dubbo

As for the distributed service framework, if you have the ability to develop it yourself, you can customize it according to the actual situation of your company’s business. If you don’t have that in the beginning, many companies will go straight to a mature open source framework, such as Dubbo.

Dubbo is a Java-based RPC framework opened by Alibaba in 2011. It implements interface-oriented proxy RPC invocation, and can cooperate with ZooKeeper and other components to realize service registration and discovery functions, and has load balancing and fault tolerance mechanisms.

Dubbo architecture

This is the architecture diagram of the official document, which describes the interaction of the Dubbo microservices component with the various centers.

  • Registry: Coordinates address registration and discovery between consumers and providers.
  • ConfigCenter: Stores global configurations during Dubbo startup to ensure cross-environment sharing and global consistency. Store and push service governance rules (routing rules, dynamic configuration, etc.).
  • Metadata Metadata center: Receives service interface Metadata reported by the Provider and provides O&M capabilities (such as service tests and interface documents) for the Admin console. Complementing the service discovery mechanism, providing additional interface/method-level configuration information synchronization capabilities is equivalent to an additional extension of the registry.

These three centers are not necessary to run Dubbo, and users can choose to enable one or more of them based on their business situation to simplify deployment. Typically, all users start Dubbo service development in a separate registry, while configuration centers and metadata centers are introduced on demand as microservices evolve.

So, if you want to quickly implement a distributed service framework, you can develop based on Dubbo’s solution, either on the fly or later.