The last article described how to build a config server, this article started to build the client side configuration.

1. Still a new spring boot project

2. Add the corresponding dependency file

        <!--spring config To configure-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-client</artifactId>
        </dependency>

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

3. Add the tag @Enable DiscoveryClient@RefreshScope to the startup class, where @Enable DiscoveryClient is the tag of config client, @RefreshScope is the tag used to trigger the refresh configuration later, and @RestController is used as the test interface, as follows:

@EnableEurekaClient
@EnableDiscoveryClient
@SpringBootApplication
@RefreshScope
@RestController
public class AdminOsApplication {

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

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

    @GetMapping("/value")
    public String returnValue(){
        return environment;
    }
}

4. Rename the previous configuration file as application.yml to bootstrap.yml so that spring boot reads the configuration from bootstrap.yml first. xx.properties is changed to bootstrap.properties

5. Add configuration in bootstrap.yml. Because I pull config service from the specified address, I specify uri path. I can also pull it through the registry. I can find config service through the registry. The following configuration is explained.

#actuator
management:
  endpoints:
    web:
      exposure:
        include: "*"
  endpoint:
    health:
      show-details: ALWAYS
spring:
  profiles:
    active: dev
---
#spring dev
spring:
  profiles: dev
  #rabbitmq
  rabbitmq:
    host: xxx
    port: xxx
    username: admin
    password: admin
  application:
    name: admin-os
  #Specify read configuration from config
  cloud:
    config:
      profile: dev
      #It is suggested to use lable to distinguish environment. The default is that lable is the master branch.
      label: dev
      uri: http://localhost:7009/
      #In addition to pulling configuration from the config service through uri, it can also be pulled from the registry.
      #discovery:
      # service-id: CONFIG-SERVER
      # enabled: true
 #Link tracking
  zipkin:
    base-url: http://localhost:7011/
  sleuth:
    sampler:
      probability: 1
#eureka
eureka:
  instance:
    leaseRenewalIntervalInSeconds: 10
    health-check-url-path: /actuator/health
  client:
    registryFetchIntervalSeconds: 5
    service-url:
      defaultZone: http://localhost:7001/eureka/

The above config configuration simply explains pulling the name from the config service to be / dev/admin-os-dev.yml configuration: branch / service name-description

The configuration of the OK client has been completed, and an interface is reserved for accessing and testing. Then the admin-os-dev.yml configuration file mentioned above is added to the git warehouse and the environment parameters are added.

Start the server, start successfully! The port number is still 7006 and the error is not the default 8080 because I did not add the port number to bootstrap.yml. It is configured in the git warehouse.

Then access the interface we reserved for testing: http://localhost:7006/value

Successful access also indicates that the configuration file was successfully pulled from the config service, and before loading the configuration file.

It's not over yet. We also need to make the server load seamlessly by changing the configuration in the git repository.

Above, we added bus dependency and rabbitmq to play a role. Through the broadcast mechanism of bus, a broadcast queue is formed, which allows all services with config configuration to retrieve the configuration. If it is a small partner whose service is placed on the external network, the refresh can be triggered by gitlab's web hook mechanism.

Modify the environment in the warehouse to 4 (originally 3), because I am a local service and have to refresh the input address manually: http://localhost:7009/actuator/bus-refresh It must be a post request. You can use postman for testing.

Refresh success! Re-request/value interface, successful display consistent with the configuration in the warehouse

This completes the function of dynamic refresh configuration. Any questions or suggestions can be commented on below. Thank you.