​

This is the eleventh article in the Spring Cloud column, and knowing the first ten articles will help you understand it better:

  1. Spring Cloud first article | Spring Cloud preface introduces an overview and its commonly used components

  2. The second Spring Cloud | use and understand Eureka registry

  3. Spring Cloud third | build a high availability Eureka registry

  4. Spring Cloud fourth article | client side load balancing Ribbon

  5. The fifth canto of Spring Cloud fusing Hystrix | service

  6. Spring Cloud article 6 | Hystrix Dashboard monitoring Hystrix Dashboard

  7. Spring Cloud seventh article | declarative service invocation Feign

  8. Spring Cloud the eighth article | Hystrix cluster monitoring Turbin

  9. Spring Cloud 9 article | distributed service tracking Sleuth

  10. Spring Cloud center Config the tenth article | distributed configuration

​

One, foreword

In order to ensure the high availability of configuration center service, make the configuration center Server as a microservice and cluster it to achieve high availability. When you deploy multiple Config Server instances and expect one or more instances to be unavailable from time to time, to ensure high availability, You can specify multiple urls (as a comma-separated list under the spring.cloud.config.uri property), or you can register all instances in Service Registry such as Eureka (if using the discovery-first Bootstrap pattern). Note: High availability is only ensured when Config Server is not running (i.e. when the application has exited) or when connection timeout occurs, for example: If the Config Server returns a 500 (internal Server error) response or the Config Client receives 401 from the Config Server (due to credentials error or other reasons), the Config Client does not try to get properties from another URL, This error indicates a user problem rather than a usability problem.

An article in the Spring Cloud the tenth | distributed configuration center Config “tells the story of a service how to read a file from the center, in the previous case only by the client direct access to the server, the address to write directly to death, this approach is not flexible, when many service instances, Have read the file from the center, if the allocation center server address changes, then we all services to start up, all need to change the configuration center server address, special trouble, because of the micro service registry, as well as the advantages of the registry, we can combine Eureka registry, will be made into micro service configuration center, Cluster deployment to achieve high availability in the configuration center. The architecture diagram is as follows:

​

2. Transform and configure the service terminal of the center

1. Add registry client dependencies

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>Copy the code

Add the @enableeurekaclient annotation to the main startup class

3. Add Eureka configuration to the application.yml file

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8700/eureka
    The client updates the service information from Eureka service every 30 seconds
    registry-fetch-interval-seconds: 30
    I need to register my service with Eureka
    register-with-eureka: true
    # Need a retrieval service
    fetch-registry: true
  Heartbeat detection detection and renewal time
  instance:
    # tell the server that if I do not send you a heartbeat within 10 seconds, it means THAT I am faulty. Delete me
    #Eureka Specifies the maximum time the server must wait after receiving the last heartbeat, in seconds.
    lease-expiration-duration-in-seconds: 10
    Send a heartbeat to the server every 2 seconds to prove that the server is still alive. Default is 30 seconds
    #Eureka Interval in seconds for the client to send the heartbeat to the server (the client tells the server it will follow this rule)
    lease-renewal-interval-in-seconds: 2
    So that what you see in the registry list is rendered as IP + port
    prefer-ip-address: true
    # instance name last render address: IP :2002
    instance-id: ${spring.cloud.client.ip-address}:${server.port}Copy the code

4. Then start the Config Server server

3. Transform the configuration center client

1. Perform the same steps as 1-1,1-2,1-3, and modify the spring.cloud.config configuration as follows in the application.yml file

spring:
  cloud:
    config:
      #uri indicates the address of the configuration center
      #uri: http://localhost:8888
      {application} fetch spring.cloud.config.name {application} fetch spring.cloud.config.name
      #spring.application. Name; otherwise, get the value of spring.cloud.config.name.
      #1), when there is no spring.cloud.config.name, the client can obtain only one git library file corresponding to spring.application.name
      #2) When a project needs to fetch multiple files, use the spring.cloud.config.name attribute, separated by commas
      name: configclient
      profile: dev
      #label corresponds to the label section
      label: master
      discovery:
        # indicates that access to config-server by service name is enabled
        enabled: true
        # indicates the service name of config-server
        service-id: tmgsp-config-serverCopy the code

2. View the services registered in the registry

​

3, then visit http://localhost:8881/index you can see the same effect, if you need high availability configuration center, only need to configure multiple instances of the center line.

Four, failure fast response and retry

1. Quick response to failure

The Spring Cloud Config client preloads a lot of other information before connecting to the Config Server for property injection. Without any additional configuration, failure response is a little slow. For a simple example, close the config-server and start the config-client directly. At this time, an error will be reported, but the error time is late. When we build a complex application, it may take a long time to start up before connecting to Config Server, and in some special cases, we want to know quickly whether the current application will be successfully transferred from Config The Server gets the configuration information, which can save a lot of time waiting to start up during the initial build of the debug environment. In order to achieve the client Config Server access to judge whether the normal priority, and rapid response to the failure, only in the Config client bootstrap. Yml configuration parameters in spring. The cloud. Config. FailFast = true.

At this time, if config-server is not started and config-client is directly started, an error will still be reported. However, we can see that the error time is too early, and the system does not print several startup logs.

2, try again

As mentioned above, when the Config Server is down or the client is incorrectly configured and fails to connect to the Config Server, a quick response configuration can work well. However, if the problem is caused by other intermittent causes such as network fluctuations, direct startup failure may seem costly. So Config client also provides the function of automatic retry, before open retry function, to ensure that have configured (ensure that open fail fast response) spring. Cloud. Config. FailFast = true in the following operation.

2-1. Add a dependency on the client

<! - connect the config - server retry mechanism related to rely on - > < the dependency > < groupId > org. Springframework. Retry < / groupId > <artifactId>spring-retry</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-aop</artifactId> </dependency>Copy the code

2-2, do not need to do any other configuration, start the client application, you can see the following in the console. After the client fails to connect to Config Server, it continues to try and returns an error message after the sixth failure. By using this retry mechanism, client applications cannot be started due to intermittent failures. Check the log as follows. During the test, remember that Config Server needs to be excluded from the registry. If it is excluded, it will be perfect.

INFO 9996 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://172.20.10.2:8888/ INFO - 9996 [tbeatExecutor - 0] com.net flix. Discovery. DiscoveryClient: Discoveryclient_springcloud-config-client / 172.20.10.2:8881-re-registering apps/ springcloud-config-client INFO 9996 -- [tbeatExecutor - 0] com.net flix. Discovery. DiscoveryClient: DiscoveryClient_SPRINGCLOUD - CONFIG - CLIENT / 172.20.10.2:8881: registering service... INFO 9996 --- [tbeatExecutor-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_SPRINGCLOUD - CONFIG - CLIENT / 172.20.10.2:8881 - registration status: 204 INFO 9996 --- [ main] c.c.c.ConfigServicePropertySourceLocator : The Connect Timeout Exception on Url - http://172.20.10.2:8888/. Will be trying on the Urlifavailable INFO 9996 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://172.20.10.2:8888/ INFO - 9996 [main] C.C.C.C onfigServicePropertySourceLocator: The Connect Timeout Exception on Url - http://172.20.10.2:8888/. Will be trying on the Urlifavailable INFO 9996 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://172.20.10.2:8888/ INFO - 9996 [main] C.C.C.C onfigServicePropertySourceLocator: The Connect Timeout Exception on Url - http://172.20.10.2:8888/. Will be trying on the Urlifavailable INFO 9996 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://172.20.10.2:8888/ INFO - 9996 [main] C.C.C.C onfigServicePropertySourceLocator: The Connect Timeout Exception on Url - http://172.20.10.2:8888/. Will be trying on the Urlifavailable INFO 9996 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://172.20.10.2:8888/ INFO - 9996 [main] C.C.C.C onfigServicePropertySourceLocator: The Connect Timeout Exception on Url - http://172.20.10.2:8888/. Will be trying on the Urlifavailable INFO 9996 --- [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://172.20.10.2:8888/ INFO - 9996 [main] C.C.C.C onfigServicePropertySourceLocator: The Connect Timeout Exception on Url - http://172.20.10.2:8888/. Will be trying on the Urlif available
ERROR 9996 --- [           main] o.s.boot.SpringApplication               : Application run failedCopy the code

2-3. It can be seen from the log that the Config client attempts to access the Config server for a total of six times, but fails to do so for six times. The configuration related to the retry mechanism is as follows:

Set the number of retries. Default is 6
spring.cloud.config.retry.max-attempts=6
# Interval multiplier, default 1.1Spring. Cloud. Config. Retry. Multiplier = 1.1Initial retry interval, default: 1000ms
spring.cloud.config.retry.initial-interval=1000
# Maximum interval, default 2000ms
spring.cloud.config.retry.max-interval=2000Copy the code

5. Dynamically refresh the configuration

Sometimes, I dynamically update the configuration file in Git repository. How can I make my config-client aware of this? Add the following dependencies to config-client:

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

Since this dependency is already introduced in our parent module (Spring Cloud-learn) dependency, we can omit it.

This dependency contains the implementation of the /refresh endpoint, which we will use to refresh the configuration information.

2. Add the @refreshScope annotation to the Bean that needs to be refreshed, otherwise the client won’t know where to refresh

3. You then need to configure the exposure/Refresh endpoint in application.yml

management:
  endpoints:
    web:
      exposure:
        include: ["info"."health"."refresh"]Copy the code

4, then start to http://localhost:8881/index

​

5. Modify the configClient-dev. yml file on the cloud, since this is the configuration file loaded by our client

​

6, and then use the postman tool send a POST request to the http://localhost:8881/actuator/refresh address (the endpoint only accept POST requests, log on as you can see), the results are as follows:

​

7, visit http://localhost:8881/index to display content is as follows

​​

Detailed reference case source: gitee.com/coding-farm…

​

​