The overall architecture of Dubbo is shown below:
The Dubbo framework design is divided into 10 layers, with the Service layer at the top being the interface layer for business logic to be implemented by 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:
Service interface layer: This layer is related to the actual business logic and designs corresponding interfaces and implementations according to the business of Service providers and Service consumers. Configuration layer (Config) : external configuration interface, centering on ServiceConfig and ReferenceConfig, can directly new configuration classes, or generate configuration classes through Spring configuration parsing.
Proxy layer: transparent Proxy of service interface, generating client Stub and server Skeleton of service, centered on ServiceProxy, and ProxyFactory as extension interface.
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.
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.
Monitoring layer (Monitor) : Monitors the number and time of RPC calls. It centers on Statistics and extends interfaces to MonitorFactory, Monitor, and MonitorService.
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.
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.
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.
Serialize: Reusable tools with Serialization, ObjectInput, ObjectOutput, and ThreadPool extensions. 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.
As a distributed service framework, Dubbo mainly has the following core points:
Service definition A service revolves around a service provider and a service consumer, who implements the service and a service consumer invokes the service.
Service registration service providers, which need to publish services, and due to the complexity of the application system, the number and type of services are expanding; For the service consumer, it is most concerned about how to obtain the services it needs, but in the face of complex application system, it needs to manage a large number of service calls. Moreover, for service providers and service consumers, they may play both roles, that is, they need to provide services and they need to consume services.
By unifying the management of services, internal applications can effectively optimize the process and management of service publication/use. Service registries can unify services externally through specific protocols. Dubbo provides several types of registries to choose from:
Multicast registries Zookeeper registries Redis registries Monitors Simple registries
Both service providers and service consumers need to effectively monitor the actual state of service invocations to improve the quality of service.
Telecommunication and information exchange
In remote communication, it is necessary to specify the protocol agreed by both communication parties, and ensure efficient and stable message transmission on the basis of ensuring that both communication parties understand the semantics of the protocol. Dubbo inherits the current mainstream network communication framework, which mainly includes the following:
Mina Netty Grizzly service call
The following is directly taken from Dubbo’s official website to look at the invocation relationship between service providers and service consumers based on RPC layer, as shown in the figure:
Node roles:
Provider: exposes the service Provider of the service.
Consumer: Service Consumer that invokes the remote service.
Registry: A Registry where services are registered and discovered.
Monitor: monitors The Times and time of service invocation.
Container: service running Container.
In the figure above, the blue ones represent interactions with the business, and the green ones represent interactions only with Dubbo internally. The above figure describes the call flow as follows:
The service container is responsible for starting, loading, and running the service provider. At startup, service providers register their services with the registry. At startup, service consumers subscribe to the registry for the services they need. 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, from the provider address list, selects one provider to call based on the soft load balancing algorithm. If the call fails, selects another one to call. Service consumers and providers accumulate calls and call times in memory and regularly send statistics to the monitoring center every minute. Then, expand the above abstract call flow chart, as shown in the figure:
Register/deregister services
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:
Service subscription/cancellation To meet the needs of the application system, a service consumer 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.