Dubbo is an open source distributed service framework of Alibaba. Its most prominent feature is that it is structured in a hierarchical manner, which can be decoupled (or loosened as much as possible) between layers. From the perspective of the service model, Dubbo adopts a very simple model, in which either the Provider provides the service or the Consumer consumes the service, so the roles of Provider and Consumer can be abstracted based on this. Details about registries, protocol support, service monitoring, and more are described below.
The overall architecture
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 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:
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.
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.
From the architecture diagram above, we can see that Dubbo, as a distributed service framework, mainly has the following core points:
The service definition
A service revolves around a service provider and a service consumer, who implements the service and a service consumer invokes it.
The service registry
For service providers, they need to publish services, and the number and types of services are expanding due to the complexity of application systems. 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 registry
The Zookeeper registry
Redis Registry
Simple Registry
Service monitoring
Both service providers and service consumers need to effectively monitor the actual state of service invocations to improve service quality.
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
The 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:
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 provider publishes the service to the service registry;
The service consumer subscribes to the service from the service registry;
The service consumer invokes the registered available service
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/cancel
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:
Protocol support
Dubbo supports a variety of protocols, as follows:
Dubbo agreement
Hessian protocol
The HTTP protocol
The RMI protocol
WebService agreement
Thrift agreement
The Memcached protocol
Redis protocol
In the communication process, different service levels generally correspond to different quality of service, so it is very important to choose the appropriate protocol. You can choose based on the creation of your application. For example, the RMI protocol is generally restricted by firewalls. Therefore, do not use THE RMI protocol in the scenario of external and internal communication. Instead, use HTTP or Hessian.
Here I recommend an architecture learning exchange group. Exchange learning group number: 478030634 inside will share some senior architects recorded video video: Spring, MyBatis, Netty source code analysis, high concurrency, high performance, distributed, microservice architecture principle, JVM performance optimization, distributed architecture and so on these become architects necessary knowledge system. I can also get free learning resources, which I benefit a lot from now
Refer to the supplementary
Dubbo uses package structure to organize each module, each module and its relationship, as shown in the figure:
This can be organized using Dubbo’s code (managed using Maven) and compared to the above modules. A brief description of each package:
Dubo-common common logic module, including Util class and common model.
Dubbo -remoting is an implementation of the Dubbo protocol. If RPC uses RMI, you do not need to use this package.
Dubbo-rpc remote call module, which abstracts various protocols, and dynamic proxy, contains only one-to-one calls and does not care about cluster management.
Dubbo-cluster is a cluster module that disgusts multiple service providers as one provider, including load balancing, fault tolerance, and routing. The address list of the cluster can be statically configured or delivered by the registry.
Dubbo-registry registry module, clustering based on registry delivery addresses, and abstractions for various registries.
Dubo-monitor monitoring module, statistics service call times, call time, call chain tracking services.
Dubbo -config configuration module is the EXTERNAL API of Dubbo. Users use Dubbo through config to hide all details of Dubbo.
The dubbo-Container module is a Standalone container that starts with a simple Main load on Spring. As services usually do not require features of a Web container such as Tomcat/JBoss, there is no need to use a Web container to load the service.
