Spring Cloud Refresh Configuration Center configuration--message bus rabbitmq_spring

At the end of http://blog.csdn.net/a60782885/article/details/69415527, we mentioned the refresh of the configuration, but this is obviously troublesome if multiple services use this configuration, and when we modify the configuration information, If we want the configuration of the service to be modified, we will have to send a POST request for one service, or turn off the service to reopen it. This is a lot of trouble.

So here we are using message middleware to complete the configuration update problem.

Goal:

When we update the configuration information for the Git warehouse, all the services that use the modified configuration will refresh the configuration.

Using RABBITMQ Middleware as the message bus, we first need to install the RABBITMQ in the computer. The installation process is not to be discussed here.

Warm tip: Use window of the small partners, installation process can not appear in Chinese path, even if your computer user name is Chinese can not be successful.

Get ready:

We first build a service registry, a configuration center, and a client that gets the configuration. Both the configuration center and the client are registered in the Service Registration center.

Verify:

The configuration center and client are visible in the service registry.

Access to the Configuration center URL can be returned in JSON format. See http://blog.csdn.net/a60782885/article/details/69415527.

The access client can get the value of a property in the warehouse.

If it's all done, the text begins.

First modify the dependency pom for the configuration center:

Add two dependencies:

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId> spring-boot-starter-actuator</artifactid>
</dependency>
<dependency>
	<groupid >org.springframework.cloud</groupId>
	<artifactid>spring-cloud-starter-bus-amqp</ Artifactid>
</dependency>

Add RABBITMQ configuration information to the Application.properties configuration file.

Spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username= user name
spring.rabbitmq.password= Password

Without using RABBITMQ's friends, you need to create a username and password first, and permission configuration is complete before you can use it.

The configuration center changes are complete.

Next is the client's modifications:

As with configuration center modifications, add two dependencies, and add RABBITMQ information to the application configuration file OK.

Then how do we verify that we are successful?

1. First we visit the client to view the information of the GIT warehouse before the modification.

2. After confirming the previous value, we modify the Git warehouse information, and then visit the client again, will find that the information has not changed.

3. Then we send a POST request to the/bus/refresh in the configuration center.

Here 7001 is the port of the configuration center.

4. Visit the client again and find that the information has been modified.

Analysis principle:

As you can see, our architecture is like this.

Because we introduced the message bus, the server and service are connected to the RABBITMQ queue.

When config server starts, it gets the configuration information to the GIT repository.

When the service is started, the configuration information is taken to config server.

When we modify the Git warehouse, the service client is unable to refresh the configuration information.

When we send a POST request to the server's/bus/refresh, config server sends the refresh request to the message bus, and when our client obtains the refresh request from the message bus, it is reset from config Server to obtain configuration information.

In this way, we still do not achieve the goal, although the configuration of the refresh has become very fast, but we still do not have to modify the Git warehouse, all services are automatically refreshed one thing, we also need to send a POST request to config server.

At this time, we can achieve the goal through the webhook of the remote warehouse. What's the use of Webhook?

Webhook sends a POST request to the specified URL when we send a push request to the warehouse. I know that. When we send a push request to the configuration warehouse of the configuration center, he sends a POST request to the/bus/refresh in our configuration center, and then the service refresh is achieved.

Create Webhook, take GitHub as an example:

A warehouse->settings->webhooks.

You just need to fill in the payload URL with the/bus/refresh of the configuration Center to achieve your goal.

Of course, the address here if the public network address, localhost what is not.

In fact, we can also send a POST request to the service client to achieve the purpose of all services are refreshed, but we choose to send a POST request to the configuration center. Why, then?

Because we finally have to set the Webhook. If we use a service as a refresh point, it is a very troublesome thing, if the service needs to migrate, then our webhook need to be modified.

It is much more convenient to use a configuration center as a refresh point.