Spring Cloud Config implements distributed configuration center

In distributed systems, configuration files are scattered in each project, making it difficult to centrally manage, or if the configuration is modified, it needs to be restarted before it can take effect. Next, we use Spring Cloud Config to solve this pain point.

Config Server

We use config-server as the Config Server and only need to add dependencies:

 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId></dependency>

In application.yml, configure:

 spring: application: name: config-server # Name cloud: config: server: git: uri: file://Users/yangdd/Documents/code/GitHub/config-repo # Use local repository (for testing), format: file://${user.home}/config-repo If it is Windows, it is file://${user.home}/config-repo #uri: https://github.com/yangdd1205/spring-cloud-master/ #username: Username#password: Password#default-label: config # Can be commit id, branch name, tag name, the default value is master #search-paths: # In other words, in addition to searching for configuration files in the root directory, you can also search in the following directory #- user server: port: 4001 # port

Spring projects generally have the principle of "convention is greater than configuration". Therefore, the configuration files in our Git are generally named after {application}-{profile}.yml or {application}-{profile}.properties.

1. {application} Map to client spring.application.name property value
2. {profile} maps to client spring.profiles.active property value

We have two files client-dev.yml in the master branch of config-repo:

 info: master-dev

client-prod.yml:

 info: master-prod

In the config branch, there are two file client-dev.yml:

 info: config-dev

client-prod.yml:

 info: config-prod

Start config-server We can access the configuration files in Git through the following mapping relationship:

 /{application}/{profile}[/{label}]/{application}-{profile}.yml/{label}/{application}-{profile}.yml/{application}-{profile}.yml/{application}-{profile}.properties/{label}/{application}-{profile}.properties

http://localhost:4001/client-dev.yml

Config Client

We use config-client as the Config Client and add dependencies:

 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId></dependency>

Configure in bootstrap.yml (bootstrap.yml will load before application.yml):

 spring: application: name: client cloud: config: uri: http://localhost:4001/ ## represents the address of the configuration center profile: dev # is equivalent to the spring.profiles.active attribute, but the priority is higher than spring.profiles.active #label: config # If you do not specify the use of label in the server, if specified, the client server: port: 4002 # port

Create a TestController in config-client:

 @RestControllerpublic class TestController { @Value("${info}") private String info; @RequestMapping(value = "/getInfo") public String getInfo() { return this.info; }}

Visit http://localhost:4002/getInfo

Modify the profile in the config-client configuration file to prod and access it to view the results.

Now we have implemented the configuration files to manage them in a unified manner, but after modifying the configuration files, how can we not restart and take effect?

We introduce dependencies in config-client:

 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId></dependency>

Add the annotation @RefreshScope to the class that needs dynamic refresh, here we add it to the TestController. And disable the actuator's permission authentication in the configuration file:

 management: security: enabled: false

Restart the project, http://localhost:4002/getInfo The result is: config-dev, and now modify the config-dev.yml file:

 info: config-dev-1.0

Call the actuator method and refresh manually. http://localhost:4002/refresh Note: It must be POST method. You can see what changes are:

 [ "info"]

Visit http://localhost:4002/getInfo again and the result is: config-dev-1.0.

We found that although the configuration can be refreshed dynamically, the refresh method must be manually called every time. If I have 1,000 services, I have to call it 1,000 times. Is there a better way? That is to use it in conjunction with Spring Cloud Bus.

Highly available

Now our Config Server is a single-point service, and once the latter Config Client is hung up, it will not be used. So in the generation, the Config Server must be highly available, so how to do it? It's very simple. Just like the high availability of Eureka mentioned earlier, you only need to deploy several more Config Server.

We use the project eureka as the registration center with the port: 7001.

Copy config-server to config-server-1, with port: 4003, and register both Config Servers to the registry center.

Register config-client to the registry and specify to get the Config Server from Eureka:

 spring: cloud: config: #uri: http://localhost:4001/ ## represents the address of the configuration center, directly specify the Config Server address profile: dev #label: config discovery: enabled: true # Enable to obtain the Config Server service-id: config-server # Config Server service name

The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.