Getting started with Spring Cloud (ten): Config unified configuration center

Introduction to SpringCloud Config

　　In a distributed system, because there are too many service components, in order to facilitate the unified management and real-time update of service configuration files in an environment where the contention is different, distributed configuration center components have appeared. There are many open source configuration centers on the market, 360 QConf, Taobao diamond, and Baidu disconf all solve this type of problem. There are also many open source configuration centers Apache Commons Configuration, etc. abroad. SpringCloud Config is used in SpringCloud.

　　SpringCloud Config is divided into two parts: Config Server and Config Client, which provides support for external configuration of distributed systems. Because both Config Server and Config Client implement the abstract mapping of Spring Environment and PropertySource, Spring Cloud Config is very suitable for Spring applications, and of course can also be used with other language applications.

　　Config Server is a horizontally extensible and centralized configuration server, which is used to centrally manage the configuration (development, testing, production, grayscale) of each application environment, and uses Git to store configuration content by default (Subversion, local File system or Vault storage configuration), so you can easily implement configuration version control and content audit. Config Client is the client of Config Server, used to operate the configuration properties stored in Config Server.

Convenience brought by SpringCloud Config

1. Centralized management configuration, through Config to centrally manage the configuration information of all component services in the cluster;

2. Strive for different configurations for different environments (development, joint debugging, testing, grayscale, production);

3. It can be dynamically adjusted during operation, and the connection pool information or fuse threshold can be dynamically set according to the load of the server;

4. After the configuration is modified, the configuration can be updated automatically without shutting down the service;

Getting started with SpringCloud Config

1. Apply for your own git repository and upload the yml or properties file of the test project to the Git directory;

2. Build Config Service

<!- 1 , Introduce Jar package->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

<!- 2 , configuration attribute information->
server:
  port: 9005
spring:
  application:
    name: ms-cfg-service
  cloud:
    config:
      server:
        git:
          uri: https: // gitee.com/******/springcloudconfig.git 
          username: ****** 
          password: ****** 

<!-3, add annotation @EnableConfigServer->

@SpringBootApplication
@EnableConfigServer
public class ConfigServiceApplication {

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

Note: There are three ways to access the configuration file, namely:

1) Access through application- {profiles} .yml, eg: http: // localhost: 8080 / application-dev.yml

2) Access through / application / {profiles} / {lable}, eg: http: // localhost: 8080 / application / dev / master

3) Access via /{lable}/application-{profiles}.yml, eg: http: // localhost: 8080 / master / application-dev.yml

3. Build Config Client

<!-1. Introduce Jar package->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>

<!-2. Create a configuration file bootstrap.yml->
spring:
  application:
    name: application
  cloud:
    config:
      uri: http://localhost:8080/
      profile: dev  
      label: master

Remarks: spring.application.name corresponds to {application} in the access rule

　　　 spring.cloud.config.profile corresponds to {profiles} in access rules

　　　 spring.cloud.config.label corresponds to {lable} in the access rule

General usage of SpringCloud config

We define an openTest switch to control whether the business logic code takes the new logic branch or the old business logic branch

method one:

<!-1. Define a variable in the properties file-> 
ycdhz.openTest = dev

<!-2. Refer to @Value annotation in the code-> 
@Value ( "$ {ycdhz.openTest}" )
 private String openTest;

public void findInfo(){
    if(openTest.equal("dev")){
        System.out.print ( "Development Environment" )
    } else if (openTest.equal("test")){
        System.out.print ( "Test Environment" )
    } else {
        System.out.print ( "production environment" )
    }
}

<!-3. Modify the property file and restart to take effect->

Method Two:

<!-1. In the client side project, introduce the jar package->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>    

<!-2. In the client side project, enable the refresh monitoring endpoint->
management:
  endpoints:
    web:
      exposure:
        include: "*"    opens all endpoints

<!-3. Add @RefreshScope to the class in the read configuration file->    
@RestController
@RequestMapping("/order")
@RefreshScope
public class OrderController {

    @Value("${openTest}")
    private String openTest;
}

<!-4. Modify the configuration file of openTest on git->     
Through Post request, execute http: // localhost: 8001 / actuator / refresh to refresh the interface

Remarks: No need to restart, just need to execute the refresh method through Post. However, when it needs to be modified in a large area in the cluster, it is still very cumbersome, and each service needs to be refreshed.

Method three:

Configure Config Client

<!-1. In the client side project, introduce the jar package->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

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

<!-2, in the client-side project, configure properties->
spring:
  application:
    name: application
  cloud:
    config:
      uri: http://localhost:9000/
      label: master
  rabbitmq:
    host: **** IP address **** 
    port: **** port number **** 
    virtual -host: **** host name ****
    username: root
    password: root
    connection-timeout: 10000
    template:
      mandatory: true  
management:
  endpoints:
    web:
      exposure:
        include: "*"
  server:
    port: 8080

Configure config Service

<!-1. In the Service side project, introduce the jar package->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

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

<!-2. In the Service side project, configure the attributes->
server:
  port: 9000
spring:
  application:
    name: ms-cfg-service
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/******/springcloudconfig.git
          username: ******
          password: ******
  rabbitmq:
    host: **** IP address **** 
    port: **** port number **** 
    virtual -host: **** host name ****
    username: root
    password: root
    connection-timeout: 10000
    template:
      mandatory: true
      
<!-3. Update configuration information on Git, access bus-refresh to refresh service configuration-> 
Access monitoring endpoint http: // localhost: 9000 / actuator / bus-refresh to refresh configuration information of all services

Note: The use of message bus bus to achieve, no longer need to fight to refresh each service component. The principle is as follows:

Getting started with Spring Cloud (ten): Config unified configuration center

Guess you like