Steps to implement distributed configuration center using Spring Cloud Config combined with Bus

Overview

Suppose there is a requirement now:

Our application is deployed on 10 machines. When we adjust a certain configuration parameter, we do not need to restart the machine. 10 machines can automatically obtain the latest configuration.
How to achieve it? There are many kinds, such as:

1. Place the configuration in a database, and each time the application reads the configuration directly from the DB. In this way, we only need to make a DB change and update the latest configuration information to the database. In this way, no matter how many applications are, since they all obtain configuration information from the same DB, they can naturally get the latest configuration.

2. Each machine provides an updateConfig interface that updates configuration information. When it is necessary to modify the configuration, the updateConfig interface of the server is called one by one.

3. Use redis to implement it and place the configuration information on redis, but in this way, you have to read it every time, which has more network requests.

The above three methods are the easiest to think of and are easy to do, but of course there are many disadvantages. Although there are many shortcomings, some traditional companies do this.

In Internet companies, I have basically never seen anyone playing like this, they all use distributed configuration centers. Use open source or implement it yourself. Currently, there are many open source distributed configuration centers, and spring cloud config is the best among them. Next, we will use spring cloud config to implement a distributed configuration center.

Whether to use the latest Spring Boot 2.0 version

I used to use the latest spring cloud 2.0 to do a distributed demo that is configuration center. I thought it was simple, but it took a whole day to get it done. There are several reasons:

1. The corresponding document of spring cloud has not been completely updated, and there is a problem and cannot be found in the document;

2. Currently, there are few companies using version 2.0, and there are no specific practical articles on the Internet. After the problem broke, Baidu could not find a solution. It is basically difficult for Google to find solutions, all of which are sporadic knowledge fragments;

3. There are some minor changes in config and bus in the 2.0 version, and if it is still done according to the 1.5.x version, it will not work.

Based on the above reasons, it is recommended to use the 1.5.x version to be more reliable. The following article will be introduced in the following version:

spring boot:

1.5.2.RELEASE

The corresponding spring cloud uses:

Dalston.RELEASE

Build spring cloud config server

If you just want to manage the configuration uniformly by spring cloud config and don't want to be highly available in the configuration center for the time being, you only need config and bus components. However, if you want to ensure high availability, you must also use the registration discovery component of spring cloud.

In addition to config and bus, we also need to use git. Because spring cloud config uses git for version management.

It is very simple to make a configuration center based on spring cloud config, it is done in just a few small steps.

【1】Introduce config and bus components

 <dependency><groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency> <dependency><groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId></dependency>

【2】The startup class uses @EnableConfigServer annotation

 package spring.cloud.config;import org.springframework.boot.SpringApplication;import org.springframework.boot.autoconfigure.SpringBootApplication;import org.springframework.cloud.config.server.EnableConfigServer;@EnableConfigServer@SpringBootApplicationpublic class ConfigApplication { public static void main(String[] args) { SpringApplication.run(ConfigApplication.class, args); }}

【3】Application.yml file configures rabbitmq and git repositories

 server: port: 8040spring: application: name: spring-cloud-config-server cloud: config: server: git: uri: https://gitlab.xxxxxx.com/config/xxxxxx.git search-paths: username: xxxxx password: xxxxxx activemq: host: 127.0.0.1 port: 5672 username: guest password: guestmanagement: security: enabled: false

RabbitMQ is configured because the bus component needs to use it to notify the client, and the configuration changes are made. Also, remember to use

 management: security: enabled: false

The verification will be closed, and the next operation will always report an authorization error.

The server configuration center has been completed. Now you can do a small experiment on the server and submit a demo-dev.properties file. The content of the file is as follows:

 address=hello

Then use

http://localhost:8040/demo/dev

If output

 {"address":"hello"}

This means that the interaction between spring cloud config and git is OK.

Client Access Configuration Center

Our goals:

After the configuration information is modified and submitted to git, all clients connected to spring cloud config will receive notifications immediately and get the latest configuration information.
The following describes how to achieve this goal.

The client only needs to do a few small steps to complete the access action.

【1】Introduce dependencies

 <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> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-amqp</artifactId> </dependency>

The introduction of spring-boot-starter-web is just for experimentation.

【2】Configure RabbitMQ and introduce urls in the configuration center

application.properties

 spring.application.name=spring-cloud-config-client1server.port=8042management.security.enabled=falsespring.rabbitmq.host=127.0.0.1spring.rabbitmq.port=5672spring.rabbitmq.username=guestspring.rabbitmq.password=guest

bootstrap.properties

 spring.cloud.config.name=demospring.cloud.config.profile=devspring.cloud.config.label=masterspring.cloud.config.uri=http://localhost:8040/

There are three points to pay attention to:

1. Close verification: management.security.enabled=false

2. The configuration related to spring cloud config must be placed in bootstrap.properties

3. Use spring.cloud.config.uri to specify the address of the configuration center

In addition, for the client, the startup class does not need to add any annotations related to config and bus .

After getting to this client, we can use a controller to start experimenting.

 package springcloudconfig.client;import org.springframework.beans.factory.annotation.Value;import org.springframework.cloud.context.config.annotation.RefreshScope;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.RestController;@RestController@RefreshScopepublic class HelloController { @Value("${address}") private String address; @RequestMapping("/address") public String getAddress() { return this.address; }}

Assuming the above HelloController needs to use the address configuration, you only need to use @RefreshScope and @value annotations.

 @RefreshScopepublic class HelloController {}

 @Value("${address}") private String address;

To verify whether the client can obtain the latest configuration information, provide a

 @RequestMapping("/address") public String getAddress() { return this.address; }

method.

Let's modify the demo-dev.properties file and change the value to

 address=hello update

And submit it to git. At this time, we call the getAddress interface

http://localhost:8041/address

I found that I did not get the latest value. That's because after the action of pushing to git was completed, we did not notify spring cloud bus. You can use postman to make a post request and call the following interface to notify bus.

http://localhost:8040/bus/refresh

Once this interface is called successfully, bus will use RabbitMQ to notify all clients that the configuration has been updated.

Special attention:

We are calling the /bus/refresh interface of the server, not the /bus/refresh interface of the client.

If you have to call the /bus/refresh interface on the server every time you submit, then this is too troublesome. You can use webhook to help.

If you are using the new gitlab, you just need to click [Settings] in the project, then click [Integrations] to set up the webhook, as shown in the figure below:

Fill in the URL to the /bus/refresh interface address of the configuration center server, and then click [Add Webhook].

Comparison with Ctrip's Apollo

The exquisite thing about Spring Cloud Config is that its configuration is stored in Git, which naturally isolates configuration modification, permissions, versions and other issues. This design makes Spring Cloud Config very simple overall, but it also brings some inconvenience.

Let's try to make a simple summary:

I personally recommend using Spring Cloud Config, which is very lightweight and active in the community. It is easy to find a solution when encountering problems. In addition, I personally think the difference between Apollo and Spring Cloud Config is just that there is no interface. The interface can be done, and we can do it through git, but the user experience is not that good.

Summarize

The above is the entire content of this article. I hope that the content of this article has certain reference value for everyone's study or work. If you have any questions, you can leave a message to communicate. Thank you for your support to Wulin.com.