MQ (Message Queue) is a commonly-used asynchronous RPC technology. This article explains how to conduct traffic control settings with standard configuration naming format, by taking traffic control over MQ as an example.
How configuration convention issues arise
For single attribute configuration of a single application, you can directly use the following configuration file, without any configuration convention issues.
//Configuration directory structure --app |--src |--config |--application.properties //Configuration content RCV_INTERVAL_TIME=20
However, when writing distributed rules for distributed PaaS services, the PaaS service provider (rather than the application party) often encounters many problems when designing the configuration. Some of the issues in the MQ traffic control scenario are:
- How to distinguish global configuration from local application configuration: For example, how can a PaaS service provider conduct global rule configuration and application-specific configuration when managing services provided by the platform.
- How to distinguish MQ services of different clusters: For example, how to distinguish configuration of MQ1 Cluster from MQ2 Cluster when the configuration naming is consistent?
- How to use one configuration center to isolate different environments such as Dev, Test, Staging, and Prod?
The preceding MQ traffic control scenario is illustrated as follows:
Obviously, improper configuration naming conventions will jeopardize the preceding configuration's usibility.
The next part covers the best practices of the configuration center. Before talking about the configuration naming conventions, it’s necessary to understand the configuration structure organizing capability of the configuration center.
Configuration structure functions of the configuration center
In addition to centralized configuration management and subscription push, the configuration center also has the configuration structuring capability to help the administrator greatly simplify configuration management in various complex application scenarios.
Description of the configuration center's configuration structuring capability
- Tenant isolation: The configuration center has the capability to isolate configuration based on users and scenarios. With tenant isolation, different configurations in different tenants can have the same name but different authentication mechanisms.
- Minimal configuration set: The configuration center combines several configurations into a configuration set. Modifying and publishing different configurations in a minimal configuration set allows unified publishing of similar configurations, and is convenient for central handling of applications. Configuration path, similar to file path or network domain name, decides the hierarchical relationship between different configuration sets.
- Key-Value form of a specific configuration: Users can set specific configuration content in the configuration center.
Comparison between different cofnfiguration centers with configuration structuring capabilities
To give you a more straightforward impression, we compared several configuration center products:
- Alibaba Cloud ACM: Alibaba Cloud Application Configuration Management, formerly known as Diamond, is the earliest configuration center product in China. Alibaba Cloud ACM currently has different open-source versions on Git. It also has an enterprise version available from Alibaba Cloud.
- Spring Cloud Config: Spring Cloud official configuration center tool, mainly used in the Java Spring industry.
- ZooKeeper: With partial configuration center capabilities, ZooKeeper is positioned in distributed coordination information management, and can only be used as a configuration center for a moderate application scale. Considering its wide application scope, we included it in the comparison.
Comparison details are as follows:
|Functions||ACM||Spring Cloud Config||ZooKeeper|
|Tenant-based isolation||Namespace and Group isolation. Different Namespaces require different AK/SK authentications, which are not required for Group.||A Git project is a tenant.||No readily available tenant isolation technology.|
|Minimal configuration set||The configuration set marked with DataID is the minimal configuration set. The configuration set doesn’t have the concept of path, but can be queried by using wildcard characters if the configuration set is properly designed. In this way, the similar effect of a configuration path can be achieved.||A configuration file in a Git project is the minimal configuration set, and doesn’t have the concept of configuration path.||Znode is the minimal configuration set, and has the concept of configuration path.|
|Key-Value configuration||KV content is assembled by the user at will under DataID in any formats, such as properties, Json, XML, and so on. Validation function is provided on the management page.||Set KV by using the properties configuration file.||Set KV by setting the Value of Znode, and the content format is not restricted.|
To sum up, ACM has a relatively higher degree of flexibility in both tenant isolation and minimal configuration set. The next part covers how to use ACM's Namespace, Group, DataID and other configuration functions to design a suitable configuration structure to implement QoS traffic control policies.
Best practices for distributed service configuration design based on the configuration center
To meet functional needs of MQ configuration, we can use the following configuration methods in combination with the ACM features.
Isolate MQ configurations for different environments with different namespaces. For example:
- Use ProdEnv namespace for the production environment, TestEnv for the test environment, and DevENV for the development environment.
- Different environments are automatically isolated with AK/SK, which further enhances the security.
MQ services provided by different clusters are distinguished with Group to isolate configurations and simplify the access methods.
For example, for MQ clusters that specifically serve the subordinate departments and core transaction departments, as well as MQ clusters that specifically serve the subordinate departments and transaction departments, we can use Group to distinguish different global configurations. By doing this, all applications use the same company's/subsidiary's AK/SK (or similar authentication system key) in the production system, which simplifies the deployment, effectively isolates the configurations of different clusters, and reduces the configuration complexity.
DataID: mq.global.qos Group: Trading DataID: mq.global.qos Group: ProductCategory
Global configurations are stored in the form of configuration items with unified DataIDs.
Wherein, the configuration ID begins with
globalindicates global configuration,
qosindicates qos configuration, and default value can be used for Group.
DataID: mq.global.qos Group: Default_Group
Application local configuration IDs are named with the same prefix qos.*
Configuration Ids begin with
app.[appname]stands for the app configuration item to be reloaded, and default value can be used for Group.
DataID: mq.app.app1.qos Group: Default_Group DataID: mq.app.app2.qos Group: Default_Group
Settings of KVs for specific configurations
For many configuration center products, such as Apollo, ACM System Manager Parameter Store, a specific configuration is the configuration center's smallest management unit. You need to set KVs of configurations one by one at a certain level. However, ACM doesn’t impose this restriction. Two common practices are:
- Similar to the preceding configuration center, save each key to a unique DataID. For example:
- Set mq.global.qos.RCV_INTERVAL_TIME to 50
- Set mq.global.qos.MAX_THREAD to 20
Combine common configurations into the same DataID, and save them in the same configuration file (supported formats are Properties, Json, XML, and so on)
For example, setting of mq.global.qos is as follows:
//MQ traffic control QoS settings RCV_INTERVAL_TIME = 50 MAX_THREAD = 20
In practice we found that the second method is more efficient. In addition to higher degree of flexibility, it has another advantage that multiple configurations can be published simultaneously after one update, which reduces performance cost and achieves an atomic operation effect of batch changes.
Configuration structure diagram
Configuration structure diagram of the preceding design is shown as follows:
Advantages of the scheme
Isolating configurations for different environments with Namespaces allows MQ configuration items to use the same names in different Namespaces. Different namespaces are isolated by the administrator, program AK/SK, and permission settings, allowing you to centrally manage configuration items without affecting other environments.
Isolating different clusters in the same environment by using Groups ensures the configuration consistency of different clusters (for example the configuration name doesn’t change), simplifies code, and logically isolates different cluster configurations.
Standard naming settings of the minimal configuration set DataIDs allow MQ clients to conveniently find both the MQ default global configurations, and their own application-specific configurations. In addition, the administrator can search with prefix wildcard characters at the ACM Portal to conveniently find all rules corresponding to all MQs, which makes configuration management much easier. Example:
For more information about ACM configuration structure and naming conventions, see:
- Application Configuration Management (ACM) official website
- Alibaba Cloud ACM official document: Configuration change risk management