客户端获取到最新的配置信息需要执行refresh，可以利用webhook的机制每次提交代码发送请求来刷新客户端，当客户端越来越多的时候，需要每个客户端都执行一遍，这种方案就不太适合了。使用Spring Cloud Bus可以完美解决这一问题。
Spring cloud bus通过轻量消息代理连接各个分布的节点，消息代理中间件可以将消息路由到一个或多个目的地。
方案一
1. 外部通过给客户端A发送 post 请求 bus/refresh
2. 客户端A接收到请求从Server端更新配置并且发送给Spring Cloud Bus
3. Spring Cloud bus接到消息并通知给其它客户端
4. 其它客户端接收到通知，请求Server端获取最新配置
5. 全部客户端均获取到最新的配置
客户端 config-client 改造步骤：
1. 添加依赖
org.springframework.cloud
spring-cloud-starter-bus-amqp
2. 配置文件
## 刷新时，关闭安全验证
management.security.enabled=false
## 开启消息跟踪
spring.cloud.bus.trace.enabled=true
spring.rabbitmq.host=192.168.1.101
spring.rabbitmq.port=5672
spring.rabbitmq.username=admin
spring.rabbitmq.password=123456
注： pom.xml中引入了spring-cloud-starter-bus-amqp，就需要配置rabbitmq，否则启动报错
3. 测试
config-client 启动时会发现 mapped 中有 /bus/refresh
在win下使用下面命令来模拟webhook，会发现所有 config-client 端都已更新配置
curl -X POSThttp://localhost:8002/bus/refresh
4. 结果
config-client A先执行，然后 config-client B/config-client C 执行
存在缺陷
在上面的流程中，我们已经到达了利用消息总线触发一个客户端bus/refresh,而刷新所有客户端的配置的目的。但这种方式并不优雅。原因如下：
1. 打破了微服务的单一职责原则。微服务本身是业务模块，它本不应该承担配置刷新的职责。
2. 破坏了微服务各节点的对等性。
3. 有一定的局限性。例如，微服务在迁移时，它的网络地址常常会发生变化，此时如果想要做到自动刷新，那就不得不修改WebHook的配置。
改进版本
1. 外部通过给 config-server 发送 post 请求 bus/refresh
2. config-server 端接收到请求并发送给Spring Cloud Bus
3. Spring Cloud bus接到消息并通知给各个客户端
4. 各个客户端接收到通知，请求Server端获取最新配置
5. 全部客户端均获取到最新的配置
服务端 config-server 改造步骤：
1. 添加依赖
org.springframework.cloud
spring-cloud-starter-bus-amqp
2. 配置文件
## 刷新时，关闭安全验证
management.security.enabled=false
## 开启消息跟踪
spring.cloud.bus.trace.enabled=true
spring.rabbitmq.host=192.168.1.101
spring.rabbitmq.port=5672
spring.rabbitmq.username=admin
spring.rabbitmq.password=123456
注： pom.xml中引入了spring-cloud-starter-bus-amqp，就需要配置rabbitmq，否则启动报错
3. 测试
config-server 启动时会发现 mapped 中有 /bus/refresh
在win下使用下面命令来模拟webhook，会发现所有 config-client 端都已更新配置
curl -X POSThttp://localhost:8002/bus/refresh
4. 结果
config-client A/config-client B/config-client C 同时执行更新
刷新后的数据在 /env 断点中可以查看。数据更新效果类似于 spring-boot-admin
5. 客户端大概的获取更新配置步骤：
Fetching config from server at: http://localhost:7001
Shutting down DiscoveryClient ...
Unregistering ...
registering service...
registration status: 204
局部刷新
某些场景下（例如灰度发布），我们可能只想刷新部分微服务的配置，此时可通过/bus/refresh端点的destination参数来定位要刷新的应用程序。
例如：/bus/refresh?destination=config-clientA:test:8003，这样消息总线上的微服务实例就会根据destination参数的值来判断是否需要要刷新。其中，config-client:testA:8003指的是各个微服务的ApplicationContext ID。SpringBoot在 ContextIdApplicationContextInitializer 中设置该ApplicationContext ID，默认为spring.application.name:active profiles:server.port 的组合值，如config-clientA:test:8003，注意：该ID与 instance-id 没任何关系。
destination参数也可以用来定位特定的微服务。例如：/bus/refresh?destination=config-clientA:**，这样就可以触发 config-clientA 微服务所有实例的配置刷新，而 config-clientB 不会更新。
跟踪总线事件
一些场景下，我们可能希望知道Spring Cloud Bus事件传播的细节。此时，我们可以跟踪总线事件（RemoteApplicationEvent的子类都是总线事件）。
跟踪总线事件非常简单，只需设置spring.cloud.bus.trace.enabled=true，这样在/bus/refresh端点被请求后，访问/trace端点就可获得结果。
想要对接受到的消息自定义自己的处理方式的话，可以添加@EventListener注解的AckRemoteApplicationEvent和SentApplicationEvent类型到你自己的应用中。或者到TraceRepository类中，直接处理数据。
gitlab等更新后自动刷新
默认gitlab的webhook更新调用config server的/monitor(spring-cloud-config-monitor)触发RefreshRemoteApplicationEvent事件，然后spring cloud bus的StreamListener监听RemoteApplicationEvent，通过mq发布到每个config client，然后client接收RemoteApplicationEvent事件来实现refresh。
config-server需引入 spring-cloud-config-monitor
实例源码：config-bus
参考文档：https://www.cnblogs.com/ityouknow/p/6931958.html