Spring Cloud Combat and thinking (i) Spring Config global configuration scheme design

Spring Cloud 's Configuration Center tool, Spring Cloud Config, provides a centralized management solution for distributed system profiles. The tool is powerful and easy to implement. Many development tutorials and use cases can be found on the web. This is not a way to share the development of Spring Cloud Config, but rather to talk about its use.

Any tool no matter how powerful and convenient, if used badly, also can not achieve the desired effect. With Spring Cloud config, I expect the profile management system built on this tool to do the following:

1. The configuration items for each instance in the MicroServices are centralized in the configuration center. Operators do not need to link to each of the distributed nodes individually, and are able to modify all configuration items in the MicroServices instance in the configuration center.
2. The configuration item information source should be single. The same configuration item does not appear in two sources. The same configuration item in two sources does not have the same value, causing confusion in the business logic.

In the "Spring Cloud Config" instance that is commonly seen online, the "config client" local configuration file "Bootstrap.properties" is as follows:

the micro-service port number "8001" and the instance name "booking-server" Configuration items in the file are actually subject to change. For example, increase or decrease the micro service instance, the port number is occupied, the new micro service type and other scenarios. Therefore, placing them in a local configuration file does not satisfy the first requirement. In addition, in order to meet the second requirement, you need to classify the configuration items into different configuration files according to their scope of use:

1) configuration items shared by all microservices instances, such as common.properties

2) configuration items shared by similar microservices instances, such as booking-common.properties

3) configuration items that are exclusive to specific microservices instances, such as booking-server-a.properties,booking-server-b.properties

This requires that the MicroServices instance be able to load multiple remote configuration files. The above configuration is to use the microservices name "booking-server" to map to the "booking-server-dev.properties" configuration file in the configuration center. Limits the number and name of the loaded profiles. The second requirement cannot be met.

Now take the booking micro-service Dev version as an example to modify the above configuration file:

2. The microservices port number "Server.port" is an instance-exclusive configuration item that puts "server.port" in the "booking-server-a.properties" configuration file.
4. The Micro service name "spring.application.name" is a configuration item shared by each instance of the booking class service, putting "spring.application.name" into " booking-common.properties"in the configuration file.
6. The Service registry address configuration item "Eureka.client.serviceUrl.deaultZone" can only remain in the local configuration file.
8. The Configuration Center microservices name "Spring.cloud.config.discovery.service-id" can only remain in the local configuration file.
10. Place the configuration items shared by the MicroServices booking with other microservices in the "common.properties" configuration file.
12. Use the "spring.cloud.config.name" configuration item to load both "common.properties", "booking-common.properties", and "booking-server-a.properties" configuration file.

The modified configuration file is as follows:

Common-dev.properties configuration file:

booking-common-dev.properties configuration file:

booking-server-a-dev.properties configuration file:

"booking-server-a" local "bootstrap.properties" configuration file:

The local configuration file for "booking" microservices instance a is now streamlined, preserving only the necessary configuration items. These configuration items are required to indicate how theconfig clientlocates theconfig serverand which configuration files should be loaded. In addition, the configuration items "spring.cloud.config.name" and "spring.cloud.config.profile" Configuration items can be placed on the command line that launches the microservices. This allows you to compile a common jar package, starting with different command line parameters as a different microservices instance.

Re-streamline the local "bootstrap.properties" configuration file:

To start the "booking" micro-service a command:

Java-jar. \booking-server.jar--spring.cloud.config.name=common,booking-common,booking-server-a-- Spring.cloud.config.profile=dev

What this article is talking about is relatively simple. The main idea is to share a way of usingSpring Cloud config.

Spring Cloud Combat and thinking (i) Spring Config global configuration scheme design