Let's first review, in the introduction of the previous Spring Cloud Config, we also left a suspense: how to achieve real-time updates to the configuration information. Although we have been able to pass/refreshInterface and Git repository Web Hook to implement content modification in the Git repository triggers application property updates. However, if all the triggering operations require us to manually maintain the application location in the Web Hook, this will become more and more difficult to maintain as the system expands, and the message broker middleware is the most suitable solution to solve the problem. . Do you remember that when we introduced the features in the Message Agent, we mentioned that a message broker middleware can route messages to one or more destinations. With this feature, we can solve this problem perfectly. Let's talk about the specific implementation of Spring Cloud Bus. Friends who are willing to understand the source code directly seek communication and sharing technology. One seven nine one seven four three three eight zero

RabbitMQ implementation

Let's take a look at the entire configuration process:

Ready to work:

Config-repo: A directory defined in the Git repository that stores a multi-environment configuration file with the application name of didispace. The configuration file has a from parameter.

Config-server-eureka: Configured the Git repository and registered to the Eureka server.

Config-client-eureka: Discover the client of Config Server through Eureka. The application name is didispace, which is used to access the configuration server to obtain configuration information. One app is provided in the app/fromInterface, it will getconfig-repo/didispace-dev.propertiesThe from attribute is returned.

Extend the config-client-eureka app

modifypom.xmlincreasespring-cloud-starter-bus-amqpModule (notespring-boot-starter-actuatorModules are also required).

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

Add connection and user information about RabbitMQ in the configuration file

spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=springcloud
spring.rabbitmq.password=123456

Start config-server-eureka, then start two config-client-eureka (on different ports, such as 7002, 7003), we can see the following in the console of config-client-eureka, at startup time , the client program has one more/bus/refreshrequest.

o.s.b.a.e.mvc.EndpointHandlerMapping : Mapped "{[/bus/refresh],methods=[POST]}" onto public void org.springframework.cloud.bus.endpoint.RefreshBusEndpoint.refresh(java.lang.String)

First access two config-client-eureka/fromRequest, will return the currentconfig-repo/didispace-dev.propertiesFrom attribute in .

Then we modifyconfig-repo/didispace-dev.propertiesThe value of the from attribute and send a POST request to one of them/bus/refresh。

Finally, we separately access the two config-client-eureka that are started./fromRequest, both requests will return the latestconfig-repo/didispace-dev.propertiesFrom attribute in .

At this point, we have been able to update the property configuration on the bus in real time via Spring Cloud Bus.

Specify refresh range

In the above example, we request Spring Cloud Bus by requesting a service instance./bus/refreshInterface, which triggers other service instances on the bus/refresh. But in some special scenarios (such as:Grayscale release), we want to be able to refresh the configuration of a specific instance in the microservice.

Spring Cloud Bus also has good support for this scenario:/bus/refreshInterface is also provideddestinationA parameter that is used to locate the application to be refreshed. For example, we can request/bus/refresh?destination=customers:9000At this point, each application instance on the bus will be based ondestinationThe value of the attribute is used to determine whether it is its own instance name. If it matches, the configuration refresh is performed. If it is not met, the message is ignored.

destinationIn addition to locating specific instances, parameters can be used to locate specific services. The principle of location services is achieved by using Spring's PathMatecher (path matching), such as:/bus/refresh?destination=customers:**, the request will triggercustomersAll instances of the service are refreshed.Complete project source code