Dubbo3 features | cloud-native three-center architecture

Dubbo3 provides a new application-level service discovery model, which is different from Dubbo2's interface-level service discovery model in terms of design and implementation.
In summary, the application-level service discovery introduced by Dubbo3 mainly has the following advantages
• Adapt to changes in cloud-native microservices. The infrastructure capabilities in the cloud-native era are continuously released upwards. Platforms such as Kubernetes integrate the conceptual abstraction of microservices. Dubbo3's application-level service discovery is a general model for adapting various microservice systems.
• Improve performance and scalability. The service governance that supports ultra-large-scale clusters has always been Dubbo's advantage. By introducing an application-level service discovery model, it essentially solves the storage and push pressure of the registry address data, and the corresponding address calculation pressure on the consumer side also drops by an order of magnitude. ; The cluster size has also become predictable and assessable (it has nothing to do with the number of RPC interfaces, but only with the instance deployment scale).
The following figure shows the service discovery model of Dubbo2: Provider registers the service address, Consumer coordinates with the registration center and discovers the service address, and then initiates communication with the address. This is the classic service discovery process used by most microservice frameworks. The special feature of Dubbo2 is that it also integrates the information of "RPC interface" into the address discovery process, and this part of information is often closely related to specific business definitions.
After accessing the cloud-native infrastructure, the infrastructure incorporates the abstraction of the concept of microservices, and the process of orchestrating and scheduling containerized microservices completes the registration at the infrastructure level. As shown in the figure below, the infrastructure not only assumes the responsibility of the registration center, but also completes the service registration action, and the information of the "RPC interface", because it is related to specific businesses, is impossible and unsuitable to be hosted by the infrastructure.
In such a scenario, two requirements are put forward for Dubbo3's service registration discovery mechanism: Dubbo3 needs to abstract a general address mapping model that has nothing to do with business logic in the original service discovery process, and ensure that this part of the model is reasonable enough to Supporting entrusting the registration behavior and storage of addresses to the underlying infrastructure Dubbo3's unique business interface synchronization mechanism is an advantage that Dubbo3 needs to retain. It needs to be resolved through its own mechanism within the framework based on the new address model defined in Dubbo3.
The new service discovery model designed in this way brings greater advantages to Dubbo3 in terms of architecture compatibility and scalability.
In terms of architectural compatibility, as mentioned above, it is possible for Dubbo3 to reuse the service abstraction capabilities of the underlying infrastructure; Afterwards, it becomes possible for users to explore connecting heterogeneous microservice systems with Dubbo.
The Dubbo3 service discovery model is more suitable for building a scalable service system. How to understand this? Here is a simple example to intuitively compare the data flow changes in the address discovery process between Dubbo2 and Dubbo3: Suppose a microservice application defines 100 interfaces (services in Dubbo), you need to register 100 interfaces in the registry. service, if this application is deployed on 100 machines, then these 100 services will generate a total of 100 * 100 = 10000 virtual nodes; and for the same application, for Dubbo3, the new registration discovery model only needs 1 One service (only related to the application and not the interface), only register 1 * 100 = 100 virtual nodes equal to the number of machine instances to the registration center. In this simple example, the number of addresses registered by Dubbo has dropped to 1/100 of the original, which greatly relieves the storage pressure on the registration center and subscribers. More importantly, the address discovery capacity is completely decoupled from the business RPC definition, and the capacity evaluation of the entire cluster will become more transparent to operation and maintenance: as many machines are deployed, there will be a large load, which will not be like Dubbo2. Because business RPC reconstruction will affect the stability of the entire cluster service discovery.
Dubbo3 deployment architecture
This article mainly focuses on the deployment architecture in the context of cloud native, mainly reflected in the fact that infrastructure (Kubernetes, Service Mesh, etc.) will take on more responsibilities, and the three-centered architecture, such as: registration center, metadata center, configuration center, etc. The responsibilities are integrated, making the architecture more excellent and resource optimization more thorough. By analyzing these centralized components, it will be easier for us to understand the working principle of Dubbo3 corresponding to the cloud-native mode.
From the above figure, we can see that in the overall Dubbo Rpc framework, in addition to the corresponding Consumer consumer, Provider service provider, and Registry registration center, which have been defined in dubbo before, there are many other centralized components. There are two centers, config-center and metadata.
Dubbo3's three-centralized system
As a microservice framework, Dubbo SDK is deployed in each location of the distributed cluster along with the microservice components. In order to realize the collaboration between various microservice components in a distributed environment, Dubbo3 has expanded some centralized components, including:
• Registry
• Coordinate address registration and discovery between Consumer consumers and Provider service providers.
• Configuration Center
• Store the global configuration of the Dubbo startup phase to ensure cross-environment sharing and global consistency of the configuration
• Responsible for storing and pushing service governance rules (routing rules, dynamic configuration, etc.).
• Metadata Center
• Receive the service interface metadata reported by the Provider server, and provide operation and maintenance capabilities for Admin and other consoles (such as service testing, interface documents, etc.)
• As a supplement to the service discovery mechanism, it provides the synchronization capability of additional interface/method level configuration information, which is equivalent to an additional extension of the registration center.
Note: The above three center systems are not a necessary condition for running Dubbo. Users can decide to enable only one or more of them according to their own business conditions (even without any center, direct connection mode, of course, not recommended for production) to achieve simplification The purpose of the deployment.
Next, we will give you a detailed explanation of each of these three centers.
registration center
In most cases, we will basically start Dubbo service development with an independent registration center, and the configuration center and metadata center will be gradually introduced on demand during the evolution of microservices.
The registration center plays a very important role, and it carries the responsibilities of service registration and service discovery. Currently Dubbo supports service discovery and service registration at the following two granularities, namely interface level and application level, and the registration center can be deployed on demand:
direct mode
During the initial use of Dubbo SDK, if only the RPC service in direct connection mode is provided, there is no need to deploy a registration center.
registration mode
Regardless of the interface level or the application level, if Dubbo SDK itself is required for service registration and service discovery, you can choose to deploy a registration center and integrate the corresponding registration center in Dubbo.
Mesh mode
In the Dubbo + Mesh scenario, with the weakening of Dubbo service registration capabilities, the registration center in Dubbo is no longer a must, and its responsibilities are beginning to be replaced by the control plane. If the Dubbo + Mesh deployment method is adopted, no matter ThinSDK The mesh method of Proxyless or the mesh method of Proxyless no longer needs to deploy the registration center independently.
The registration center does not depend on the configuration center and metadata center
For composition, the registration center does not completely depend on the configuration center and metadata center, as shown in the following figure.
The configuration center and metadata center are not deployed. In Dubbo, the instance of the registration center will be used as the configuration center and metadata center at the same time by default. This is the default behavior of Dubbo. If you really do not need the capabilities of the configuration center or metadata center, you can use Closed in the configuration, there are two configurations in the configuration of the registration center are use-as-config-center and use-as-metadata-center, set the configuration to false.