By Zou Yixian (GitHub ID: @zouyx), an open-source enthusiast. He works in the SheIn supply chain department and is responsible for the supply chain open platform.
In the Apache/dubbo-go (hereinafter referred to as Dubbo-go) community, some members wanted configuration files to be placed not only locally, but also in the configuration management center. It's critical to answer: what is the difference between being placed locally and in the configuration management center?
If the configuration files are placed locally, you have to restart the system after each update, making it difficult to manage configuration files and preventing real-time updates from taking effect right away. Local files also rely on manual versioning, which greatly increases the costs and difficulty of O&M in microservice scenarios.
The configuration management center provides centralized configuration file management, real-time synchronization of file updates, centralized version control, and permission management.
Based on the preceding background, let's summarize the following purposes:
In Dubbo-go, the configuration center is responsible for the following scenarios:
For now, Dubbo-go primarily supports all open-source configuration centers supported by Dubbo, including:
However, considering that some companies have their own R&D configuration centers, or there are configuration centers that are currently popular but not supported by Dubbo, such as etcd, we focus on designing a mechanism that allows us, including users, to quickly access different configuration centers by extending the interfaces with new implementations.
Then, how do we implement this in Dubbo-go? The answer is to use the dynamic plug-in mechanism, which loads different implementations of configuration center on-demand at startup.
These functions are implemented in an independent sub-project. Check out this page for more information.
The original design logic ensures Dubbo-go reads the local configuration file after startup, loads it into the memory, reads the information of the registry through the configuration file to obtain the information about the service provider, and registers the service consumer.
In this logic, some of you may be confused about why we need to read the local configuration file now if we have agreed to use the configuration center. The reason is that the information that Dubbo-go reads is divided into two parts:
1) The object that functions as the configuration center.
2) The metadata in the configuration center.
For example, if ZooKeeper is used as the configuration center, the link information of ZooKeeper is metadata. After all, we must obtain the link information before we can connect to ZooKeeper.
During the renovation, the following issues need to be considered:
1) How can we support multiple configuration centers? How can we load data on demand?
By abstracting the DynamicConfiguration
class, developers can quickly support multiple configuration centers. After you import a specified component package, Dubbo-go loads the required components into the memory during startup so that they can be called on demand by applications, as shown by the cells in the green background in the following figure.
2) When is the configuration loading phase of the configuration center?
This happens after Dubbo-go reads configuration files. Specifically, Dubbo-go reads and analyzes the information of configuration centers from local configuration files. Then, it initializes configuration center links, reads /dubbo/config/dubbo/dubbo.properties and /dubbo/config/dubbo /<Application name>
/dubbo.properties, and loads them to the memory to overwrite the original configurations. Next, it monitors configuration changes, and updates the changes to the memory in real-time, as shown by the cells in the blue background in the following figure.
After loading the corresponding modules of a configuration center, add each configuration center module to register its initialization classes in the initialization phase.
The key of the whole dynamic configuration center is the DynamicConfigurationFactory class, which is used to create a link for a configuration center by parsing the internal custom URL of the configuration center, obtaining its protocol type, and extracting its parameters.
For example: Make the following configuration in the configuration file:
config_center:
protocol: zookeeper
address: 127.0.0.1:2181
namespace: test
Dubbo-go parses it internally to the following format:
zookeeper://127.0.0.1:2181? namespace=test
Then, Dubbo-go uses it internally to initialize the configuration center link.
Note: The internal protocol in this example is available everywhere in Dubbo-go. A thorough understanding of the internal protocol is helpful for interpreting Dubbo-go code.
This interface specifies the functions to be implemented in each configuration center, as described below.
This phase prioritizes the compatibility with the existing Dubbo design to reduce learning costs for users. Dubbo-admin implements application-level configuration management as the service provider, whereas Dubbo-go implements configuration delivery management as the consumer. The following section uses ZooKeeper as an example to analyze the overall processes of service providers and consumers.
Dubbo-admin adds a global configuration in configuration management, and corresponding configuration nodes are automatically generated in ZooKeeper. The contents of the nodes are the configurations set in Dubbo-admin.
<Application name>
/dubbo.properties corresponds to the application configuration file.The preceding figure shows the storage structures of the Dubbo.properties files respectively in ZooKeeper and Apollo:
1) ZooKeeper
2) Apollo
The biggest difference between ZooKeeper and Apollo is the node where Dubbo.properties are located.
The following uses Apollo as an example to describe how to support a new configuration center.
This example uses the Apollo Go Client obtained from https://github.com/zouyx/agollo
Note: If you cannot find the client, you can implement it yourself.
The storage structure of each configuration center has its own characteristics. Therefore, when Dubbo uses an external configuration center, it adopts a different structure of storage configuration nodes. In dubbo-configcenter, find the configuration center that you want to support. In this example, Apollo is located in ApolloDynamicConfiguration.java.
As the annotations show, Apollo namespace = governance (governance.properties) is used for governance rules, and namespace = dubbo (dubbo.properties) is used for configuration files.
Create a new client creation method. We recommend creating a single client at a time.
The following methods are required and used to obtain the configuration of a configuration center. In these methods, the namespace of the configuration file is Apollo.
Choose the implementation method. If this method is not implemented, the configuration in Dubbo-go cannot be dynamically updated.
Use the default implementations of Parser and SetParser, which are Properties converters by default.
For more information, see dubbo-go-apollo.
From the preceding design, let's depict its application.
To use a configuration center, you only need to import the related dependencies. The configuration center is implemented after package initialization. For example, you may load ZooKeeper or Apollo as the configuration center as shown below.
_ "github.com/apache/dubbo-go/config_center/zookeeper"
_ "github.com/apache/dubbo-go/config_center/apollo"
To implement the configuration center, loading is only part of the process. For example, after loading ZooKeeper, you also need to connect to the configuration center, that is, the metadata of the configuration center mentioned earlier, which is configured locally. For example:
config_center:
protocol: "zookeeper"
address: "127.0.0.1:2181"
If Apollo is used as the configuration center, create namespace: dubbo.properties in advance for configuration management.
config_center:
protocol: "apollo"
address: "127.0.0.1:8070"
app_id: test_app
cluster: dev
This document will not elaborate on the more specific implementation process. If you are interested, we recommend that you check the source code. Your continued interest in and contributions to the code are welcome.
Though the configuration center is compact, its functions are complete. Although the preceding methodology is imperfect, it is developing on the right track from the overall architecture perspective. In terms of scalability, its performance is good. Currently, it supports a limited number of configuration centers, which are actually ZooKeeper and Apollo, and only supports configuration files with the properties extension. While this already meets the requirements of basic application scenarios, it still has some way to go until it is optimized.
Future enhancements include:
1) Nacos (pending release)
2) etcd (under development)
3) Consul (not supported at present)
4) Additional configuration file formats, such as YML and XML
Common Solutions for Scheduling and Delay Problems in Business Scenarios
Aixuexi Education Group: Racing Against Time through Cloud-Native Practices
199 posts | 12 followers
FollowAlibaba Cloud Native Community - January 26, 2024
Aliware - April 13, 2020
Alibaba Cloud Native Community - July 2, 2021
Alibaba Developer - February 4, 2021
Alibaba Cloud Native Community - May 21, 2021
Alibaba Cloud Native Community - April 23, 2023
199 posts | 12 followers
FollowMSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.
Learn MoreBuild a Data Lake with Alibaba Cloud Object Storage Service (OSS) with 99.9999999999% (12 9s) availability, 99.995% SLA, and high scalability
Learn MorePlan and optimize your storage budget with flexible storage services
Learn MoreA unified security management system that identifies, analyzes, and notifies you of security threats in real time
Learn MoreMore Posts by Alibaba Cloud Native