Introduction to the

It is common to encounter variable parameters in services, such as database addresses, timeout times, and so on. These parameters are poorly coupled with the code, but it would be silly to change the parameters in the code every time, and then compile and deploy, so you have a configuration center implementation. Currently, SpringCloudConfig and Ctrip’s Apollo are widely used configuration centers. The benefit of SpringCloudConfig is that it is bundled with SpringCloud, a whole family bucket (both good and bad, you know), and easy to deploy; Apollo deployment is a bit of a hassle. It first needs to compile the deployment address in apollo-client, and then reference the Apollo-client in the configuration project. Since it is the configuration center, why can’t the configuration center itself decouple the code and parameters? !). Of course, these are all my personal goods. In fact, Apollo is very powerful, complete permissions, and supports multiple languages. We all know that Ctrip’s technology stack is mainly.NET. The two types have different strengths and weaknesses. If you are interested, you can go to Github to check them out. The documentation is very detailed. Now, let’s focus on Spring Cloud Config.

Start the Config

The Config configuration is also simple: add dependencies on Spring-Cloud-config-server, add annotations @enableconFigServer and @enableDiscoveryClient to the entry class, the first annotation is to enable the Config registry, The second is to register with Eureka and let other services find the service.

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>
Copy the code
@EnableDiscoveryClient @EnableConfigServer @SpringBootApplication public class ConfigApplication { public static void main(String[] args) { SpringApplication.run(ConfigApplication.class, args); }}Copy the code

The Config Server configuration

First said registry had been related content, registered service address Eureka. Client. ServiceUrl. DefaultZone and who he is spring. The application. The name is ok. I’ll add the prefer-ip-address configuration here, and I’ll trust the instructions later.

spring:
  application:
    name: config-server
eureka:
  instance:
    prefer-ip-address: true
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
Copy the code

Next is the configuration center related content. The configuration center usually uses Git or SVN as the configuration storage end. The official documents also use JDBC database for storage. This article uses Git to illustrate. One spring. The cloud. Config. Server. The uri is the address of the git configuration file storage, in order to more intuitive demonstration, on my gitee configuration corresponding content. ‘{application}’ indicates that different services will go to git project to find the file corresponding to the project name (spring.application.name). The rule is {application}-{profile}.yml

For example, in service A, spring.application.name: fuwu1, when service A starts, the configuration center will find the fuwu1.yml file in git.uri and hand it to service A for configuration. When service A is started with -dspring. profiles.active=master, the configuration center will find the fuwu1-master.yml file in git.uri and hand it to service A for configuration.

Configuration also requires permission management, and the permission logic in the configuration center is the same as git (if you are using Git as a storage backend). You can configure username and password, and if you need more requirements, you can also configure public and private keys like git. Put the public key on Git, fill in the private key content directly in the private-key area, and you can even remove the permission information from the code and configure the private key on the deployed server. In short, git is configured the way it is configured. (Git related content click here)

Git uri: git@your-git-address:your-config-repo/{application}.git. Different project configurations are placed in different repositories, so that permissions for different repositories can be configured. If configured this way, the file life rule in the repository is application-{profile}.yml.

spring:
  cloud:
    config:
      server:
        git:
          uri: [email protected]:yangzijing/config.git
          search-paths: '{application}'
          #uri: git@your-git-address:your-config-repo/{application}.git
          #private-key:
          #username: yourusername
          #password: yourpassword
Copy the code

Config Client configuration

There are also two types of client configuration: eureka configuration and Config configuration. Note that these configurations are written in bootstrap.yml. The configuration in bootstrap.yml is started first, and the configuration in application. Yml is started after the configuration.

The configuration of Eureka is not described here, but the configuration of Config. 1) Specify the IP address of the config file and set it to the address in spring.cloud.config.uri. 2) find the Config address through Eureka, configure spring. Cloud. Config. The discovery, enabled = true and discovery service – id (the service – id here and spring Config items. The ap Plication. Name Indicates the same name. The default value is configserver.

spring:
  application:
    name: api-admin
  cloud:
    config:
      #uri: http://ip:port
      discovery:
        enabled: true
        service-id: config-server
Copy the code

In the api-admin project, we added a from configuration. In application. Yml, we can write from: ${from:hello}. If not, you can also reference it directly in a Java file, for example:

@Value("${from}")
private String from;
Copy the code

${XXX} = ${XXX} = ${XXX} = ${XXX} = ${XXX}

Automatic refresh using WebHook

Add the @refreshScope annotation to the class that references the configuration, and add http://config-ip:port/bus/refresh to the Webhooks in Git (such as GitHub, GitLab, Gitee).

The process is as follows: Git repository update -> Trigger Webhook -> trigger config refresh endpoint -> config notification application -> apply refresh configuration content.

A prefer-ip-address problem encountered

A problem was found during debugging. If prefer-ip-address is not enabled on the Config server, the client cannot find the Config server. I have found an explanation about this configuration on the Internet. I hope it is useful to explain the prefer-ip-address mechanism

The general content of config is finished, there may be a need to configure content encryption, which is a little complicated. If you have the opportunity to supplement it, you can check the official documents or other Chinese blogs urgently