Source Code Architecture on Apache Dubbo

Analysis of Single-Port Multi-Protocol Implementation Principles

Mon, 01 Jan 0001 00:00:00 +0000

By configuring protocols, Dubbo 3 can support port protocol multiplexing. For instance, after enabling port reuse with the Triple protocol, you can add support for the Dubbo protocol and the Qos protocol on the same port. These protocols are identified by a unified port reuse server, which can facilitate service protocol migration, save ports and related resources, and reduce operational complexity.

During the service creation phase, different Protocol objects are created for export by retrieving service export protocol configurations from the Config layer. If it’s not the first time creating a port-reusing Server, the Exchanger saves data passed from the Protocol layer to the Server for subsequent processing of that protocol type’s messages.

Code Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Overall Design

Legend explanation:

The light blue background on the left side of the diagram represents the interfaces used by service consumers, the light green background on the right side represents the interfaces used by service providers, and the interfaces on the central axis are used by both parties.
The diagram is divided into ten layers from bottom to top, with each layer being a one-way dependency. The black arrows on the right represent the dependency relationships between layers. Each layer can detach from the upper layer for reuse, where the Service and Config layers are APIs and the others are SPIs.
The green small blocks represent extension interfaces, and the blue small blocks represent implementation classes. Only the implementation classes related to the inter-layer connections are shown in the diagram.
The blue dashed lines represent the initialization process, i.e., the assembly chain during startup, the red solid lines represent the method invocation process, i.e., the runtime invocation chain, and the purple triangular arrows represent inheritance, where subclasses can be seen as the same node as their parent class. The text on the lines indicates the invoked methods.

Layer Descriptions

Config Layer: External configuration interface centered around ServiceConfig and ReferenceConfig, allowing direct initialization of configuration classes or generating configuration classes through Spring.
Proxy Layer: Transparent proxy for service interfaces, generating client Stubs and server Skeletons centered around ServiceProxy, with the extension interface being ProxyFactory.
Registry Layer: Encapsulates the registration and discovery of service addresses, centered around service URLs, with extension interfaces RegistryFactory, Registry, RegistryService.
Cluster Layer: Encapsulates routing and load balancing for multiple providers and bridges to the registry, centered around Invoker, with extension interfaces Cluster, Directory, Router, LoadBalance.
Monitor Layer: Monitors RPC call counts and call durations, centered around Statistics, with extension interfaces MonitorFactory, Monitor, MonitorService.
Protocol Layer: Encapsulates RPC calls, centered around Invocation and Result, with extension interfaces Protocol, Invoker, Exporter.
Exchange Layer: Encapsulates request-response patterns, synchronizing to asynchronous, centered around Request and Response, with extension interfaces Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer.
Transport Layer: Abstracts Mina and Netty into a unified interface, centered around Message, with extension interfaces Channel, Transporter, Client, Server, Codec.
Serialize Layer: Reusable tools, with extension interfaces Serialization, ObjectInput, ObjectOutput, ThreadPool.

Relationship Explanation

In RPC, the Protocol is the core layer, meaning that as long as there is Protocol + Invoker + Exporter, non-transparent RPC calls can be completed, then applying Filters on the Invoker’s main process.
The Consumer and Provider in the diagram are abstract concepts meant to help viewers understand which classes belong to the client and server side. The reason for not using Client and Server is that Dubbo employs Provider, Consumer, Registry, and Monitor to define logical topological nodes in many scenarios, maintaining a unified concept.
Cluster is an external concept, meaning its purpose is to disguise multiple Invokers as a single Invoker, allowing others to focus only on the Protocol layer Invoker. Adding or removing Cluster will not affect other layers, as there is no need for Cluster with only one provider.
The Proxy Layer encapsulates transparent proxying for all interfaces, and in other layers, it revolves around the Invoker. Only at the point of exposing for user use is Proxy used to convert Invoker into an interface or convert interface implementations into Invoker. This means removing the Proxy layer allows RPC to run, though it won’t be as transparent or seem as local as remote service calls.
The Remoting implementation is the Dubbo protocol implementation. If you choose the RMI protocol, the entire Remoting will not be used. Remoting is internally divided into the Transport layer and the Exchange layer, where the Transport layer is responsible for one-way message transmission, abstracting Mina, Netty, and Grizzly, and it can also extend UDP transmission. The Exchange layer encapsulates Request-Response semantics on top of the Transport layer.
The Registry and Monitor should not be counted as a layer but rather as independent nodes, drawn together for a global view in a layered manner.

Module Packaging

Service Invocation Extension Points

Mon, 01 Jan 0001 00:00:00 +0000

As shown in the figure above, from the perspective of service invocation, Dubbo provides a wealth of extension points in the call chain, covering load balancing methods, interceptors before and after service location, server processing interceptors, and more. In simple terms, when Dubbo initiates a remote call, the main workflow can be divided into two parts: the consumer side and the server side.

The workflow of the consumer side is as follows:

Extension Point Development Guide

Mon, 01 Jan 0001 00:00:00 +0000

1. Introduction to Dubbo SPI Extensions

The extension mechanism in Dubbo is similar to the JDK standard SPI extension points principle. Dubbo has made certain modifications and enhancements:

The JDK standard SPI instantiates all extension point implementations at once, which can waste resources if the extension implementations are resource-intensive but not used.
If an extension point fails to load, JDK SPI does not provide detailed information to locate the problem, while Dubbo SPI logs the actual failure reason on failure and prints it out.
Adds IOC, AOP capabilities.
Adds sorting capabilities.
Adds conditional activation capabilities.
Provides a series of more flexible APIs, such as getting all SPI extension implementations, querying a specific extension implementation by name, querying extensions by type, and querying extension implementations that match conditions.

1.1 Definition of SPI

The SPI plugin in Dubbo is standard Java Interface definition and must contain the @org.apache.dubbo.common.extension.SPI annotation: