Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Decrypting the Three Major Components of Dubbo for High-Availability Deployment

Decrypting the Three Major Components of Dubbo for High-Availability Deployment

We will walk you through Dubbo's three conceptualized central components and how they relate to high-availability deployment architecture.

By Hua Zhongming, Apache Dubbo Committer

Dubbo's Deployment Architecture

Dubbo is a microservice framework. Dubbo SDK is bound to the same process as application services. It follows that application services are deployed in various locations of distributed clusters. To implement collaboration among various application services in a distributed environment, Dubbo defines several centralized components, including:

  • Registry: Coordinates address registration and discovery between consumers and providers
  • Configuration: Stores the global configuration of the Dubbo startup phase to ensure cross-environment sharing and global consistency of the configuration. It is also responsible for storing and pushing service governance rules (such as routing rules, dynamic configuration).
  • Metadata: Receive service port metadata reported by the Provider and provide O&M capabilities for Admin and other consoles (such as service testing and port documentation). As a supplement to the service discovery mechanism, it provides synchronization capability of the additional interface or method level configuration information, which is equivalent to additional expansion of the registry.

1

The figure describes the interaction process between Dubbo microservice components and each center.

However, the preceding three centers are not necessary conditions for running Dubbo. Users can decide not to enable them, or only enable one or more of them according to their business conditions to achieve the purpose of simplifying deployment. Typically, all users develop the Dubbo service with an independent registry, while configuration centers and metadata centers are introduced as needed during the evolution of microservices.

1. Registry Center

The registry center plays an important role, carrying the responsibilities of service registration and service discovery. Currently, Dubbo supports service discovery and registration at the following two granularities, namely, the interface level and the application level. The registry can be deployed as needed:

  • In the traditional posture of Dubbo SDK, if only RPC services are provided in direct connection mode, you do not need to deploy a registry center.
  • If Dubbo SDK is required for service registration and discovery at the interface or application level, you can deploy a registry and integrate the corresponding registry in Dubbo.
  • In the Dubbo + Mesh scenario, with the weakening of Dubbo service registration capability, the registry center in Dubbo is no longer a necessary option, and its responsibilities are replaced by the control plane. If Dubbo + Mesh deployment mode is adopted, no matter ThinSDK mesh mode or Proxyless mesh mode, it is no longer necessary to deploy the registry center independently.

The registry does not rely on configuration center and metadata centers, as shown in the following figure:

2

In this figure, no configuration center and metadata center are deployed. In Dubbo, the instance of the registry is used as the configuration center and metadata center by default. This is the default behavior of Dubbo. If you do not need the configuration center or metadata center, you can disable it in the configuration. In the configuration of the registry, there are two configurations: use-as-config-center and use-as-metadata-center. Just set the configuration to false.

2. Metadata Center

Metadata centers are supported in 2.7.x. As application-level service registration and discovery are implemented in Dubbo, metadata centers become important. Metadata center deployment will be required in several situations.

  1. For an application service originally built with the old version of Dubbo, when migrating to Dubbo 3, Dubbo 3 needs a metadata center to maintain the mapping relationship between RPC services and applications ( the mapping relationship between interfaces and applications). If application-level service discovery and registration are adopted, the data organization form of the "application-instance list" structure will be adopted in the registry center. It is no longer an "interface-instance list" structure. However, when the application services that used interface-level service registration and service discovery in the past migrate to the application level, they cannot obtain the corresponding relationship between the interface and the application. Thus, they are unable to obtain the instance list information from the registry center. Therefore, to be compatible with this scenario, Dubbo starts at the provider side. It stores the mapping between interfaces and applications to the metadata center.
  2. To make the registry focused and address discovery and push capabilities and reduce the burden on the registry, the metadata center carries such as all service metadata and a large amount of interface /method level configuration information. Whether it is service discovery and registration at interface granularity or application granularity, the metadata center plays an important role.

If you have both requirements, you can deploy a metadata center and use Dubbo configurations to integrate the metadata center.

The metadata center does not depend on the registry and configuration center. Users can choose whether to integrate or deploy the metadata center, as shown in the following figure:

3

The figure is not equipped with a configuration center, which means that the ability to manage configurations globally is not required. The figure does not have a registry center, which means that the Dubbo mesh scheme may be adopted, service registration may not be required, and only service calls in direct connection mode may be received.

3. Configuration Center

The configuration center is different from the other two centers. It has nothing to do with interface or application level. It has no corresponding relationship with the interface. It is related to configuration data. Although there is no registry and metadata center deployed, the configuration center can be directly connected to Dubbo application services. In the entire deployment architecture, instances in the entire cluster (whether providers or consumers) will share the configurations in the configuration center cluster, as shown in the following figure:

4

The figure does not have a registry center, which means that the Dubbo mesh scheme may be adopted, service registration may not be required, and only service calls in direct connection mode may be received.

The figure is not equipped with a metadata center, which means that the consumer can obtain service metadata from the metadata service exposed by the Provider to implement RPC calls.

High-Availability Deployment Architecture for Preserving the Three Centers

Although the three centers above are no longer necessary for Dubbo application services, in a real production environment, once the three centers have been integrated and deployed, the three centers still face availability problems. Dubbo needs to support the high availability solutions of the three centers. Dubbo supports multi-registry, multi-data centers, and multi-configuration centers to meet the requirements of deployment architecture modes such as active zone-redundancy, three data centers across two zones, and active geo-redundancy.

The Dubbo SDK supports multiple modes for all three centers.

  • Multi-registry: Dubbo supports multiple registries. An interface or an application can be registered with multiple registries, such as ZK clusters and Nacos clusters. Consumers can subscribe to the address information of related services from multiple registries to discover services. You can switch to another registry cluster when one of the registry clusters is unavailable. This ensures that services can be provided and service calls can be initiated. This can also meet the requirements of the registry to adapt to various highly available deployment architecture patterns.
  • Multi-configuration center: Dubbo supports multi-configuration centers to ensure that one configuration center cluster can be switched to the other configuration center cluster when it is unavailable. This ensures that global configurations and routing rules can be obtained from the configuration center. This can meet the configuration center to adapt to various highly available deployment architecture patterns in deployment.
  • Multi-data center: Dubbo supports multi-data center. It is used to deal with the unavailability of a metadata center cluster due to disaster recovery. As such, you can switch to another metadata center cluster to ensure that the metadata center can manage service metadata.

Take the registry as an example. The following is a schematic diagram of the deployment architecture for a multi-active scenario:

5

Current Issues

  • The configuration of the metadata center can be bound to a registry and configured through a registry, but there are some problems with the configuration to be fixed.
  • As mentioned earlier, only one metadata center will be used for Pub and Sub of metadata:

6

SDK Architecture Microservices Developers High Availability Dubbo Configuration metadata center
0 0 0
Share on

Read previous post:

Sealer – A Kubernetes-based Distributed Application Package & Delivery Tool

Read next post:

AppActive: An Open-Source Multi-Active Disaster Tolerance Architecture

Alibaba Cloud Native Community

506 posts | 48 followers

You may also like

Comments

Alibaba Cloud Native Community

506 posts | 48 followers

Related Products

More Posts by Alibaba Cloud Native Community

See All