Spring Cloud Config provides Server and client support for external configuration in distributed systems. With Config Server, you can manage the external properties of your applications in all environments. The concept mappings on the client and server are the same as the Spring Environment and PropertySource abstractions,

So they fit well with Spring applications, but can be used with any application running in any language. As the application moves through the deployment process from developer to test and production, you can manage the configuration between these environments and determine that the application has everything it needs to run at migration time.

The default implementation of the server storage back uses Git, so it easily supports a tabbed version of the configuration environment, as well as access to a variety of tools for managing content. It is easy to add alternative implementations and plug them in using Spring configuration.

 

1. Why do I need to configure the center?

An application not only needs code, but also needs to connect resources and other applications. There are often many items that need external Settings to adjust the application behavior, such as switching different databases and setting function switches.

With the continuous increase of system microservices, the primary consideration is the scalability and scalability of the system, and then a configuration management problem. Managing your own development is fine when you go online, but managing it becomes a headache when you have to update it on a large scale.

And you can’t stop your service cluster to update your configuration, which is not practical, so the SpringCloud Configuration Center is a good solution. Here is a springCloud configuration Center solution:

 

Common configuration center implementation methods are as follows:

1. Hard coding (cons: code modification is risky)

2. Put it in a configuration file, such as XML, and package it with the application (disadvantage: need to repackage and restart)

3. File system (Disadvantages: operating system dependent)

4. Environment variables (Disadvantages: a lot of configuration needs to be manually set into environment variables, which is not easy to manage and depends on the platform) 5. Cloud storage (cons: Coupling with other applications)

 

Spring Cloud Config is the Cloud storage configuration information, it has centralized, version control, dynamic update support, platform independent, language independent and other features. Its characteristics are:

1. Provide server and client support (Spring Cloud Config Server and Spring Cloud Config Client) 2. Centralized management of application configuration in distributed environment 3. Seamless integration with Spring applications based on the Spring environment 4. 5. The default implementation is based on git repository, which can be used for version management 6. Alternative custom implementationsCopy the code

Spring Cloud Config consists of two parts:

1. Spring Cloud Config Server as the server of the configuration center:

1. Update the git repository copy when pulling the configuration to ensure that it is the latest result

2. Support rich data structure, YML, JSON, properties, etc

3. Cooperate with Eureke to realize service discovery, and cooperate with Cloud Bus to realize configuration push update

4. The configuration storage is based on git repositories for version management

5. Simple and reliable, with abundant supporting schemes

2.Spring Cloud Config Client

1. The Spring Boot project does not need to change any code. Just add a Boot configuration file that specifies which configuration file from the ConfigServer to use

 

SpringCloud Config is quite different from Baidu disconf and the like, with the following three main differences:

1. The configuration is stored in different ways: Disconf saves the configuration information in mysql and Zookeeper, while Spring Cloud Config saves the configuration in Git/SVN (i.e. the configuration is managed as source code).

2. Different configuration management modes: Spring Cloud Config has no unified management interface similar to Disconf. Since the configuration is treated as git source code, git management interface is the configuration management interface

3. The notification mechanisms for configuration changes are different: After configuration changes in disconf, it relies on zK’s event watcher to notify the application, while Spring Cloud Config relies on Git’s push every time to trigger webhook callback and finally trigger Spring Cloud Bus. The message bus then notifies the relevant application.

From the perspective of the notification mechanism of configuration changes, if there are 100 application nodes, all depend on the unified configuration. If the configuration is modified, only a few nodes can update the configuration “gray scale”, Spring Cloud Config Server is easier to do, which is more flexible than DisConf

 

First of all, SpringCloud Config is divided into Server side and Client side. The Server side is responsible for managing the configuration, and the Client side is used to load the configuration. We integrate a Client side for each service. That was mentioned above. So let’s now take a look at the Server side Demo implementation of Config.

Start by creating a new SpringCloud-config-server module in the original project and introducing related dependencies as follows:

 

　　<dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-server</artifactId>
        <version>1.4.0. RELEASE</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-eureka</artifactId>
        <version>1.3.5. RELEASE</version>
    </dependency>
Copy the code

 

We can see the introduction of Eureka. Why? Obviously for high availability.

Then add the @enableconFigServer annotation above the startup class to indicate that this is the configuration center service. The Eureka client annotation code is as follows:

 

@SpringBootApplication @EnableConfigServer @EnableDiscoveryClient public class ConfigApplication { public static void main(String[] args) { SpringApplication.run(ConfigApplication.class, args); }}Copy the code

 

Application. Yml configuration is as follows:

 

Spring: application: name: config-server cloud: config: server: git: https://gitee.com/xxxx/springcloud-config.git # git repository account password username: password: XXX XXX # to join the registry, achieving high had been available: the client: service-url: defaultZone: http://localhost:8888/eureka/,http://localhost:8889/eureka/Copy the code

 

Note that you must set up a git repository and then configure two configurations: dev and test.

Dev looks like this:

The contents of test are as follows:

Let’s start the SpringCloud-config module, start the bootstrap class, run it, and access the Cloud-config-dev.properties in git repository as follows:

 

Next, we will perform the Client Demo of SpringCloud Config as follows:

Firstly, Client dependencies are introduced as follows:

 

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

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
            <version>1.4.0. RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
            <version>1.3.5. RELEASE</version>
        </dependency>
Copy the code

 

The reason for introducing the previous Actuctor dependency is that our Client needs to update the pull-load configuration center changes and then modify the value of the configuration in memory without restarting it.

Register with the registry by annotating @enableDiscoveryClient on the Client startup class as follows:

 

@SpringBootApplication @EnableDiscoveryClient public class ConfigClientApplication { public static void main(String[] args) { SpringApplication.run(ConfigClientApplication.class, args); }}Copy the code

 

 

The next step is to change the application.yml file in the Client module to bootstrap.yml. This is crucial because bootstrap.yml is loaded before application.yml. Yml has a higher priority than application.yml. I mean, for example, your application is running, and your configuration hasn’t been loaded, isn’t that bullshit?

As follows:

 

 

 

 

server: port: 7005 spring: application: name: cloud-config cloud: config: Dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev dev Discovery: enabled: true # This name is a service name on the Config Server side. Service-id: config-server # registry eureka: client: service-url: defaultZone: http://localhost:8888/eureka/, http://localhost:8889/eureka/ # do you need access to. The default is true, if not false then you are not allowed to pull the configuration center Server update management: Security: enabled: falseCopy the code

 

 

Then write a test code as follows. Create a test Controller as follows:

 

Git git git git git git git git git git git git git git git @refreshScope public class TestController {@value ("${name}") private String name; @Value("${age}") private Integer age; @RequestMapping("/test") public String test(){ return this.name+this.age; }}Copy the code

 

Then start the project, and the running results are as follows:

First let’s look at the values before the configuration update, as follows:

Post localhost:7005/refresh localhost:7005/refresh localhost:7005/refresh

You can see that Postman returns config.client.version to inform the client that the configuration center in the remote repository has updated the configuration version information to age.

Localhost :7005/test to see if the age is up to date:

You can see the age is up to 24.

 

But is that enough? Although the service is not restarted, we want to send post requests one service at a time. Are we ok with that? This is much better than not having configured the center before, so how do we continue to avoid sending Post requests one by one to the service to tell the service that your configuration has changed and you need to modify the configuration in memory in a timely manner.

Let’s not forget the publish-subscribe model of message queues at this point. Have all the services subscribe to this event, and when the event changes, all the microservices can be notified to update their configuration information in memory.