Article Directory
(1) The problem of local configuration
1.
Dynamic update of configuration In practical applications, there will be requirements for dynamic update of the configuration, such as modifying the service connection address and current limiting configuration. In the traditional mode, you need to manually modify the configuration file and restart the application to take effect. This method is too inefficient, and restarting will also cause the service to be temporarily unavailable.
2. Centralized configuration management
In the microservice architecture, some core services will deploy hundreds of nodes in order to ensure high performance. If a configuration file is maintained in each node, once a certain attribute in the configuration file needs to be modified, As you can imagine, the workload is huge.
3. The security and authority of the configuration content The
configuration files are submitted to the code base along with the source code, which is likely to cause data leakage of the configuration information of the production environment.
4. Configuration management
in different deployment environments As mentioned earlier, the profile mechanism is used to manage configurations in different environments. This method is cumbersome for daily maintenance.
(2) Nacos Configuration Center
(1) Basic introduction
There are many open source solutions in the configuration center, such as ZooKeeper, Disconf, Apollo, Spring Cloud Config, QConf, Nacos, etc. Similarly, no matter what kind of solution, its core function will not change.
Nacos is Alibaba's open source middleware. We know that there are two modules in the architecture diagram of Nacos, namely Config Service and Naming Service. Among them, Config Service is the core module used by Nacos to implement the configuration center. It implements functions such as CRUD, version management, gray management, monitoring management, push trajectory, and data aggregation for configuration. We mainly focus on the in-depth analysis of the Config Service module in Nacos to realize the function of the configuration center.
(2) Configure YAML file extension based on Data ID
When Spring Cloud Alibaba Nacos Config loads the configuration from Nacos Config Server, it will match the Data ID. In the implementation of SpringCloud Nacos, the default rule for Data ID is
By default, it will go to the Nacos server to load the Data ID to
$(spring.application.name}.${
file-extension : properties}
Basic configuration for the prefix.
For example, when we configure properties in the bootstrap.properties file
spring.application.name=spring-cloud-nacos-config-sample
When the Data ID prefix is not specified through spring.cloud.nacos.configprefix,
the configuration information with the Data ID of spring-cloud-nacos-config-sample.properties in the Nacos Config Server will be read by default .
If the spring.cloud.nacos.config.prefix=example property is explicitly specified, the configuration with Data ID=example will be loaded.
spring.profile.active represents multi-environment support, which is also applicable to Nacos
In practical applications, if you use YAML configuration format, Nacos Config also provides YAML configuration format support. The steps are as follows.
Declare
spring.cloud.nacos.config.file-extension=yaml in bootstrap.properties
(3) Configuration switching of different environments
In Spring Boot, configuration switching in different environments can be realized based on spring.profiles.active, which is more used in actual work. Many companies have development environments, test environments, production environments, etc. Services are deployed in different environments, and some configurations are different, so we hope to be able to easily specify the current application deployment environment through a property, and according to different The environment loads the corresponding configuration. The configuration steps for multi-environment support based on the Spring Boot project are as follows.
When loading the configuration in Nacos Config Server in Spring Cloud Alibaba Nacos Config, not only Data ID is loaded
$(spring.application.name}.${
file-extension : properties}
Is the basic configuration of the prefix, and also loads the Data ID as
$(spring.applicationname)}-${profile}.$(file-extension : properties}
The basic configuration of this method provides very good support for switching between different environments.
Example: where oauth-center is the name corresponding to spring.applicationname in the configuration file, dev corresponds to profile, and yaml corresponds to file-extension
The configuration method is the same as Spring Boot, and the specific implementation steps are as follows.
Declare spring.profiles.active=prod in bootstrap.properties. It should be noted that it must be declared in bootstrap.properties.
There is no difference between switching between different environments based on Nacos Config and switching between different environments of local configuration. If we need to switch to the test environment, we only need to modify spring.profiles.active=test. However, the configuration of this property is hard-coded in the bootstrap.properties file, and it is very troublesome to modify. The usual practice is to specify the environment through the -Dspring.profiles.active=${profile} parameter to achieve the purpose of flexible switching.
(Three) Nacos Config realization principle analysis
（1）SDK和OpenAPI
Document reference address:
https://nacos.io/zh-cn/docs/sdk.html
https://nacos.io/zh-cn/docs/open-api.html
【获取配置】
public String getConfig(String dataId, String group, long timeoutMs) throws NacosException
/nacos/v1/cs/configs GET
【监听配置】
public void addListener(String dataId, String group, Listener listener)
/nacos/v1/cs/configs/listener post
【删除监听】
public void removeListener(String dataId, String group, Listener listener)
【发布配置】
public boolean publishConfig(String dataId, String group, String content) throws NacosException;
@Since 1.4.1
public boolean publishConfig(String dataId, String group, String content, String type) throws NacosException;
/nacos/v1/cs/configs POST
【删除配置】
public boolean removeConfig(String dataId, String group) throws NacosException
/nacos/v1/cs/configs DELETE
(2) Configured CRUD
For Nacos Config, it actually provides the centralized management function of configuration, and then provides CRUD access interface to the outside so that the application system can complete the basic operation of configuration. In fact, this scenario is not complicated. For the server, it is nothing more than how the configuration is stored and whether it needs to be persisted. For the client, it is to query the corresponding data from the server through the interface, and then return.
It should be noted that the data storage of the Nacos server uses the Derby database by default. In addition, it supports the MySQL database. If you need to modify it, customize it to the configuration of the MySQL database.
(3) Pull Or Push for dynamic monitoring
When the configuration on the Nacos Config Server changes, the relevant application needs to be aware of the configuration change and then the application change, which requires the client to monitor the configuration of interest. So how does the Nacos client implement real-time updates of configuration changes?
Generally speaking, the data interaction between the client and the server is nothing more than two ways: Pull and Push.
1. Pull means that the client actively pulls data from the server.
2. Push means that the server actively pushes data to the client.
There is no difference between these two methods. It just depends on which method is more suitable for the current scene. For example, ActiveMQ supports Push and Pull modes. Users can choose different modes in specific scenarios to obtain consumer messages.
For Push mode, the server needs to maintain a long connection with the client. If the number of clients is large, the server needs to consume a lot of memory resources to save each connection, and in order to check the validity of the connection, a heartbeat mechanism is also needed. To maintain the state of each connection.
In Pull mode, the client needs to periodically pull data from the server once. Since there will be a certain time interval for the timing task, the real-time nature of the data cannot be guaranteed. And when the server configuration is not updated for a long time, the client's timing tasks will do some invalid Pull
Nacos uses the Pull mode, but it is not a simple Pull, but a long polling mechanism, which combines the advantages of Push and Pull. The client uses a long polling method to periodically initiate a pull request to check whether the server configuration information has changed. If there is a change, the client will obtain the latest configuration based on the changed data. The so-called long polling means that after the client initiates a polling request, if there is a configuration change on the server side, it will return directly.
If after the client initiates a pull request, it is found that the configuration of the server and the configuration of the client are consistent, then the server will first "Hold" the request, that is, the server will not be in the specified period of time after the connection is obtained. Return the result. Until the configuration changes during this period, the server will return the original "Hold" request. As shown in the figure, after the Nacos server receives the request, it will first check whether the configuration has changed. If not, Set up a timed task, postpone the execution for 29.5s, and add the current client long-polling connection to the allSubs queue. At this time, there are two ways to trigger the return of the connection result:
The first is to trigger the automatic check mechanism after waiting for 29.5s. At this time, no matter whether the configuration has changed, the result will be returned to the client. And 29.5s is the duration of this long connection.
The second is to modify the configuration through Nacos Dashboard or API at any time within 29.5s. This will trigger an event mechanism. The task that listens to the event will traverse the allSubs queue and find the corresponding configuration item that has changed. In the ClientLongPolling task, the changed data is returned through the connection in the task, and a "push" operation is completed.
This not only ensures that the client is aware of configuration changes in real time, but also reduces the pressure on the server. Among them, the session timeout period of this long connection is 30s by default.