前言
SpringCloud Config Bus
上述的示例中，我们客户端发现每次获取最新配置都需要手动进行刷新，如果少的的话还可以使用，但是多的话就比较繁琐了，虽然我们可以使用类似Github的WebHook的工具。
WebHook是当某个事件发生时，通过发送http post请求的方式来通知信息接收方。
但是当客户端越来越多的时候WebHook已经不好使用了，每次新增客户端都需要更改WebHook会显得很麻烦，springcloud官方给出了非常好的解决方案，Spring Cloud Bus。
Spring cloud bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其他的消息指令。Spring bus的一个核心思想是通过分布式的启动器对spring boot应用进行扩展，也可以用来建立一个多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道，同样特性的设置（有些取决于通道的设置）在更多通道的文档中。
为什么使用Spring Cloud Bus就可以解决这个问题了呢？
我们不一定非要透彻的理解其原理才可以知道，我们只需要知道它的实现步骤，就可以知道了为什么可以解决了。
步骤如下:
- 首先，在配置中进行更新配置文件信息，它就会自动触发post发送bus/refresh；
- 然后服务端就会将更新的配置并且发送给Spring Cloud Bus；
- 继而Spring Cloud bus接到消息之后并通知给使用该配置的客户端；
- 最后使用该配置的客户端收到通知后，就会获取最新的配置进行更新；
这里我也简单的画了下使用Spring Cloud Bus之前和之后的流程图，方便进行理解。
不使用Spring Cloud Bus获取配置信息流程图:
使用Spring Cloud Bus获取配置信息流程图:
开发准备
和上述的环境一样即可。
局部刷新测试
完成上述全局刷新测试之后，有时我们只想刷新部分微服务的配置，那么便可以使用/actuator/bus-refresh/{destination}端点的 destination 参数来定位要刷新的应用程序。
我们继续更改configtest-pro.properties的配置为:
word=hello!!!然后依旧使用Postman工具发送post请求，地址为:
http://localhost:9005/actuator/bus-refresh/springcloud-config-bus-client2
然后我们再浏览器输入:
http://localhost:9006//hello?name=pancm
界面返回:
pancm,hello!! 浏览器输入:
http://localhost:9007//hello?name=pancm
界面返回:
xuwujing,hello!!！ 发现只有springcloud-config-bus-client2客户端的配置更新，另一个springcloud-config-bus-client没有进行刷新，达到了我们的目的。
示例图:
上述示例完成之后，我们把SpringCloud Config Refresh的测试在进行一遍，发现依旧可以实现，因此我们发现只要开启Spring Cloud Bus 后，不管是对服务端还是客户端，执行/actuator/bus-refresh都是可以更新配置的。
如果我们想进行跟踪总线事件的话，只需要在刷新配置之后，在地址后面添加
