Dubbo source code analysis-overall introduction and module division

Dubbo frame design introduction 

Introduction

Dubbo is a high-performance and excellent service framework open sourced by Alibaba. It enables applications to realize service output and input functions through high-performance RPC , and can be seamlessly integrated with the Spring framework. It provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing , and automatic service registration and discovery . I believe that there are still many Internet companies that use dubbo in China. Although springcloud is linked to the famous spring team Pivotal  , it feels that domestic companies do not use dubbo as much, and now dubbo has restarted maintenance and donated to the apache fund Yes, the future development prospects are also bright. The difference between dubbo and springcloud and their respective advantages and disadvantages can be found in this comparison of Dubbo and Spring Cloud microservice architecture . I feel that the analysis is still in place. In general, it can be summarized as that the microservice concepts and components covered by springcloud are more extensive and are a complete set of solutions; while dubbo only completes some of the core functions of microservices, but both have their own In terms of the specific framework, the benevolent sees the benevolent and the wise.

Overall design

The overall design of dubbo also deeply implements the idea of layered design , with each layer performing its own duties. Misappropriating a picture from the official website:

Layering is an important concept. Just like in web application development, ssh, ssm architecture.

It is to abstract the tasks or functions of each layer from the whole, and then do their own, so that their internal affairs can be digested internally without affecting other external layers, and the entire system will become maintainable and easy understanding. Then analyze this picture

Official website legend description:

• The light blue background on the left is the interface used by the service consumer, the light green background on the right is the interface used by the service provider, and the interface on the central axis is the interface used by both parties.
• The figure is divided into ten layers from bottom to top. Each layer is one-way dependent. The black arrow on the right represents the dependency between the layers. Each layer can be stripped of the upper layer and reused. Among them, the Service and Config layers are APIs. All other layers are SPI. (The SPI mechanism is at the core of Dubbo, and Dubbo will show the best of SPI)
• The green blocks in the figure are extended interfaces, and the blue blocks are implementation classes. The figure only shows the implementation classes used to associate each layer.
• In the figure, the blue dotted line is the initialization process, that is, the assembly chain at startup, the red solid line is the method call process, that is the runtime timing chain, and the purple triangle arrow is the inheritance. The subclass can be regarded as the same node of the parent class. The text above is the method to be called.

Description of each layer

• service Service layer : This layer is written by the user, whether it is the service interface or the service realization. It can be seen from the overall design drawing that the interface is used by both the provider and the consumer, and the implementation is only on the provider and not exposed to the consumer. This is also in line with our usual usage cognition. The service provider separates the interface into a jar package for the consumer to use.

• config configuration layer : External configuration interface, with ServiceConfig and ReferenceConfig as the center, can directly initialize configuration classes, or generate configuration classes through spring analysis. Dubbo-config contains two sub-modules, config-api and config-spring, which correspond to the two configuration generation methods respectively. The configuration class contains information such as protocol and url, which is a relatively heavy object.

• Proxy service proxy layer : transparent proxy service interface, generating service client Stub and server side Skeleton, centered on ServiceProxy, and extended interface as ProxyFactory. As you can see from the overall design drawing, Invoker is actually an agent responsible for invoking the real service of the service provider, while Proxy is an agent responsible for invoking the provider's service on the consumer side.

• Registry registration center layer : Encapsulates the registration and discovery of service addresses, centered on the service URL, and the extended interfaces are RegistryFactory, Registry, RegistryService.

• Cluster routing layer : encapsulates the routing and load balancing of multiple providers, and bridges the registry, with the Invoker as the center, and the expansion interface is Cluster, Directory, Router, LoadBalance. It is equivalent to encapsulating the cluster as a single node, so that the external can be handled like a single call, without considering the situation of the cluster (such as the situation of multiple providers)

• monitor Monitoring layer : RPC call times and call time monitoring, centered on Statistics, and extended interfaces are MonitorFactory, Monitor, MonitorService. There will be some statistics on service call information.

• Protocol remote call layer : encapsulates RPC calls, centered on Invocation and Result, and extended interfaces as Protocol, Invoker, and Exporter. For protocol encapsulation, dubbo supports multiple protocols, and the default is dubbo protocol.

• Exchange information exchange layer : encapsulates the request response mode, synchronous to asynchronous, with Request and Response as the center, and the extension interfaces are Exchanger, ExchangeChannel, ExchangeClient, and ExchangeServer.

• transport Network transport layer : abstract mina and netty as unified interfaces, with Message as the center, and extended interfaces as Channel, Transporter, Client, Server, Codec.

• serialize data serialization layer : some reusable tools, the extended interface is Serialization, ObjectInput, ObjectOutput, ThreadPool. The serialization of dubbo also supports multiple protocols.

Official website relationship description

• In RPC, Protocol is the core layer, that is, as long as there is Protocol + Invoker + Exporter, non-transparent RPC calls can be completed, and then the Filter intercept point in the main process of Invoker.

• The Consumer and Provider in the picture are abstract concepts. I just want viewers to understand more intuitively which categories belong to the client and the server. The reason why Client and Server are not used is that Dubbo uses Provider, Consumer, Registry in many scenarios. Monitor divides logical topology nodes to maintain a unified concept.

• Cluster is a peripheral concept, so the purpose of Cluster is to disguise multiple Invokers as one Invoker, so that others only need to pay attention to the Protocol layer Invoker. Adding Cluster or removing Cluster will not affect other layers because only one provides In case of this, Cluster is not required.

• The Proxy layer encapsulates the transparent proxy of all interfaces, and the Invoker is the center at other layers. Only when it is exposed to users, will the Invoker be converted into an interface by the Proxy, or the interface implementation will be converted into an Invoker, that is, to remove the Proxy Layer RPC can be run, but it is not so transparent, and it does not look like a local service to call a remote service.

• The Remoting implementation is the implementation of the Dubbo protocol. If you choose the RMI protocol, the entire Remoting will not be used. Remoting is then divided into the Transport transport layer and the Exchange information exchange layer. The Transport layer is only responsible for one-way message transmission, which is for Mina, Netty, Grizzly's abstraction, it can also extend UDP transmission, and the Exchange layer encapsulates the Request-Response semantics on top of the transport layer.

• Registry and Monitor are actually not a layer, but an independent node, just for a global overview, drawn together in a layered manner.

Module description

The module description on the official website here is now the latest version of dubbo is 2.7.8, and the modules are more detailed. The following figure shows the function of each module.

---

Dependency (role division)

 

Node role description

node	Role description
Provider	Service provider of exposed service
Consumer	Service consumer calling remote service
Registry	Registry for service registration and discovery
Monitor	Monitoring center that counts the number of service calls and call time
Container	Service running container

Call relationship description

1. The service container is responsible for starting, loading, and running the service provider
2. When the service provider starts, register the service it provides with the registry
3. When a service consumer is started, he subscribes to the registry for the service he needs.
4. The registration center returns the list of service provider addresses to the consumer. If there is a change, the registration center will push the change data to the consumer based on the long connection.
5. The service consumer, based on the soft load balancing algorithm, selects one provider to call from the provider address list, and if the call fails, selects another to call.
6. Service consumers and providers accumulate the number of calls and call time in the memory, and send statistical data to the monitoring center every minute.

origin

dubbo solves the following needs

1. When there are more and more services, service URL configuration management becomes very difficult, and the single point pressure of F5 hardware load balancer is also increasing.
2. The dependencies between services have become mistracked and complicated, and it is even difficult to distinguish which application should be started before which application
3. Service calls are getting larger and larger, and service capacity problems are exposed to  machine management, traffic control, etc.