Dubbo SDK is a microservice framework. Dubbo SDK and application services are bound in the same process. Dubbo SDK follows application services to be deployed in various locations of distributed cluster.

The author | bell heart Ming

01 Deployment Architecture

As a micro-service framework, Dubbo SDK and application services are bound in the same process. It follows application services to be deployed in various locations of distributed cluster. In order to realize the collaboration among various application services in distributed environment, Dubbo defines some centralized components, including:

  • Registry: Coordinates address registration and discovery between Consumer and Provider

  • Configuration center:

  • The global configuration during Dubbo startup is stored to ensure cross-environment sharing and global consistency

  • Store and push service governance rules (routing rules, dynamic configuration, etc.).

  • Metadata center.

  • Receives service interface metadata reported by the Provider and provides o&M capabilities (such as service tests and interface documents) for the Admin console.

  • Complementing the service discovery mechanism, providing additional interface/method-level configuration information synchronization capabilities is equivalent to an additional extension of the registry

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

However, the above three centers are not necessary to run Dubbo. Users can choose to enable none of them, only one of them, or multiple of them to simplify deployment. Typically, all users start Dubbo service development in a separate registry, while configuration centers and metadata centers are introduced on demand as microservices evolve.

1. Registry

Registries play a very important role, hosting the responsibilities of service registration and service discovery. Dubbo currently supports service discovery and service registration at the interface level and application level, and registries can be deployed on demand:

  • In the traditional Dubbo SDK usage posture, there is no need to deploy a registry if you only provide RPC services in direct connection mode.
  • If the Dubbo SDK itself is required to do service registration and service discovery, whether at the interface level or application level, you can choose to deploy a registry and integrate the corresponding registry into Dubbo.
  • In the Dubbo + Mesh scenario, with the weakening of the Dubbo service registration capability, the registry in Dubbo is no longer required and its responsibilities are replaced by the control plane. If the Deployment mode of Dubbo + Mesh is adopted, A separate deployment registry is no longer required for either ThinSDK’s mesh or Proxyless’s mesh.

Registries are independent of configuration centers and metadata centers, as shown below:

The configuration center and metadata center are not deployed in this figure. By default, the instance of the registry is used as both the configuration center and metadata center in Dubbo. This is the default behavior of Dubbo. In the registry configuration, use-as-config-center and use-as-metadata-center are configured to false.

2. Metadata center

Metadata center support began in version 2.7.x and has become increasingly important as application-level service registration and service discovery are implemented in Dubbo. Metadata center deployment is required in the following situations:

  1. For an application service originally built with an older version of Dubbo, Dubbo 3 will require a metadata center to maintain the mapping between RPC services and applications (that is, interfaces and applications) when migrating to Dubbo 3, because with application-level service discovery and service registration, “Application – will be used in the registry instance list” the organization of data structure, is no longer the previous “interface – instance list” the organization of data structure, whereas in the past with interface level service registration and service discovery application service during the migration to the application level, can not get the corresponding relationship between interface and application, Therefore, Dubbo cannot obtain instance list information from the registry. To be compatible with this scenario, Dubbo stores the mapping between interfaces and applications to the metadata center when the Provider is started.

  2. In order to make the registry has focused on the address detection and push ability, reduce the burden of the registry, metadata center carries all of the service metadata, a large number of interface/method level configuration information, such as application interface granularity and granularity of the service discovery and registration, and meta data center has played an important role.

If the preceding two requirements are met, you can deploy the metadata center and integrate the metadata center by configuring Dubbo.

The metadata center is independent of the registry and configuration center. Users can choose whether to integrate and deploy the metadata center, as shown in the following figure:

The absence of a configuration center in this figure means that the ability to manage configurations globally is not required. The absence of a registry in this figure means that the Dubbo Mesh scheme may be used, or service registration may not be required and only service invocations in direct connection mode may be received.

3. Configure the center

Unlike the other two centers, the configuration center is not about interface level or application level. It has no correspondence with the interface. It is only about configuration data. Throughout the deployment architecture, instances (both Provider and Consumer) across the cluster will share the configuration in the central cluster, as shown below:

The absence of a registry in this figure means that the Dubbo Mesh scheme may be used, or service registration may not be required and only service invocations in direct connection mode may be received.

The absence of a metadata center in this figure means that the Consumer can get the service metadata from the MetadataService exposed by the Provider to implement the RPC calls.

02 Protecting the highly available deployment architecture of the three centers

Although the three hubs are no longer necessary for Dubbo application services, in a real production environment, once the three hubs have been integrated and deployed, they still face usability issues and Dubbo needs to support a high availability solution for the three hubs. Dubbo supports multiple registries, multiple data centers, and multiple configuration centers to meet the requirements of deployment architecture patterns such as same-city multi-live, two-place, three-center, and remote multi-live.

The Dubbo SDK supports Multiple mode for all three hubs.

  • Multiple registries: Dubbo supports multiple registries, meaning that an interface or application can be registered in multiple registries, such as ZK and Nacos clusters. Consumers can also subscribe to address information of related services from multiple registries for service discovery. Multiple registries are supported to ensure that if one registry cluster becomes unavailable, it can be switched to another registry cluster to ensure the normal service provision and service invocation. This also enables registries to adapt to various highly available deployment architecture patterns on deployment.

  • Multi-configuration center: Dubbo supports multiple configuration centers to ensure that when one configuration center cluster becomes unavailable, it can switch to another configuration center cluster and obtain global configuration and routing rules from the configuration center. This also enables the configuration center to adapt to various highly available deployment architecture patterns on deployment.

  • Multivariate data center: Dubbo Supports multivariate data center: when a metadata center cluster becomes unavailable due to disaster recovery (Dr), you can switch to another metadata center cluster to ensure that the metadata center can properly manage service metadata.

Taking the registry as an example, here is a schematic deployment architecture for a live scenario:

03 Existing problems

  • The configuration of the metadata center can be bound to a registry, configured through Registry, but there are configuration issues that need to be fixed
  • Pub, Sub, which uses only one metadata center for metadata:

About the author:

Hua Zhongming: Apache Dubbo Committer, author of In-depth Understanding of RPC Principles and Implementation. The book provides a more in-depth introduction to Dubbo’s core architecture and the importance of the three centers, and interested readers can read the book to learn more. You are also welcome to actively participate in the Dubbo open source community and work with the authors to build Dubbo.

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.