We used to write the configuration directly in application.yml when we were making a single application. However, what are the problems if we adopt the mode of microservice architecture for development? First, maintenance difficulties, security concerns, project restarts for configuration updates, and so on. In view of these problems, this article focuses on the Spring Cloud Config component, which can be used to deal with the following problems.

Flaws in the original practice

1. Maintenance difficulties: If A service is developed by several people, A modifies the configuration during development, and B needs to test some other functions during development. At this time, the configuration file has been modified beyond recognition by A, which causes conflicts.

2, safety factors: and in the safety factor, the company projects online it is wrong to configure basic development of the public, especially the database account password it, is basically only ops know that the configuration in the project, each developer can see, this kind of situation will need to isolate the configuration files.

3, update configuration need to restart: online update configuration is often happen, such as a little configuration update, do you need to restart? Spring Cloud Config solves this problem.

Unified configuration center architecture

The configuration center will also serve as a service. For the convenience of management, we put the configuration on Git, which will be more convenient to control with Git. As shown in the figure below, the arrow represents the direction of data flow:

The first step is to put the configuration in the remote Git, such as Gitlab, Github or a private server built by yourself. Config-server pulls the configuration from the remote Git and puts it in the local Git. There is a bidirectional flow between config-server and the local Git. The remote Git will be put into the local Git. If the remote Git cannot be accessed, the configuration will be pulled out from the local Git, and the configuration can be used by the micro-service module. Shop and Order services need to integrate the config-client component. This is the overall architecture of the unified configuration Center.

Config Server usage flow

1. Introduce dependencies

Since the Config center is also registered with the Eureka Server as a Client service, the dependency of the Eureka Client must be introduced and registered with the Eureka Server as a Client. As a unified configuration center, it is essential to introduce SpringCloud Config component dependencies:

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

2. Start the class with annotations

Add annotations to support @enableconFigServer on the startup class. In fact, it is not difficult to find that many SpringCloud components are used in the same way, which is to introduce the dependency first, and then add the startup class annotations and other processes. Don’t forget that this is also a Eureka Client, so the annotations and configuration of the Eureka Client are also essential.

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

Application. Yml configuration file:

spring: application: name: config cloud: config: server: git: uri: https://gitee.com/zouchanglin/config-repo username: Basedir: /root/config eureka: instance: appname: config client: service-url: defaultZone: http://localhost:8761/eurekaCopy the code

3. Put the configuration file into the warehouse

It is not hard to find that we have configured the Git repository address, user name and password in the above configuration file, because it can be seen from the architecture diagram that other service component configuration files need to be placed in a Git repository, which can be Github, GitlabGit, Gitee or a private Git server built by ourselves. I showed it directly on top of Gitee:

4. Try to access the configuration file

Then you can try to access the Eureka Server, start Eureka Server, and then start the unified configuration center to register with the Eureka Server.

As you can see, although we are only submitting an order.yml on the Master branch, we cannot access order.yml. Access to order-a.xml, order-b.xml, order-a.xml, order-a.xml, order-a.xml, order-a.xml, order-a.xml, order-a.xml SpringCloudConfig does the conversion for us. What are the conversion rules? You can see the words /{label}/{name}-{profiles}. Yml in the log, which respectively represent the following meanings:

Label: Git branch, such as master, dev, test, pre-release, etc
Name: the name of the service, where the order service is order
Profiles: environment, such as test environment, pre-live environment, online environment, etc

Config Process for using the Client

1. Import Config Client dependencies

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

2. Modify the configuration file

Change application.yml to bootstrap.yml, which means to fetch the configuration file from the specified configuration center and execute the core process of starting SpringBoot:

spring:
  application:
    name: shop
  cloud:
    config:
      discovery:
        enabled: true
        service-id: CONFIG
      profile: test
Copy the code

When changed to bootstrap.yml, the original diagram becomes a cloud, meaning it is fetched from the server (unified registry)

3. Verify whether it is successful

Put the shop-test.yml file in the warehouse:

server:
  port: 8090

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

spring:
  application:
    name: shop

env: test
Copy the code

You also place the shop-dev.yml file in the repository

server:
  port: 8090

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

spring:
  application:
    name: shop

env: dev
Copy the code

The env attribute of the two configuration files is different. Write a Controller to test the contents of the configuration file from the unified configuration center:

@RestController @RequestMapping("/env") public class EnvController { @Value("${env}") private String env; @GetMapping("print") public String printEnv(){ return env; }}Copy the code

When we set the profile property in bootstrap.yml to dev, the configuration file is shop-dev.yml, and the interface for accessing the print environment property is dev. When we set the profile property in bootstrap.yml to test, the configuration file is shop-test.yml, and the interface for accessing the print environment property prints test:

High availability of the unified configuration center

When Eureka is configured for high availability, mutual registration is adopted to achieve high availability. The high availability of the unified configuration Center service is actually very simple, because the unified configuration center is also the client of Eureka, so as long as there are enough instances of the unified configuration center registered with Eureka Server to achieve high availability. Since this is a local development environment, three instances of the unified configuration center are started by specifying different port numbers:

-Dserver.port=8080
-Dserver.port=8081
-Dserver.port=8082
Copy the code

In the interface of Eureka Server, you can see that three configuration center instances have been registered with Eureka Server:

Use the configuration center’s attention points

http://localhost:8761/eureka/, this address is the address of the default, suppose we change the IP address of the other port or other would be an error could not find Eureka, actually it is not hard to understand this, because want to get the configuration file is the premise of need to find the center of the unified configuration instance, The premise of the unified configuration center instance is that you have to go to the Eureka Server to find the instance, and the premise is that you have to register with the Eureka Server. However, the registration address of the Eureka Server is not configured at this time, so it is equivalent to being isolated. It is an isolated module, and startup failure will occur naturally. Therefore, the configuration of Eureka Server can be directly written in the configuration file instead of being distributed by the unified configuration center.

There is also a way to specify the URL of the unified configuration center so that you can find the instance of the unified configuration center directly in bootstrap.yml:

spring:
  application:
    name: shop
  cloud:
    config:
      discovery:
        enabled: true
        service-id: CONFIG
      profile: dev
      uri: http://localhost:8888
Copy the code

To sum up:

Method 1: Find the unified configuration center, obtain the configuration, find the Eureka Server from the configuration center, and register with the Eureka Server
Method 2: Find the Eureka Server and the configuration center from the Eureka Server. (Recommended)

Yml and shop-dev.yml are stored in Git repositories, and the unified configuration center will pull the configuration file from the Git repository. Both shop.yml and shop-dev.yml files are pulled down and merged, so we usually follow the principle that the common configuration content is written in shop.yml (for this example), The configuration of different environments is written in shop-dev.yml or shop-test.yml.

Unified configuration center