Spring Cloud Building a microarchitecture (vii) Message bus

To recap, in the previous introduction to Spring Cloud Config, we left a suspense: how to implement real-time updates to configuration information. Although, we have been able to implement the property update of the application triggering the content modification in the Git warehouse through the/refresh interface and the Git warehouse Web hook. However, if all triggering operations require us to manually maintain the application location of Web hooks, this will become more and more difficult to maintain as the system expands, and message broker middleware is the most appropriate solution to the problem. Do you remember when we introduced the characteristics of the message broker that we mentioned a function: Message Broker middleware can route messages to one or more destinations. With this function, we can solve the problem perfectly, and here we say the specific implementation of Spring Cloud bus.

In the article "Using RABBITMQ in Spring boot", we've covered the basics and how to use the message broker, AMQP protocol, and RABBITMQ. Let's start with a specific introduction to the configuration of Spring Cloud bus and implement a real-time update of the configuration with an example of Spring Cloud bus and Spring Cloud config. RABBITMQ Implementation

Here's what we're going to do. The entire configuration process: preparation: Here we do not do new applications, but we need to use the previous chapter, we have implemented a few projects on Spring Cloud Config, if the reader does not understand it, it is recommended to read the 4th chapter. Config-repo: A directory defined in a git warehouse that stores a multiple-environment profile named Didispace with a from parameter in the configuration file. Config-server-eureka: The GIT repository is configured and registered to the Eureka server. Config-client-eureka: The client using Eureka to discover config server, with the name Didispace, is used to access configuration servers to obtain configuration information. An/from interface is provided in this application that gets the return from property in the Config-repo/didispace-dev.properties. Extended Config-client-eureka Application Modification pom.xml Add SPRING-CLOUD-STARTER-BUS-AMQP modules (note that Spring-boot-starter-actuator modules are also required).

1 2 3 4

<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

1 2 3 4

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 in Config-client-eureka, At startup, the client program has one more/bus/refresh request.

1	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)

Access to the/FROM request of the two Config-client-eureka first returns the From attribute in the current config-repo/didispace-dev.properties. Next, we modify the From attribute value in Config-repo/didispace-dev.properties and send a POST request to one of the/bus/refresh. Finally, we then access the/from requests of the two Config-client-eureka that are started, at which time both requests return the From attribute in the most recent config-repo/didispace-dev.properties.

Here, we have been able to update the property configuration on the bus in real time through spring Cloud buses. Principle Analysis

We implemented dynamic updates of the application configuration by using the integration of Spring Cloud bus with Spring Cloud Config and RABBITMQ as the message agent.

The entire schema, shown in the figure above, contains three instances of the Git warehouse, Config Server, and Micro Service "service A", all of which have spring Cloud buses in all three instances, so they are all connected to the RABBITMQ message bus.

When we start the system up, three instances of Service A request config server for configuration information, and config server obtains the configuration information from the GIT repository and returns according to the rules for applying the configuration.

At this point, if we need to modify the properties of "Service A". First, the corresponding property values are modified in the repository through the GIT administration tool, but this modification does not trigger a property update for the "Service A" instance. We send a POST request to the "Service A" Instance 3 to access the/bus/refresh interface. At this point, "instance 3 of service A sends the refresh request to the message bus, which is retrieved from the bus by instance 1 and instance 2 of service A, and retrieves their configuration information from config server to enable dynamic update of configuration information.

The change from the configuration in the Git repository to the POST request initiating/bus/refresh can be triggered by the web hook from the Git repository. Because all applications connected to the message bus accept the update request, there is no need to maintain all node content in the Web hook to update, thus resolving the problem of refreshing one by one with Web hooks. Specify a refresh range

In the example above, we can trigger the/refresh of other service instances on the bus by requesting the/bus/refresh interface of Spring Cloud buses to the service instance. But in some special scenarios (such as grayscale publishing), we want to be able to refresh the configuration of a specific instance of the Micro service.

Spring Cloud Bus also has good support for this scenario: The/bus/refresh interface also provides destination parameters to locate the application to be refreshed specifically. For example, we can request/bus/refresh?destination=customers:9000, at this time each application instance on the bus is based on the value of the destination attribute to determine whether or not to be its own instance name, if the match is configured to refresh, Ignore the message if it does not match.

In addition to locating specific instances, the destination parameter can be used to locate specific services. The principle of locating services is achieved by using Spring's pathmatecher (path matching), such as:/bus/refresh?destination=customers:**, which triggers all instances of the customers service to be refreshed. Architecture Optimization

Now that the/bus/refresh interface for Spring Cloud Bus provides parameters for configuring updates for services and instances, our architecture can make some adjustments accordingly. In the previous architecture, the configuration update of a service would need to send a request to an instance in a specific service, and then trigger a configuration update for the entire service cluster. Although it can achieve functionality, the result is that the application instance that we specify will be different from other application instances in the cluster, which will increase the complexity within the cluster, which is not conducive to future operation, for example: we need to migrate the service instance, then we have to modify the configuration in the Web hook. So we want to make every node in the service cluster equal as much as possible.

Therefore, we have made some adjustments to the previous architecture, as shown in the following illustration:

We made these changes mainly by introducing the spring Cloud bus in config server and adding the configuration server side to the message buses. The/bus/refresh request is not sent to a specific service instance, but is sent to the Config Server, and the destination parameter is used to specify the service or instance to update the configuration.

With the above changes, our service instance does not need to assume responsibility for triggering configuration updates. At the same time, the configuration such as the trigger for GIT is only required for config server, which simplifies some maintenance work on the cluster.

This article complete example: Open source China: