Dubbo + zookeeper (2) Dubbo architecture


The last time I updated my blog was a year ago. A lot of things happened in this year, which was not smooth or even painful. However, don’t stop learning. Only learning can make you stronger and deal with more instability.

1、 RPC concept

Dubbo service is an RPC framework. First of all, we need to understand what RPC is. Remote procedure call is remote procedure call.

Remote procedure call is relative to local procedure call. Local procedure call, needless to say, can be simply understood as local method calling function. Remote procedure call refers to calling a procedure or function in another address space (usually on another machine sharing the network). Instead of the programmer explicitly coding the details of the remote call. That is to say, whether the programmer calls local or remote functions, the calling code is basically the same.

The basic architecture of RPC is as follows:


RPC framework is the client stub and server stub in the figure. If services need to call each other, they need to establish a connection first. When the client calls the client stub, it may need to pass parameters. When it is passed between networks, it needs to be serialized. After the serialization is complete, the message to be called is sent to the server stub. After the server receives the message, it first deserializes it, and then calls the local service. After calling the local service, it returns the processing result, and the result also needs to be serialized, After serialization, the message is returned. When the client stub receives the message, it needs to deserialize it again and convert it into the call result. This is a complete RPC process, as shown in the figure



RPC framework is to achieve the same thing as the little assistant, the purpose is to let us use the remote call as simple and convenient as the local call, and solve some problems that will occur in the remote callIt’s senseless to us.

In the example diagram, we can also see that the core module of RPC isCommunication, serialization

If we design an RPC framework, what should our design idea be?

Start with the service caller, which is aConsumer sideIf we want to consume a service, this service should be in the form of an interface. This interface is generally defined by a public jar package. When I know what interface to call, I don’t need to know the specific implementation. All these should be done by the framework agent. I just need to bring the interface and parameters.

The consumer doesn’t need to know the details, and doesn’t need to know which server to call. There should be one at this timeRegistryThis registration center is similar to the front desk property of the company building. It is responsible for guiding the guests to find the companies in this building. Each company is similarService providerAfter the company enters the large building, it will tell the front desk its own floor and house number, and the front desk will post the company’s situation on the front desk guide. Then when someone wants to find the company to provide services, they can directly find the company they want to go to through the house number. After the company moves away, the front desk industry will remove the company, and the server consumers need can directly find the corresponding company.

Of course, if you directly tell the customer your specific location, then the customer does not need to go to the registration center to find you, that is to sayThe registry may not be required

What did you doService providerIf you want to tell others the servers your company can provide, goImplement the corresponding interfaceAnd then it’s exposed, which is where it’s goingRegister yourself in the registryTo expose the services you can provide. Then there is a consumer request that needs to be processed, and the provider needs to use and the consumerNegotiated agreementTo handle the request, and then doDeserialization

In the face of many services, fine monitoring and convenient operation and maintenance is essential. At this time, we needMonitoring operation and maintenanceThat is monitoring center. Of course, if you want to be so reckless, you don’t need to monitor. Of course, you can.

So far, this is the architecture we can think of. Next, let’s take a look at the Dubbo design (of course, I deduce it from the actual architecture, manual dog head)

2Dubbo core concepts

Dubbo is a Java based RPC framework opened by Alibaba in 2011. It has been quiet for a while, but some other enterprises are still using Dubbo and making their own extensions, such as dubbox of dangdang.com and dubbok of koala.com.

In 2018, it merged with dubbox, entered the Apache incubator, and officially became the top project of Apache in 2019.

Learn a technology. If there is an official website, we will try our best to learn from it:http://dubbo.apache.org/

First, we need to know what features Dubbo has

  • High performance RPC call for interface proxy: it provides high-performance remote call capability based on proxy, and the service takes interface as granularity to shield developers from the underlying details of remote call.

  • Intelligent load balancing: a variety of built-in load balancing strategies can intelligently sense the health status of downstream nodes, significantly reduce call delay and improve system throughput.

  • Automatic service registration and discovery: support a variety of registry services, real-time perception of service instances online and offline.

  • Highly scalable: following the design principle of microkernel + plug-in, all core capabilities such as protocol, transport and serialization are designed as extension points, and the built-in implementation and third-party implementation are treated equally.

  • Run time traffic scheduling: built in conditions, scripts and other routing strategies, through the configuration of different routing rules, easy to achieve gray publishing, the same room priority and other functions.

  • Visual service governance and operation and maintenance: provide rich service governance and operation and maintenance tools: query service metadata, service health status and call statistics at any time, issue routing policies and adjust configuration parameters in real time.

3Architecture diagram

Let’s take a look at the architecture diagram



The architecture is divided into five nodes

Service provider: expose the service provider of the service. When the service provider starts up, it registers its own services with the registry.

Service consumer: the service consumer that invokes the remote service. When the service consumer starts up, he / she subscribes the service he / she needs to the registry. The service consumer selects one provider from the address list of the providers based on the soft load balancing algorithm to call. If the call fails, he / she selects another one to call.

Registry: the registry returns the address list of the service provider to the consumer. If there is a change, the registry will push the change data to the consumer based on the long connection

Monitoring center: service consumers and providers, accumulate call times and call time in memory, and regularly send statistical data to the monitoring center every minute

Service run container: responsible for starting, loading and running the service provider

Their calling relations are as follows:

  1. The service container is responsible for starting, loading and running the service provider.

  2. The service container is responsible for starting, loading and running the service provider.

  3. When service consumers start, they subscribe to the service they need from the registry.

  4. The registry returns the address list of the service provider to the consumer. If there is a change, the registry will push the change data to the consumer based on the long connection.

  5. Service consumers, from the address list of providers, select one provider to call based on soft load balancing algorithm. If the call fails, select another one to call.

  6. Service consumers and providers accumulate call times and call time in memory, and regularly send statistical data to the monitoring center every minute.

The architecture of Dubbo is very clear and easy to understand. When we study, we first understand the architecture, then learn to use it, and then go to the source code to understand the basic code structure.

4、 Characteristics

Dubbo architecture has the following characteristics: connectivity, robustness and scalability.


  • The registration center is responsible for the registration and search of service address, which is equivalent to directory service. Service providers and consumers only interact with the registration center at startup, and the registration center does not forward requests, so the pressure is less

  • The monitoring center is responsible for the statistics of the times and time of each service call. The statistics are first summarized in the memory and then sent to the monitoring center server once a minute, and displayed in a report

  • The service provider registers its services with the registry and reports the call time to the monitoring center, which does not include the network overhead

  • The service consumer obtains the address list of the service provider from the registration center, calls the provider directly according to the load algorithm, and reports the call time to the monitoring center, which includes the network overhead

  • Registration Center, service provider and service consumer are all long-term connections, except monitoring center

  • When the service provider is down, the registry will immediately push the event to inform consumers

  • The registration center and monitoring center are all down, and the running providers and consumers are not affected. The consumers cache the list of providers locally

  • Registration center and monitoring center are optional, and service consumers can directly connect with service providers


  • The failure of the monitoring center does not affect the use, but only part of the sampling data is lost

  • After the database is down, the registry can still provide service list query through cache, but can not register new services

  • Register center peer-to-peer cluster, after any one is down, it will automatically switch to another

  • After all the registries are down, service providers and service consumers can still communicate through local cache

  • The service provider is stateless, and the use of any service provider will not be affected when it is down

  • After all service providers are down, the service consumer application will not be able to use, and will be reconnected indefinitely, waiting for the service provider to recover


  • The registration center is a peer-to-peer cluster, which can dynamically add machine deployment instances, and all clients will automatically find new registration centers

  • The service provider is stateless and can dynamically add machine deployment instances. The registry will push new service provider information to consumers

Now that we have a basic understanding of Dubbo architecture, let’s start the development of practical examples.