1 Dubbo core functions

1. Remoting: Provides abstract encapsulation of various NIO frameworks, including synchronous to asynchronous and request-response information exchange modes.
2. Cluster: Service framework that provides transparent remote procedure calls based on interface methods, including multi-protocol support, and Cluster support for soft load balancing, failure tolerance, address routing, and dynamic configuration.
3. Registry: service Registry, based on the Registry directory service, so that service consumers can dynamically find service providers, so that the address is transparent, so that service providers can smoothly add or subtract machines.

For these three core functions, what component roles are involved in Dubbo to collaborate on distributed governance?

2 Dubbo component role

Call relationship description:

• The Service Container is responsible for starting, loading, and running the service provider.
• The service Provider registers its services with the registry at startup.
• At startup, a service Consumer subscribes to the registry for the services it needs.
• The Registry returns a list of service provider addresses to the consumer, and if there are changes, the Registry pushes the change data to the consumer based on the long connection.
• The service Consumer selects one provider from the provider address list to call based on the soft load balancing algorithm. If the call fails, it selects another one to call.
• The service Consumer and Provider accumulate call times and call time in memory, and regularly send statistical data to Monitor every minute.

3 Overall Architecture of Dubbo

The main feature of Dubbo is that it is architected in a hierarchical manner, which can be decoupled (or maximally decoupled) from each other. So, let’s look at Dubbo’s architecture horizontally and hierarchically, as shown in the figure below:

The Dubbo framework design is divided into 10 layers, with the Service layer at the top being the interface layer for implementing business logic for developers who actually want to develop distributed services using Dubbo. In the figure, the interfaces used by the service consumer on the left with a light blue background, the interfaces used by the service provider on the right with a light green background, and the interfaces used by both parties on the central axis.

Below, based on the official Dubbo document, we understand the design key points of each level in the framework layered architecture:

1. Service interface layer: Related to the actual business logic, according to the Service provider and Service consumer business design corresponding interface and implementation.
2. Configuration layer (Config) : external configuration interface, centering on ServiceConfig and ReferenceConfig, can directly new configuration classes, or generate configuration classes through Spring configuration parsing.
3. Proxy layer: transparent Proxy of service interface, generating client Stub and server Skeleton of service, centered on ServiceProxy, and ProxyFactory as extension interface.
4. Service Registration layer (Registry) : encapsulates the registration and discovery of service addresses. It is centered on service URLS and extends the interfaces to RegistryFactory, Registry and RegistryService. There may be no service registry, in which case the service provider directly exposes the service.
5. Cluster layer (Cluster) : encapsulates routing and load balancing of multiple providers, Bridges registries, centers on Invoker, and extends interfaces to Cluster, Directory, Router, and LoadBalance. Multiple service providers are combined into a single service provider to achieve transparency to the service consumer and interact with only one service provider.
6. Monitoring layer (Monitor) : Monitors the number and time of RPC calls. It centers on Statistics and extends interfaces to MonitorFactory, Monitor, and MonitorService.
7. Remote Invocation layer (Protocol) : Dispatcher RPC calls with Protocol, Invoker and Exporter interfaces centered on Invocation and Result. Protocol is the service domain, which is the main functional entry for Invoker exposure and references, and is responsible for the lifecycle management of Invoker. Invoker is the entity domain that is the core model of Dubbo, to which all other models rely or turn. It represents an executable to which invoke calls can be made. It may be a local implementation, a remote implementation, or a cluster implementation.
8. Exchange: Encapsulates the Request and Response mode, and turns it into async. It uses Request and Response as the center and uses Exchange channel, ExchangeClient and ExchangeServer as the expansion interface.
9. Network Transport Layer (Transport) : Abstract MINA and Netty as the unified interface, Message as the center, extended interfaces are Channel, Transporter, Client, Server and Codec.
10. Serialize: Reusable tools with Serialization, ObjectInput, ObjectOutput, and ThreadPool extensions.

As can be seen from the figure above, Dubbo provides service providers and service consumers with interfaces that need to be cared for and extended from the 10 layers of the framework to build the entire service ecosystem (service providers and service consumers are themselves service-oriented).

According to the official description of the relationship between the above layers, it is as follows:

• In RPC, Protocol is the core layer, which means that as long as you have Protocol + Invoker + Exporter, you can perform non-transparent RPC calls and Filter interception points on the main process of Invoker.
• Consumer and Provider in the figure are abstract concepts, which are intended to give viewers a more intuitive understanding of which classes belong to the client side and server side. The reason for not using Client and Server is that Dubbo uses Provider, Consumer, Registry, and Monitor to divide logical topology nodes in many scenarios to maintain a uniform concept.
• Cluster is a peripheral concept, so the purpose of Cluster is to disguise multiple invokers as one Invoker, so that other people only need to pay attention to the Protocol layer Invoker, adding or removing the Cluster will not affect other layers. Because a Cluster is not required when there is only one provider.
• Proxy layer encapsulates transparent Proxy of all interfaces, while other layers are Invoker centered. Only when exposed to users, Proxy can be used to convert Invoker into interface or interface implementation into Invoker. In other words, RPC can Run without Proxy layer, but it is not so transparent. It doesn’t look like calling a remote service is calling a local service.
• Remoting is an implementation of the Dubbo protocol. If you choose RMI, the entire Remoting protocol will not be used. Remoting is divided into Transport layer and Exchange layer, Transport layer is only responsible for one-way message transmission. An abstraction from Mina, Netty and Grizzly, it can also extend UDP transport, while the Exchange layer encapsulates request-Response semantics on top of the transport layer.
• Registry and Monitor are not really one layer, but rather a separate node, drawn together in layers for a global overview.

4 Service Invocation Process

5 Register/deregister the service

Service registration and deregistration are for the role of the service provider, so the sequence diagram of service registration and deregistration is shown as follows:

6 Subscribe/cancel the service

To meet the needs of the application system, the consumer of a service may need to subscribe to a specified service published by a service provider from a service registry and invoke the service directly when notified that it is available. Conversely, if a service is no longer needed, you can cancel it. Take a look at the corresponding sequence diagram, as shown in the figure below: