Dubbo system architecture analysis

Dubbo’s two main design principles

The Dubbo framework was designed with two principles in mind:

• Use the “microkernel + plug-in” design pattern. The kernel is only responsible for assembling plug-ins (extension points), and all of Dubbo’s functionality is implemented by plug-ins. As an excellent RPC framework, Dubbo is a top-level project of Apache. One of the biggest highlights of Dubbo is its excellent unlimited open design architecture — the architectural design idea of “micro-kernel + plug-in”, which makes almost all its components easy to be extended, enhanced and replaced.

• The URL is used as the uniform format of configuration information, and all extension points carry configuration information by passing the URL.

Dubbo’s three domain model

To facilitate the description of Dubbo’s overall architecture, Dubbo abstracts three domain models.

• Protocol Service domain: The main functional entry for Invoker exposure and references, which is responsible for the lifecycle management of Invoker.
• Invoker entity domain: the core model of Dubbo, to which other models rely or convert, represents an executable to which invoke calls can be made. It may be a local implementation, a remote implementation, or a cluster implementation.
• The Invocation session field: It holds the Invocation variables, such as method names, parameters, etc.

The four components of Dubbo

• Provider: indicates the service Provider.
• B: We serve consumers.
• Registry: a center for service registration and discovery that provides directory services.
• Monitor: a log service that collects statistics on service invocation times and invocation time and can set service permissions and degrade services. This log service is called a service control center.

Dubbo’s ten-tier architecture

Dubbo’s architecture is divided into 10 layers. In the figure, the left light blue background is the interface used by the service Consumer, the right light green background is the interface used by the service Provider, and the interface located on the central axis is the interface used by both parties. These 10 floors can be divided into three floors according to their overall functions:

The Business layer

This layer contains only one Service service layer, which is related to the actual business logic and realizes the corresponding interface according to the business design of the service consumer and service provider.

RPC layer

This layer is mainly responsible for the communication between hosts in the whole distributed system. This layer consists of the following six layers.

• Config configuration layer: Centered around ServiceConfig and ReferenceConfig, used to load and parse Dubbo tags in Spring configuration files.
• Proxy ServiceProxy layer: transparent proxy of service interfaces. The client Stub and server Skeleton that generate services are centered on ServiceProxy, and the extension interface is ProxyFactory. The Proxy layer encapsulates the transparent Proxy of all interfaces, while the other layers are invoker-centric and only when exposed to the user, they use Proxy to convert Invoker into interface, or convert interface implementation into Invoker. So you get rid of the Proxy layer and YOU can run RPC but it’s not so transparent, it doesn’t look like you’re calling a remote service like you’re calling a local service.
• Registry layer: encapsulates the registration and discovery of service addresses, centering on service URLS and extending interfaces to RegistryFactory, Registry, and RegistryService. There may be no service registry, in which case the service provider directly exposes the service.
• Cluster routing layer: Encapsulate the routing and load balancing of multiple providers, bridge the registry, take Invoker as the center, extend the interface to Cluster, Directory, Router and LoadBalance, combine multiple service providers into one service provider, and realize the clarity of service consumption. You only need to interact with one service provider. Dubbo officials point out that Cluster is a peripheral concept in Dubbo’s overall architecture. The purpose of a Cluster is to disguise multiple invokers as a single Invoker, so that the user can focus only on the Protocol layer Invoker. Adding or removing the Cluster does not affect the other layers, because when there is only one provider, Cluster is not required.
• Monitor monitoring layer: Monitors the time and number of RPC calls. With Statistics as the center, it extends MonitorFactory, Monitor, and MonitorService.
• Protocol Remote Invocation layer: Encapsulates 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 are converging-or converging-represents an executable to which Invoker calls can be made. It may be a local implementation, a remote implementation, or a cluster implementation. 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.

Remitting layer

Remoting is the implementation of Dubbo protocol. If we choose RMI protocol, the entire Remoting will not be used. Remoting is divided into Transport layer and Exchange layer. The Transport layer is only responsible for one-way message transmission, which is an abstraction of Mina, Netty and Grizzly. It can also extend UDP Transport, while the Exchange layer encapsulates request-Response semantics on top of the Transport layer.

• Exchange information exchange layer: package Request and Response model, synchronous asynchronous, centered on the Request and Response, extension interface for Exchanger and ExchangeChannel, ExchangeClient and ExchangeServer.
• Transport Network transport layer: Abstract and MINA and Netty are unified interfaces, Message is the center, and extended interfaces are Channel, Transporter, Client, Server, and Codec.
• Serialize Data Serialization layer: reusable tools that extend interfaces to Serialization, ObjectInput, ObejctOutput, and ThreadPool.

Dubbo framework module parsing

will Dubbo Source code project import Idea

The source code version we are reading is Dubbo2.7.3. Download the source zip package from the official website and decompress it to import it directly into Idea.

Github address: github.com/apache/dubb…