文章持续更新中，欢迎关注！
为什么要用SpringCloud Bus?用SpringCloud Config时，我们可以实现配置信息手动的动态刷新，也就是远端配置信息发生改变后，需要告诉服务端配置信息发生变化后，服务端才会更新配置信息，而现在我们想要实现分布式自动刷新配置信息功能，这就需要我们使用SpringCloud Bus消息总线配合SpringCloud Config实现配置信息的动态刷新。
SpringCloud Bus 原理简介Spring Cloud Bus 使用轻量级的消息代理来连接微服务架构中的各个服务，可以将其用于广播状态更改（例如配置中心配置更改）或其他管理指令
通常会使用消息代理来构建一个主题，然后把微服务架构中的所有服务都连接到这个主题上去，当我们向该主题发送消息时，所有订阅该主题的服务都会收到消息并进行消费。
使用 Spring Cloud Bus 可以方便地构建起这套机制，所以 Spring Cloud Bus 又被称为消息总线。
Spring Cloud Bus 配合 Spring Cloud Config 使用可以实现配置的动态刷新。
目前 Spring Cloud Bus 支持两种消息代理：RabbitMQ 和 Kafka。
SpringCloud Bus动态刷新全局广播在学习SpringCloud Config的时候我们已经建立了服务springcloud-config-client，端口号为3355，作为Config的客户端，这里为了演示广播效果，我们增加复杂度，再以3355为模板再制作另一个Config的客户端3366，建立Module：springcloud-config-client3366，其结构和springcloud-config-client，端口号为3355类似，修改下服务端口号即可
1.消息总线的两种设计思想： 方案一：利用消息总线触发一个客户端/bus/refresh端点，而后刷新所有客户端的配置 方案二：利用消息总线触发一个服务端ConfigServer的/bus/refresh端点，而后刷新所有客户端的配置明显第二种架构更加合适，第一种架构不合适的原因主要有：
-
打破了微服务的职责单一性，因为微服务本身是业务模块，它本不应该承担配置刷新的职责；
-
破坏了微服务各节点的对等性；
-
有一定的局限性，比如在微服务迁移时，它的网络地址常常会发生变化，此时如果想要做到自动刷新，那就会增加更多的修改。
所以虽然从技术上两种方案都可以实现，但是无疑在技术选型上我们应该选择第二种方案。
2.给springcloud-config-center配置服务中心服务端ConfigServer添加消息总线支持在其POM文件中添加使用RabbitMQ实现消息总线的依赖：
org.springframework.cloud spring-cloud-starter-bus-amqp
然后在其yaml配置文件中添加RabbitMQ的相关配置，暴露SpringCloud Bus刷新配置的端点
# RabbitMQ相关配置
spring:
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
# 暴露总线刷新配置的端点
management:
endpoints:
web:
exposure:
include: 'bus-refresh'
3.给springcloud-config-client3366，springcloud-config-client两个客户端添加消息总线支持
在其POM文件中添加RabbitMQ实现总线的依赖（同ConfigServer的相关依赖）：
org.springframework.cloud spring-cloud-starter-bus-amqp
然后在其yaml配置文件中添加RabbitMQ的相关配置：
# RabbitMQ相关配置
spring:
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
4.测试
按顺序启动Eureka服务注册中心7001，ConfigServer配置中心3344，ConfigClient配置中心客户端3355/3366，此时远端GitHub上的配置信息如下：
config:
info: "config.info"
分别访问配置中心http://localhost:3344/master/config-dev.yml及其配置中心客户端http://localhost:3355/config/http://localhost:3366/config：
然后将Gitee远端的配置信息中的info改为"config.info, version = 4"，然后对服务配置中心发送POST请求：
curl -X POST "{配置中心的地址}/actuator/bus-refresh"
如，此时我们该发送的POST请求为：
curl -X POST "http://localhost:3344/actuator/bus-refresh"
此时再分别访问配置中心http://localhost:3344/master/config-dev.yml及其配置中心客户端http://localhost:3355/config/http://localhost:3366/config：
发现所有服务的配置信息都得到了更新，打开RabbitMQ的控制面板，我们可以发现有一个交换机，这就对应消息总线发送消息的交换机：
再全局广播中，我们更新配置文件的信息对所有服务都进行了通知，但是假设我们只想通知3355，而不想通知3366又该怎么办呢，这就需要我们用定点通知的方法通知3355，也就是说我们进行消息通知时只指定具体某个实例生效而不是全部生效，这种情况下就需要修改我们发送的POST请求：
curl -X POST "http://{配置中心的地址}/actuator/bus-refresh/{destination}"
样的话，/bus/refresh请求就不再发送到具体的服务实例上，而是发给ConfigServer配置中心并通过destination参数指定需要更新配置的服务或实例。其中destination具体为微服务+端口号。
比如现在我们修改远端配置文件，但是我们只想通知3355的配置更新信息，而不想通知3366，此时我们发送的POST请求就应该是：
curl -X POST "http://localhost:3344/actuator/bus-refresh/springconfig-client:3355"
将Gitee远端的配置信息中的info改为"config.info, version = 5"，然后对服务配置中心发送上面的POST请求，
此时再分别访问配置中心http://localhost:3344/master/config-dev.yml及其配置中心客户端http://localhost:3355/config/http://localhost:3366/config，我们发现3355的配置信息得到了更新，而3344的配置中心仍然是之前的配置：
我们Spring Cloud Bus到这里就学习完毕了，so easy！
下一篇文章我们学习Spring Cloud Stream消息驱动，持续学习，持续更新，下一节更精彩！欢迎朋友们点赞关注！感谢！
