As online projects become larger and larger, each project is scattered with various configuration files. If a distributed development mode is adopted, the required configuration files will continue to increase as the number of services increases. Changes in a certain basic service information will cause a series of updates and restarts, and operation and maintenance are miserable and error-prone. Configuration Center is a panacea to solve such problems.
There are many open source configuration centers on the market, each of which has been published by BAT, 360's QConf, Taobao's diamond, and Baidu's disconf are all solutions to such problems. There are also many open source configuration centers Apache Commons Configuration, owner, cfg4j and so on abroad. These open source software and solutions are excellent, but my favorite is Spring Cloud Config, because it is comprehensive and powerful, and can be seamlessly combined with the spring system. It is convenient, simple, and beautiful. I like it.
Spring Cloud Config
Before we understand spring cloud config, I can think about what the core functions provided by a configuration center should be
- Provides server and client support
- Centrally manage configuration files across environments
- After the configuration file is modified, it can take effect quickly
- Version management possible
- Supports large concurrent queries
- Support various languages
Spring Cloud Config can perfectly support all the above requirements.
The Spring Cloud Config project is a configuration management solution for distributed systems. It consists of two parts: Client and Server. The server provides storage of configuration files and provides the content of the configuration files in the form of interfaces. The client obtains data through the interface and initializes its own application based on this data. Spring cloud uses git or svn to store configuration files. By default, git is used. Let's take git as an example to make a set of examples.
First, a folder config-repo is created on github to store configuration files. In order to simulate the production environment, we create the following three configuration files:
// development environment neo-config- dev.properties // test environment neo-config- test.properties // production environment neo-config-pro.properties
A property neo.hello is written in each configuration file, and the property value is hello im dev/test/pro. Next we start to configure the server side
server side
1. Add dependencies
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
</dependencies>
Just add the spring-cloud-config-server package reference.
2. Configuration file
server: port: 8040 spring: application: name: spring-cloud-config-server cloud: config: server: git: uri: https: // github.com/ityouknow/spring-cloud-starter/ # Configure the address of the git repository search-paths: config- repo # The relative address under the address of the git repository, you can configure multiple, use, and split. username: # git repository account password: # git repository password
Spring Cloud Config also provides a way to store configuration locally. We just need to set the properties spring.profiles.active=native, and the Config Server will src/main/resourceretrieve the configuration files from the application's directory by default. The location of the configuration file can also be specified via spring.cloud.config.server.native.searchLocations=file:E:/properties/properties. Although Spring Cloud Config provides such a function, in order to support better content management and version control functions, it is recommended to use git.
3. Startup class
Start class addition @EnableConfigServer, activate support for configuration center
@EnableConfigServer @SpringBootApplication public class ConfigServerApplication { public static void main(String[] args) { SpringApplication.run(ConfigServerApplication.class, args); } }
At this point, the server-side related configuration has been completed
4. Test
First of all, we need to test whether the server side can read the configuration information on github and directly access:http://localhost:8001/neo-config/dev
The returned information is as follows:
{ "name": "neo-config", "profiles": [ "dev" ], "label": null, "version": null, "state": null, "propertySources": [ { "name": "https://github.com/ityouknow/spring-cloud-starter/config-repo/neo-config-dev.properties", "source": { "neo.hello": "hello im dev" } } ] }
The above returned information includes the location, version, name of the configuration file, and the specific content of the configuration file, indicating that the server has successfully obtained the configuration information of the git repository.
If you directly view the configuration information in the configuration file, you can access: http://localhost:8001/neo-config-dev.properties, return:neo.hello: hello im dev
Modify neo-config-dev.propertiesthe configuration information in the configuration file as: neo.hello=hello im dev update, access it in the browser again http://localhost:8001/neo-config-dev.properties, and return to: neo.hello: hello im dev update. Note that the server side will automatically read the latest submitted content
The configuration file in the warehouse will be converted into a web interface, and the following rules can be followed for access:
- /{application}/{profile}[/{label}]
- /{application}-{profile}.yml
- /{label}/{application}-{profile}.yml
- /{application}-{profile}.properties
- /{label}/{application}-{profile}.properties
Take neo-config-dev.properties as an example, its application is neo-config, and its profile is dev. The client will choose to read the corresponding configuration according to the filled parameters.
client side
It mainly shows how to obtain server-side configuration information in business projects
1. Add dependencies
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
Introduce spring-boot-starter-web package to facilitate web testing
2. Configuration file
Two configuration files need to be configured, application.properties and bootstrap.properties
application.properties is as follows:
spring.application.name=spring-cloud-config-client
server.port=8002
bootstrap.properties is as follows:
spring.cloud.config.name=neo-config spring.cloud.config.profile=dev spring.cloud.config.uri=http://localhost:8001/ spring.cloud.config.label=master
- spring.application.name: corresponds to the {application} part
- spring.cloud.config.profile: corresponds to the {profile} section
- spring.cloud.config.label: The branch corresponding to git. This parameter is useless if the configuration center is using local storage
- spring.cloud.config.uri: The specific address of the configuration center
- spring.cloud.config.discovery.service-id: Specifies the service-id of the configuration center, which is easy to expand into a high-availability configuration cluster.
Special Note: The above properties related to spring-cloud must be configured in bootstrap.properties, so that the config part can be loaded correctly. Because the relevant configuration of config will precede application.properties, and the loading of bootstrap.properties will also precede application.properties.
3. Startup class
Start class addition @EnableConfigServer, activate support for configuration center
@SpringBootApplication public class ConfigClientApplication { public static void main(String[] args) { SpringApplication.run(ConfigClientApplication.class, args); } }
The startup class only needs to be @SpringBootApplicationannotated
4. Web testing
Use @Valueannotations to get the value of server-side parameters
@RestController class HelloController { @Value("${neo.hello}") private String hello; @RequestMapping("/hello") public String from() { return this.hello; } }
After starting the project, access: http://localhost:8002/hello, return: hello im dev updateThe parameters have been correctly obtained from the server side. At this point, a complete server provides configuration services, and the example of the client obtaining configuration parameters is completed.
We are conducting some small experiments. neo-config-dev.propertiesThe configuration information in manual modification is: neo.hello=hello im dev update1submit to github, access it in the browser again http://localhost:8002/hello, and return: neo.hello: hello im dev update, indicating that the obtained information is still the old parameter, why is this? Because the springboot project only obtains the value of the configuration file when it is started, after modifying the github information, the client does not obtain it at the next time, which leads to this problem. How to solve this problem? We'll leave it to the next chapter to introduce it.