SpringCloud Bus

SpringCloud Bus@[Mr_Wzzzz]

概述

用SpringCloud Config时，我们可以实现配置信息手动的动态刷新，也就是远端配置信息发生改变后，需要告诉服务端配置信息发生变化后，服务端才会更新配置信息，而现在我们想要实现分布式自动刷新配置信息功能，这就需要我们使用SpringCloud Bus消息总线配合SpringCloud Config实现配置信息的动态刷新。SpringCloud Bus是用来将分布式系统的节点与轻量级消息系统连接起来的框架，整合了Java的事件处理机制和消息中间件的功能，SpringCloud Bus目前支持两种消息代理：RabbitMQ和Kafka。SpringCloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改、事件推送等， 也可以当做微服务间的通信通道。

什么是总线

在微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，所以称它为消息总线。在总线上的各个实例，都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息。

SpringCloud Config客户端的实例都监听消息队列中的同一个主题（topic）（默认是SpringCloud Bus），当一个服务器刷新数据的时候，它会把这个信息放入到主题中，这样其他监听了同一主题的服务就能得到通知，然后去更新自身的配置。

SpringCloud Bus动态刷新全局广播

消息总线的两种设计模式：

• 利用消息总线触发一个客户端/bus/refresh端点，而后刷新所有客户端的配置：
  

• 利用消息总线触发一个服务端ConfigServer的/bus/refresh端点，而后刷新所有客户端的配置：
  
  一般情况下，我们选择第二种设计模式而不选择第一种设计模式，原因如下：

1. 第一种设计模式打破了微服务的职责单一性，因为微服务本身是业务模块，它本不应该承担配置刷新的职责；
2. 第一种设计模式其破坏了微服务各节点的对等性；
3. 第一种设计模式有一定的局限性，比如在微服务迁移时，它的网络地址常常会发生变化，此时如果想要做到自动刷新，那就会增加更多的修改。

配置

1. 在配置中心的POM文件中添加使用RabbitMQ实现消息总线的依赖：

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

2. 然后在其yaml配置文件中添加RabbitMQ的相关配置，暴露SpringCloud Bus刷新配置的端点

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

3. 在客户端的POM文件中添加RabbitMQ实现总线的依赖（同ConfigServer的相关依赖）
4. 然后在客户端yml配置文件中添加RabbitMQ的相关配置：

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

SpringCloud Bus动态刷新定点通知

再全局广播中，我们更新配置文件的信息对所有服务都进行了通知，但是假设我们只想通知3355，而不想通知3366又该怎么办呢，这就需要我们用定点通知的方法通知3355，也就是说我们进行消息通知时只指定具体某个实例生效而不是全部生效，这种情况下就需要修改我们发送的POST请求：

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

这样的话，/bus/refresh请求就不再发送到具体的服务实例上，而是发给ConfigServer配置中心并通过destination参数指定需要更新配置的服务或实例。其中destination具体为微服务+端口号。