Some of you in the Apache/ Dubo-Go community wanted configuration files to be stored not only locally, but also in the configuration manager. So what’s the difference between being local and being in the CONFIGURATION manager?

You need to restart the configuration file every time it is updated on the local PC. As a result, configuration file management is difficult and real-time update takes effect immediately. In addition, local files also rely on manual version control, which greatly increases the cost and difficulty of operation and maintenance in the microservice scenario.

The CONFIGURATION manager provides unified configuration file management, including file update, real-time synchronization, unified version control, and permission management.

The target

Based on the above background, the following objectives can be summarized

  • Compatible with configuration files in Dubbo’s existing configuration center, reducing the cost of learning new language stacks;
  • Supports multiple configuration file formats.
  • Mainstream configuration centers are supported to adapt to different scenarios and deliver highly scalable configurations.

Configuration center

The configuration center is responsible for the following scenarios in Dubbo-Go:

  • Properties configuration file. In this case, the key value is the file name, for example, dubo. properties, and value is the content of the configuration file.
  • Stores a single configuration item, such as switch items and constant values.
  • Storage service governance rules. In this case, key is organized in the format of service name + rule type, and value is a specific governance rule.

Dubo-go should support all of the various open source configuration centers supported in Dubbo, including:

  • Apollo: The distributed configuration center developed by the Framework department of Ctrip can centrally manage the configuration of applications in different environments and clusters, and push the configuration modification to the application end in real time. It has standardized permissions and process governance features, and is suitable for micro-service configuration management scenarios.
  • Zookeeper: a distributed, open source distributed application coordination service. It is an open source implementation of Google’s Chubby and a key component of Hadoop and Hbase. It provides consistency services for distributed applications, including configuration and maintenance, domain name service, distributed synchronization, and group service.
  • Nacos: Alibaba’s open source configuration management component provides an easy-to-use feature set to help you implement dynamic service discovery, service configuration management, and service and traffic management.

Considering that some companies have their own in-house development configuration centers, or currently popular configuration centers that Dubbo does not support, such as ETCD, our core is to design a mechanism that allows us, and our users, to quickly access different configuration centers through new implementations of extended interfaces.

So how does that work in Dubo-Go? Our answer is: a dynamically based plug-in mechanism loads different implementations of the configuration center on demand at startup.

Implementing this part of the functionality is placed in a separate subproject, see: github.com/apache/dubb…

Dubbo – go design

The original logic is: read the local configuration file during startup, load it into the memory, read the information of the registry through the configuration file to obtain the service provider, and register the service consumer.

Some readers may be a little confused. Why read the local configuration when you were supposed to use the configuration center? The answer is that the information read is divided into two parts:

  • What to use as the configuration center;

  • The metadata of the configuration center, for example, if ZooKeeper is used as the configuration center, the link information of ZooKeeper is metadata. After all, we can only connect to ZooKeeper after we know the link information.

During the renovation, the following issues need to be considered:

  1. How to support multiple configuration centers? How to implement load on demand?

Abstract DynamicConfiguration allows developers to quickly support multiple configuration centers.

After the user imports the specified component package, it loads the required components into memory during startup for the program to call on demand, as shown in green below.

  1. When is the configuration load phase in the configuration center?

The configuration center information in the local configuration file should be read and parsed after the read configuration file phase. Initialization configuration center link, and read/dubbo/config/dubbo/dubbo. The properties and/dubbo/config/dubbo/application name/dubbo, properties, and loads it into memory to cover the original configuration, monitoring the change, Real-time updates to memory, as shown in blue.

ConfigCenterFactory

After loading the corresponding configuration central module, the user adds each configuration central module to register its initialization class in the initialization stage.

DynamicConfigurationFactory

The center of the whole dynamic configuration key points on the DynamicConfigurationFactory, including internal custom URL by parsing, obtain the protocol type, reflecting its parameters, is used to create the configuration center link.

Such as:

Configured in the configuration file

Config_center: protocol: ZooKeeper Address: 127.0.0.1:2181 Namespace:test
Copy the code

Dubo-go internally resolves to zero

Zookeeper: / / 127.0.0.1:2181? namespace=test
Copy the code

Passed internally to initialize the configuration center link.

PS: This internal protocol is ubiquitous in Dubbo-Go, and a thorough understanding of this internal protocol is helpful in reading dubbo-Go code.

DynamicConfiguration

This interface defines the functions that each configuration center needs to implement:

  • Configuration data deserialization way: currently, only the properties deserialization, see: DefaultConfigurationParser.
  • Add listener: Used to add specific logic after adding changes in listening data (subject to configuration center client implementation).
  • Delete listeners: Delete existing listeners (this method is not currently known to be provided by the NacOS Client due to the limitations of the configuration center client implementation).
  • Obtain routing configuration: Obtain routing table configuration.
  • Obtain application-level configuration: Obtain application-level configuration, such as protocol type configuration.

implementation

Compatibility with existing Dubbo designs is given priority to reduce users’ learning costs. Dubbo-admin implements application-level configuration management as a service provider, and Dubbo-Go implements configuration delivery management as a consumer. Taking ZooKeeper as an example, the whole process of service providers and service consumers is analyzed.

How do I store configuration management

If the global configuration is added to the dubbo-admin configuration management, zooKeeper automatically generates the corresponding configuration node, which contains the configuration configured in dubbo-admin.

  • / dubbo/config/dubbo/dubbo properties corresponding to the global configuration file.
  • /dubbo/config/dubbo/ application name /dubbo.properties Corresponds to the specified application configuration file.

Node path

The image above shows the storage structure of the dubo.properties file in ZooKeeper and Apollo:

zookeeper

  • The namespace is dubbo

  • Group: The global level is Dubbo, which is shared by all applications. The application level is the application name demo-provider, which takes effect only for the application

  • key : dubbo.properties

Apollo

  • App_id: specifies the namespace. The default value is dubbo, which is the same as the ZooKeeper namespace

  • Cluster: freely specified. It is recommended that the cluster be consistent with the ZooKeeper group

  • Namespace namespace: dubo.properties

The biggest difference between ZooKeeper and Apollo is the node where Dubo.properties is located.

Implement configuration manager support

Apollo as an example, a brief introduction to how to implement support for a new configuration management center.

Select the Configuration Manager Client or SDK

The Apollo Go Client used in this example is github.com/zouyx/agoll… .

PS: If not found, their own implementation is also possible oh.

Node path

Because the storage structure of each configuration manager is different, the structure of storage configuration nodes is different when Dubbo uses an external configuration manager. Found in dubbo – configcenter want to support configuration management center, and in this case, Apollo in ApolloDynamicConfiguration. Java.

Apollo namespace = governance (governance.properties) is used for governance rules and namespace = dubbo (dubbo.properties) is used for configuration files.

Implement DynamicConfiguration

Create a method to create a client. It is best to keep the client as a singleton.

The following methods must be implemented to get the configuration center configuration.

  • GetInternalProperty: In the configuration file (Apollo is a namespace), obtain the corresponding value based on the key.
  • GetRule: Get the governance configuration file (Apollo is namespace);
  • GetProperties: Get the entire configuration file (Apollo is namespace);

You can select the implementation method. If the method is not implemented, the configuration information in Dubo-Go cannot be dynamically updated.

  • RemoveListener
  • AddListener

Parser & SetParser uses the default implementation, which is the Properties converter.

For more information, see: Dubo-go-Apollo.

Method of use

From the above design, you can probably guess how to use:

Obviously, using a configuration center is not complicated; you just need to bring in the corresponding dependencies. When the package is initialized, an implementation of the corresponding configuration center is created. For example, load ZooKeeper or Apollo as configuration center:

zookeeper

_ "github.com/apache/dubbo-go/config_center/zookeeper"
Copy the code

Apollo

_ "github.com/apache/dubbo-go/config_center/apollo"
Copy the code

Of course, loading is not enough. For example, although I have loaded ZooKeeper, I still need to know how to connect to the configuration center, that is, the metadata of the configuration center mentioned above, which needs to be configured locally. Such as:

zookeeper

config_center:
  protocol: "zookeeper"
  address: "127.0.0.1:2181"
Copy the code

Apollo

If you want to use Apollo as the configuration center, create namespace dubo. properties for configuration management.

config_center:
  protocol: "apollo"
  address: "127.0.0.1:8070"
  app_id: test_app
  cluster: dev
Copy the code

conclusion

More specific implementation, I will not discuss in detail, you can go to see the source code, welcome to continue to pay attention to, or contribute to the code.

The function of the whole configuration center, sparrow is small, but the five viscera. It’s not perfect at the moment, but it’s on the right path at the framework level. From the expansibility, is more convenient. Currently, the supported configuration center is not rich enough, only ZooKeeper and Apollo, and the supported configuration file format is only Properties. Although it can meet the basic usage scenarios, there is still a long way to go to perfect.

Future plans:

  1. Nacos (already PR, under review)
  2. Etcd (not supported)
  3. Consul (not supported)
  4. Rich file configuration formats, such as: YML, XML, etc

You are welcome to follow or contribute your code at github.com/apache/dubb…