Learning goals

What is a message bus

The article is from Le Byte

The message broker middleware builds a common message topic for all microservice instances to subscribe to, which is listened to and consumed by all microservice instances when the message topic produces a message.

What is the message broker? Message broker is a message validation, transport, routing architectural pattern that is used to receive and distribute messages and forward them to the correct application based on the configured message processing flow. It plays the role of communication scheduling between microservices, reducing the dependency between services.

　　

What is Spring Cloud Bus

Spring Cloud Bus is a message Bus in the Spring Cloud system that connects all nodes of the distributed system.

Spring Cloud Bus connects distributed nodes with lightweight message brokers (RibbitMQ, Kafka). Changes to profiles, or communication between services, can be broadcast through a message broker, and can also be used for monitoring. Solved the problem of microservice data change and timely synchronization.

　

When to use Spring Cloud Bus

Microservices are generally deployed in cluster mode, and in high concurrency, services need to be expanded, reduced, online, and offline. For example, if we need to update the configuration, or if we need to deactivate a cache on all servers at the same time, and we need to send commands to all relevant servers, we can use Spring Cloud Bus.

The bottom line is that Spring Cloud Bus is an option when we need to distribute an operation to all the backend related servers.

Next, we implemented a configuration refresh of the microservices architecture through Spring Cloud Bus.

　　

Environment to prepare

　　

RibbitMQ V3.8.2 Address: 192.168.10.101

　　

Bus-demo aggregation project SpringBoot 2.2.4.RELEASE and Spring Cloud hoxton.sr1.

  • eureka-server: Registry
  • eureka-server02: Registry
  • config-server: Configures the center server
  • config-server02: Configures the center server
  • order-service: Order service (configuration center client)
  • order-service02: Order service (configuration center client)

　　

Configuration file order-service-prod.yml

spring:
  application:
    name: order-service # Application name

Configure the Eureka Server registry
eureka:
  instance:
    prefer-ip-address: true       # Whether to use IP address registration
    instance-id: ${spring.cloud.client.ip-address}:${server.port} # ip:port
  client:
    service-url:                  Set the service registry address
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/

# Custom configuration
name: order-service-prod
password: root
Copy the code

　　

The Spring Cloud Bus configuration has been updated

　　

The client initiates a notification

　　

A typical application scenario for the message Bus (Bus) is to configure the central client refresh.

When we learned about the Configuration center of Spring Cloud, we talked about the configuration refresh based on the Interface. At that time, we only had a Config Client, we could use Webhook, and manual refresh was not too much work. However, if there are a lot of clients, it would be a bit complicated to manually refresh one by one, and this scheme is not suitable. Spring Cloud Bus is a perfect solution to this problem.

With the help of the broadcast function of Spring Cloud Bus, let Config Client subscribe to the configuration update event. When the configuration update is triggered, the update event of one end is triggered, and Spring Cloud Bus broadcasts this event to other subscribing clients, so as to achieve batch update.

  1. When the Webhook listener is triggered, A bus-Refresh request is sent to ConfigClient A to refresh the configuration
  2. ConfigClient A reads the configuration in the ConfigServer and sends messages to Bus
  3. After receiving the message, the Bus broadcasts the message to other ConfigClients
  4. Other ConfigClients read the latest configuration after receiving the message

　　

Add the dependent

　　

Config Client Added the Spring Cloud starter bus AMQP dependency.

<! -- Spring Cloud Starter Bus AMQP dependency -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
Copy the code

　　

The configuration file

　　

The configuration file needs to configure the message queue and bus-Refresh endpoints automatically. The/ACTUATOR/bus-Refresh endpoints clear the @RefreshScope cache rebinding property.

The bootstrap.yml core configuration of Config Client.

spring:
  cloud:
    config:
      name: order-service The name of the configuration file that corresponds to the first half of the configuration file in the Git repository
      label: master # git branch
      profile: prod # Specify environment
      discovery:
        enabled: true # open
        service-id: config-server Specifies the service id of the configuration center server
  # Message queue
  rabbitmq:
    host: 192.16810.106.

# Metrics monitoring and health check
management:
  endpoints:
    web:
      base-path: /actuator    # Access the root path of the endpoint. Default is /actuator
      exposure:
        include: bus-refresh  # Endpoints to be turned on
        #exclude: indicates the endpoint that does not need to be enabled
Copy the code

　　

test

　　

Look at the endpoint

　　

You can see that bus-Refresh is enabled to automatically refresh the endpoint.

　　

　　

Modify the Git repository configuration

　　

Modify Git repository configuration information as follows:

# Custom configuration
name: The order - service - prod - 1.0
Copy the code

　　

Automatically refresh

　　

Refresh the page and find that the results have not changed, nothing normal.

Call the auto-refresh endpoint of any client by Post mode: The results of re-access are as follows:

Check the queue

　　

Take a look at the message queue UI and discover that there is an additional switch for springCloudBus.

There are two queues bound to the switch corresponding to our two Config Clients.

The client initiated notification defect

　　

  • Breaking the single responsibility of microservices. The microservice itself is a business module and should not be responsible for configuration refresh.
  • This breaks the peer-to-peer relationship between microservice nodes.
  • There are some limitations. For example, when a microserver migrates, its network address often changes, and if you want to refresh automatically, you have to modify the Webhook configuration.

　　

The server initiates a notification

　　

To address the client-initiated notification defect, we switched to server-initiated notification.

  1. When the Webhook listener is triggered, a bus-Refresh request is sent to the ConfigServer to refresh the configuration
  2. ConfigServer sends messages to Bus
  3. After receiving the message, Bus broadcasts the message to all ConfigClients
  4. Each ConfigClient reads the latest configuration after receiving the message

　　

Add the dependent

　　

Config Server Added the Spring Cloud starter bus AMQP dependency.

<! -- Spring Cloud Starter Bus AMQP dependency -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>
Copy the code

　　

The configuration file

　　

The configuration file needs to configure the message queue and bus-Refresh endpoints automatically. The/ACTUATOR/bus-Refresh endpoints clear the @RefreshScope cache rebinding property.

Configserver application. Yml core configuration.

spring:
  application:
    name: config-server # Application name
  cloud:
    config:
      server:
        git:
          uri: https://github.com/imrhelloworld/config-repo Address of the repository where the configuration file is located
          #username: #username used to log in to Github and other products
          #password: # Github products login password
          #default-label: master # config file branch
          #search-paths: # root directory for configuration files
  # Message queue
  rabbitmq:
    host: 192.16810.106.

Configure the Eureka Server registry
eureka:
  instance:
    prefer-ip-address: true       # Whether to use IP address registration
    instance-id: ${spring.cloud.client.ip-address}:${server.port} # ip:port
  client:
    service-url:                  Set the service registry address
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/

# Metrics monitoring and health check
management:
  endpoints:
    web:
      base-path: /actuator    # Access the root path of the endpoint. Default is /actuator
      exposure:
        include: bus-refresh  # Endpoints to be turned on
        #exclude: indicates the endpoint that does not need to be enabled
Copy the code

The article is from Le Byte