Spring Cloud Configuration Center Spring Cloud Config

1. Introduction to Spring Cloud Config

Spring Cloud Config provides external configuration support for distributed systems for the server and client. The configuration server provides a centralized external configuration for all environments of each application. Spring Cloud Config has features such as centralization, version control, support for dynamic updates, and language independence. The configuration server uses Git to store configuration information by default. Using Git as the back-end storage for configuration is helpful for version management of the environment configuration, and it is also convenient for related personnel to manage and access. At the same time, the configuration server also supports storage configuration methods such as SVN, local files, JDBC, Redis, AWS S3, and CredHub.

1.1, Spring Cloud Config system architecture

1.2, distributed configuration workflow

In Spring Cloud Config, there are two types of roles: client and server. The server mainly provides the ability to centrally manage configuration resources and a variety of storage configuration information methods. The configuration server can easily integrate the registry to build a highly available configuration service. The client mainly refers to those application services that need to use these configuration files. Let's sort out the workflow first, and refer to the system architecture diagram above:

First, the server is started, and the configuration information under Git or other storage methods is not loaded by default.

Then, when the client starts, it will send the configuration server according to the application name (spring. application.name), environment name (spring.profiles.active), and version branch (spring.cloud.config.label) configured in bootstrap.properties Request configuration data.

Then, the server will load the configuration information according to the application name, environment name, and version branch, and pull the loaded information to the local to establish a local cache.

Then, create a Spring ApplicationContext instance based on the pulled information, and return the configuration information to the client.

Finally, after the client obtains the configuration information, it loads the configuration data into its own context (the configuration information has a higher priority than the local configuration information).

2. Build a configuration server-config-server

The configuration service can be built on the basis of an existing application, or a separate configuration service application can be built. Here we choose the latter. Here choose to use the default Git as the configuration information storage method. Prepared Git repository: https://gitee.com/hsh2015/qriver-cloud-learning.git, the configuration file is as follows:

2.1, add pom dependency

Among them, spring-cloud-config-server is the core dependency, and spring-cloud-starter-netflix-eureka-client is introduced in order to register the configuration service to the registry.

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

2.2, modify the application.properties file

spring.application.name=config-server
server.port=8090

#设置与Eureka Server交互的地址。
eureka.client.serviceUrl.defaultZone=http://127.0.0.1:8000/eureka/

#git地址
spring.cloud.config.server.git.uri=https://gitee.com/hsh2015/qriver-cloud-learning.git
#git用户名
spring.cloud.config.server.git.username=xxx
#git密码
spring.cloud.config.server.git.password=xxx
#指定配置文件的存储目录
spring.cloud.config.server.git.search-paths=config-repo

In the above configuration information:

spring.cloud.config.server.git.uri corresponds to the Git warehouse address
spring.cloud.config.server.git.username corresponds to the Git username
spring.cloud.config.server.git.password corresponds to the Git password (if you use a public Git repository, you can omit the username and password)
spring.cloud.config.server.git.search-paths corresponds to the search directory, that is, if the configuration file is in the root directory of the Git repository, no configuration is required. If the configuration file is in a specific subdirectory, it can be specified by the searchPaths property The directory

2.3, create a startup class

The registration service function is mainly enabled through the @EnableConfigServer annotation, and the service registration is performed through the @EnableDiscoveryClient annotation.

@SpringBootApplication
@EnableConfigServer
@EnableDiscoveryClient
public class ConfigServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }

}

2.4, start, verify

After completing the above configuration, we can verify by visiting http://localhost:8090/config-clientA/dev/master, the following content will be output on the page, indicating that the configuration server is successfully built.

{"name":"config-clientA","profiles":["dev"],"label":"master","version":"a6cc89b37c925028c428b4c18ee13f391d1a0004","state":null,"propertySources":[{"name":"https://gitee.com/hsh2015/qriver-cloud-learning.git/config-repo/config-clientA-dev.properties","source":{"logging.level.org.springframework":"debug"}},{"name":"https://gitee.com/hsh2015/qriver-cloud-learning.git/config-repo/config-clientA.properties","source":{"logging.level.org.springframework":"error"}}]}

Access path format: /{application}/{profile}[/{label}], where application, profile, and label correspond to application name, environment name, and branch version respectively. The default value of profile is default, and the default value of label is master.

3. Client application configuration

Clients are application services that use distributed configuration information, and are generally other microservices in a distributed system. Create a config-clientA application here to demonstrate how to use the client.

3.1, add dependency

On the basis of the original pom file, just introduce config related dependencies, as shown below:

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

3.2. Modify the bootstrap.properties configuration file. Note that it is the bootstrap.properties file, not the application. properties file.

spring.application.name=config-clientA
server.port=8091


eureka.client.serviceUrl.defaultZone=http://127.0.0.1:8000/eureka/

#spring.cloud.config.uri=http://127.0.0.1:8090

spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=config-server
spring.cloud.config.profile=dev
spring.cloud.config.label=master

among them

spring.cloud.config.discovery.enabled means to enable configuration information discovery
spring.cloud.config.discovery.serviceId represents the service-id of the configuration center, which is easy to expand into a highly available configuration cluster. Generally, only the spring.application.name property of the server is configured. If you connect to a single configuration server instance, you can use spring.cloud.config.uri configuration.
spring.cloud.config.profile represents the {profile} part of the configuration file
spring.cloud.config.label represents the Git branch of the configuration file

It should be noted here : The naming convention of the configuration file in the Git repository: {application}-{profile}.properties or {application}-{profile}.yml, where application is the parameter value corresponding to the client's spring.application.name .

3.3, start class

This startup class does not require special processing because of the use of distributed configuration information, it is a normal startup class.

3.4, enable verification

Because profile=dev is used in the bootstrap.properties configuration file, config-clientA-dev.properties will be used, and the spring Debug mode is enabled in this configuration. After starting the client service, you will find that the console will print Spring's Debug level log, the default is Info level.

4. Server-side high availability

The high availability problem of the configuration server is a problem that must be considered and solved in the production environment, because the configuration service affects the overall situation, and if it is unavailable, it may cause a production accident.

How to achieve high availability of configuration services, in fact, in the previous examples, we have applied the relevant knowledge points, that is, register the configuration service instance to the registry, and the client discovers and uses the corresponding service through the registry. If we start multiple configuration service instances, and then register to the registry, and the client just makes service calls based on the service name, this time actually achieves a highly available configuration.

5. Client-configuration refresh

In the above client application, we add a test class ConfigTestController to verify the parameters in the configuration file, as shown below:

@RestController
//@RefreshScope
public class ConfigTestController {

    @Value("${test.config}")
    private String testStr;

    @RequestMapping("getStr")
    public String getTestStr(){
        return testStr;
    }
}

You need to add the corresponding test.config attribute in the configuration file corresponding to the Git library, as shown below:

#自定义，测试数据
test.config = bbb

Restart the client service, visit http://localhost:8091/getStr, the string "bbb" is returned on the page. Then, modify the above-mentioned test.config attribute value to aaa, and then visit http://localhost:8091/getStr, and find that the return is still "bbb", why is this? If at this time, we check the configuration file of the server through http://localhost:8090/config-clientA/dev/master and find that it has been modified, it means that the client service has not monitored the configuration information changes. We can provide the function of refreshing the configuration by introducing the spring-boot-starter-actuator dependency.

5.1, modify the pom configuration

First, introduce actuator related dependencies in the pom file, as shown below:

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

5.2. Then modify the ConfigTestController class and add @RefreshScope annotation to the class

5.3, modify the bootstrap.properties configuration file

If you do not add the following configuration, you will get a 404 error when you visit http://localhost:8091/actuator/refresh.

#actuator相关配置
management.endpoints.web.exposure.include=*

5.4, verify configuration refresh

After restarting, every time you modify the Git configuration, visit http://localhost:8091/actuator/refresh to refresh the configuration, and then when you visit again, you will find that you can see the latest modified information. At this time, it means that the modification has been obtained by the client. However, if you are interested in children's shoes, it is troublesome to refresh through /actuator/refresh every time. If there are many client services, do you need to complete all client services every time Refresh it again? The answer is of course no. Later, we will continue to learn how to combine Spring Cloud Bus to implement notification of configuration information changes in the form of a message bus to complete automatic updates on the cluster.