(Vii) distribution center (of service and high availability)

I. Introduction

Before then this article (vi) distribution center (Git version and dynamic refresh) , said it continued to use the Spring Cloud Config.

First recall, in the foregoing what we have done:

• Construction of a config-server, connecting to the Git repository
• Create a config-repo directory on Git, used to store configuration information
• Construction of a config-client, acquires the configuration information in Git
• Refresh opened in config-client, the dynamic refresh configuration information

In this article, we continue to look at some other capabilities of Spring Cloud Config.

 

 

Second, high availability issues

 

Traditional practices

Usually in a production environment, Config Server service registry, we also need to extend it to high availability clusters. In config-server basis prior to implementation of up to achieve high availability is very simple, we do not need to do any additional configuration to the server, only need to comply with a rule configuration: Config Server will all point to the same Git repository, so that all configure content can be maintained through a unified shared file system, and the client when specifying Config Server location, as long as the load balancing can be configured outside the Config Server, as shown in Fig following structure:

 

Registration for the Service

Although server load balancing been able to achieve, but as a configuration management within the framework, in fact, is in itself can be seen as a micro-services architecture. So, another way simpler method is to config-server is also registered as a service, so that all clients can be accessed as a service. In this way, only you need to start more than one point to the same location Git repository config-server will be able to achieve a high availability.

Configuration process is very simple, we based configuration center Git version of the content to transform.

 

 

Third, the code transformation

 

End transformation services

Add dependent

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

 

The new configuration in application.yml in Eureka

eureka:
  client:
    service-url:
      defaultZone: http://localhost:7000/eureka/

Server side of this transformation is complete. Eureka registry first start, start Server side, access in the browser: HTTP: // localhost: 7000 /  will see the Server-side has been registered to the registry.

 

 

The client transformation 

Add dependent

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

 

Profiles

bootstrap.yml

spring:
  cloud:
    config:
      name: config-client # 对应 {application} 部分
      profile: dev # 对应 {profile} 部分
      label: master # 对应 {label} 部分，即 Git 的分支。如果配置中心使用的是本地存储，则该参数无用
      discovery:
        enabled: true
        service-id: config-server
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7000/eureka/

Mainly removed  spring.cloud.config.uri directly to end address Server configuration increases the last three configurations:

• spring.cloud.config.discovery.enabled: Open Config service discovery support
• spring.cloud.config.discovery.serviceId: Specifies the end of the Server name, Server is the end  spring.application.name value
• eureka.client.service-url.defaultZone: Point Configuration Center Address

The three configurations require into  bootstrap.yml the configuration file.

 

Start Client-side access in the browser: HTTP: // localhost: 7000 /  will see Server-side and Client-side have been registered to the registry.

 

 

Learn from https://windmt.com/2018/04/19/spring-cloud-8-config-with-eureka/