Preface:

The Spring Cloud Config component is independent and does not need to be registered with eureka.
The working principle of config is to pull the read target configuration to the local cache and then supply it to other clients. Once the config is started successfully, you can delete the git configuration (but no one actually does).  

If the unified configuration center is not used in the microservice architecture, the problems are as follows:

• Configuration files are scattered in various projects, which is not easy to maintain
• Configure content security and permissions. In actual development, developers do not know the configuration of online environment
• After updating the configuration, the project needs to be restarted

In spring cloud, we use the config component as a unifying tool:

Parent pom in the project:

 <!-- Administration springboot Versions and dependencies -->
     <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.3.RELEASE</version>
        <relativePath/>
    </parent>
    
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
        <!-- main spring-cloud Version. Finchley.RELEASE Apply to springboot2.0.3 Edition -->
        <spring-cloud.version>Finchley.RELEASE</spring-cloud.version>
    </properties>
    
    <!-- Administration springcloud Edition -->
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
 
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
         <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
    </dependencies>

Add application.yml file in config service:

server:
  port: 7000
#Service name
spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
#Address of git warehouse
          uri: https://github.com/forgeorgeo/springcloud.git
#Account and password of git warehouse; it is OK if not written
          username: 466786065@qq.com 
          password: java362430
#If you have a lower level directory        esarch-paths:   
      
#Join the registry for high availability
eureka:
  client:
    service-url:
       defaultZone: http://localhost:8888/eureka/

Of course, we also need to use git to submit the code file to github:

config startup class:

package cm.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.config.server.EnableConfigServer;

@SpringBootApplication
@EnableConfigServer
@EnableDiscoveryClient
public class ServiceConfigApplication {

    public static void main(String[] args) {
        SpringApplication.run(ServiceConfigApplication.class, args);
        System.out.println("------Startup success!");
    }
}

At this time, you can visit: http: / / localhost: 7000 / config info dev.yml

Result:

 

2. Client:

 

Project pom file:

<parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.3.RELEASE</version>
        <relativePath/>
    </parent>
    
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
        <spring-cloud.version>Finchley.RELEASE</spring-cloud.version>
    </properties>
    
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
     
 <dependencies>
         <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-client</artifactId>
        </dependency>
         <!--Spring Boot Actuator，Sensing server changes-->
         <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.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

To create a bootstrap.yml file:

spring:
    cloud:
        config:
            label: master
            uri: http://localhost:7000 ා server path
            name: config-info    #git Upper file name (such as file: config-info-dev.yml)
            profile: dev         #File suffix (development, test version)

Create the application.yml file:

server:
  port: 9091    #Client port
spring:
  application:
    name: user-service   #Client service name

The bootstrap loading order in the two configuration files here is before the application.

Here, the simplest configuration for spring cloud config to access github configuration file is completed. Let's write an interface test in config client

package cn.demo.web;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RefreshScope
public class Controller {
    
         @Value("${spring.cloud}")
        private String config;

        @GetMapping("/test/config")
        public String test() {
            return config;
        }
    
    
}

Start the config service first, and then start the config client to access the http://localhost:9091/test/config

But is that all right? Although the service has not been restarted, we need to send post requests from one service to another. Can we accept it? This is much better than the previous configuration center, so how can we continue to avoid sending post requests to the service one by one to inform the service that your configuration information has changed and you need to modify the configuration information in memory in a timely manner.

At this time, we should not forget the publish and subscribe model of message queuing. Let all services subscribe to this event. When this event changes, all microservices can be notified to update their in memory configuration information. At this time, Bus message Bus can be solved. This will be left for the next essay.

Configuration rule details

Do you remember the naming rules of the test files we built at the beginning?

• hellxztest.yml
• hellxztest-dev.yml
• hellxztest-stable.yml
• hellxztest-prod.yml

The application here can be customized to other names. Here you can use the application name, that is, the application name. The following dev, stable and prod can be regarded as multiple different configuration files under an application, and can be regarded as the environment name. The environment name is used for the following.

The parameter rules that Config supports our requests are:

• /{application name} / {environment name} [/ {branch name}]
• /{application name} - {environment name}. yml
• /{application name} - {environment name}. properties
• /{branch name} / {application name} - {environment name}. yml
• /{branch name} / {application name} - {environment name}. properties