Teach you how to build a SpringCloud project (15) Integrated Bus message bus

Continue to update, welcome to like and follow!

1 Overview

When using Spring Cloud Config, we can implement manual dynamic refresh of configuration information, that is, after the remote configuration information changes, we need to tell the server that the configuration information has changed, and the server will update the configuration information, and now we want to achieve distribution Automatically refresh the configuration information function, which requires us to use the SpringCloud Bus message bus to cooperate with SpringCloud Config to realize the dynamic refresh of configuration information. SpringCloud Bus is a framework for connecting distributed system nodes with lightweight message systems. It integrates Java's event processing mechanism and message middleware functions. SpringCloud Bus currently supports two message brokers: RabbitMQ and Kafka. SpringCloud Bus can manage and disseminate messages between distributed systems, just like a distributed executor, which can be used to broadcast state changes, event push, etc., and can also be used as a communication channel between microservices.

What is a bus?

In a system with a microservice architecture, a lightweight message broker is usually used to build a common message topic and connect all microservice instances in the system, because the messages generated in this topic will be monitored by all instances and Consumption, so it is called a message bus. Each instance on the bus can easily broadcast some messages that need to be known to other instances connected to the topic.

The instances of the SpringCloud Config client all listen to the same topic (topic) in the message queue (the default is SpringCloud Bus). When a server refreshes data, it will put this information into the topic, so that other listeners of the same topic The service can be notified and then update its own configuration.

2. SpringCloud Bus dynamically refreshes the global broadcast

When learning Spring Cloud Config, we have established the service cloud-config-client-3355 as the client of Config. Here, in order to demonstrate the broadcast effect, we increase the complexity, and then use 3355 as a template to make another Config client 3366. Create Module: cloud-config-client-3366, its structure is similar to cloud-config-client-3355, just modify the service port number

Two design ideas of the message bus:

Solution 1: Use the message bus to trigger a client /bus/refresh endpoint, and then refresh the configuration of all clients:
insert image description here

Solution 2: Use the message bus to trigger the /bus/refresh endpoint of a server ConfigServer, and then refresh the configuration of all clients:
insert image description here

Obviously, the second architecture is more suitable. The reasons why the first architecture is not suitable are:

Breaking the singleness of responsibility of microservices, because microservices themselves are business modules, it should not be responsible for configuration refresh;

Destroys the equivalence of each node of the microservice;

There are certain limitations. For example, when a microservice is migrated, its network address often changes. At this time, if you want to achieve automatic refresh, you will need to add more modifications.

Therefore, although both solutions can be realized technically, there is no doubt that we should choose the second solution in terms of technical selection.

1. Add message bus support to cloud-config-center-3344 configuration service center server ConfigServer

Add the dependency of using RabbitMQ to implement the message bus in its POM file:

<!--添加消息总线RabbitMQ支持-->
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

Then add RabbitMQ related configuration in its yaml configuration file, exposing the endpoint of SpringCloud Bus refresh configuration

# RabbitMQ相关配置
spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
# 暴露总线刷新配置的端点  
management:
  endpoints:
    web:
      exposure:
        include: 'bus-refresh'

2. Add message bus support to cloud-config-client-3355/3366 clients

Add the dependency of RabbitMQ to implement the bus in its POM file (the same as the dependency of ConfigServer):

<!--添加消息总线RabbitMQ支持-->
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

Then add the relevant configuration of RabbitMQ in its yaml configuration file:

# RabbitMQ相关配置
spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

3. Test

Start the Eureka service registration center 7001/7002, ConfigServer configuration center 3344, and ConfigClient configuration center client 3355/3366 in order. At this time, the configuration information on the remote GitHub is as follows:

config:
  info: "spring cloud config-dev, version=3"

Access the configuration center and the service center of the configuration center client respectively:
insert image description here

Then change the version number in the GitHub remote configuration information to 4, and then send a POST request to the service configuration center:

curl -X POST "{配置中心的地址}/actuator/bus-refresh"

For example, the POST request we should send at this time is:

curl -X POST "http://localhost:3344/actuator/bus-refresh"

insert image description here

At this time, visit the configuration center and client configuration information:
insert image description here

It is found that the configuration information of all services has been updated. Open the control panel of RabbitMQ, we can find that there is a switch, which corresponds to the switch that the message bus sends messages:
insert image description here

3. SpringCloud Bus dynamically refreshes fixed-point notifications

In the global broadcast, we update the information of the configuration file to notify all services, but suppose we only want to notify 3355, but not 3366, what should we do? That is to say, when we perform message notification, we only specify a specific instance to take effect instead of all of them. In this case, we need to modify the POST request we send:

curl -X POST "http://{配置中心的地址}/actuator/bus-refresh/{destination}"

In this case, the /bus/refresh request is no longer sent to a specific service instance, but is sent to the ConfigServer configuration center and specifies the service or instance whose configuration needs to be updated through the destination parameter. The destination is specifically the microservice + port number.

For example, now we modify the remote configuration file, but we only want to notify 3355 of the configuration update information, but not 3366. At this time, the POST request we send should be:

curl -X POST "http://localhost:3344/actuator/bus-refresh/config-client:3355"

Modify the remote configuration file information on GitHub, change the version number to 5, and then send the above POST request to the service configuration center,
insert image description here

At this time, we visit the configuration center and its client configuration center again, and we find that the configuration information of 3355 has been updated, while the configuration center of 3344 is still the previous configuration:
insert image description here

We have finished learning Spring Cloud Bus here, so easy!

Due to time reasons, other friends Liujia Hengbao forwarded the article, click to view the original text!

In the next article, we learn Spring Cloud Stream message-driven, continuous learning, continuous updating, and the next section will be more exciting! Friends are welcome to like and follow! grateful! insert image description here