Config，其所能达到的极限也只是通过发送一个POST请求，手动版的实现动态刷新。 我们想解决这样的几个情形：
- GitHub上的配置文件修改后，可否广播一下，不用每个微服务都通过发送POST请求动态刷新。
- 可不可以该刷新的刷新，不想刷新的不刷新。
1.概述
1.1 是什么
我们想实现分布式的自动刷新配置功能，不是通过手动发送POST请求实现刷新。 SpringCloudBus配合SpringCloudConfig使用可以实现配置的动态刷新。
配置更新后，将A刷新一下（推给A），然后通过总线“传染”给了其他的微服务。
Bus支持两种消息代理：RabbitMQ和Kafka
1.2 能干嘛
Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改、事件推送等，也可以当作微服务间的通信通道。
这里是推送给ConfigServer，跟上面推送给客户端是不一样的。
1.3 为什么被称为总线
什么是总线：在微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有微服务实例都连接上来。由于该主题中产生的消息会被所有实例监听和消费，所以称它为消息总线。在总线上的各个实例，都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息。
基本原理：ConfigClient实例都监听MQ中同一个topic(默认是springCloudBus)。当一个服务刷新数据的时候，它会把这个信息放入到Topic中，这样其它监听同一Topic的服务就能得到通知，然后去更新自身的配置。
2.RabbitMQ环境配置
RabbitMQ:安装与WEB管理插件
3.SpringCloud Bus动态刷新全局广播
3.1 Bus动态刷新全局广播的设计思想和选型
1、利用消息总线出发一个客户端/bus/refresh，从而刷新所有客户端的配置
2、利用消息总线接触一个服务端ConfigServer的/bus/refresh断点，从而刷新所有客户端的配置
图二的框架显然更合理一些，图一不适合的原因如下：
- 破坏了微服务的职责单一性，因为微服务本身是业务模块，它不应该承担配置刷新的功能
- 破坏了微服务各结点的对等性
- 有一定的局限性： 微服务迁移时，它的网络地址常常会发生变化，此时如果想要做到自动刷新，那就回增加更多的修改。
所以我们使用第二种：通知总线，总线再通知所有客户端。
3.2 添加一个新的cloud-config-client-3366
演示广播效果，增加复杂度，再以3355为模板再制作一个3366
3.2.1 pom
pom.xml 和3355一样
3.2.2 yml
application.yaml
3.2.3 主启动类
ConfigClientMain3366
3.2.4 业务类controller
ConfigClientController
3.3 配置案例
3.3.1 给cloud-config-center-3344配置中心服务端添加消息总线支持
pom
yml： 注意对齐
3.3.2 给cloud-config-client-3355/3366客户端添加消息总线支持
pom
yml：
3.4 测试
启动7001,3344,3355,3366
修改GitHub上的配置文件
给3344Config-Server发送Post请求，刷新3344
http://127.0.0.1:3366/configInfo，http://127.0.0.1:3355/configInfo 都更新了
基本原理回顾
ConfigClient实例都监听MQ中同一个topic（默认是SpringCloudBus）。 在RabbitMQ中找到了这个topic订阅主题/exchange路由交换机。
当一个服务刷新数据时，它会把这个信息放到Topic中，这样其他监听同一Topic的服务就能得到通知， 然后去更新自身的配置。
4.SpringCloud Bus动态刷新定点通知
我们这里以刷新运行在3355端口上的config-client为例，只通知3355，不通知3366
curl -X POST "http://localhost:3344/actuator/bus-refresh/config-client:3355"
成功：3355刷新，3366未刷新
5.流程总结
