一、简单介绍一下spring cloud Bus
在微服务架构的系统中，我们通常会使用轻量级的消息代理来构建一个共用的消息主题让系统中所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，所以我们称它为消息总线。在总线上的各个实例都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息，例如配置信息的变更或者其他一些管理操作等。
由于消息总线在微服务架构系统中被广泛使用，所以它同配置中心一样，几乎是微服务架构中的必备组件。Spring Cloud作为微服务架构综合性的解决方案，对此自然也有自己的实现，这就是本章我们将要具体介绍的Spring Cloud Bus。通过使用Spring Cloud Bus，可以非常容易地搭建起消息总线，同时实现了一些消息总线中的常用功能，比如，配合Spring Cloud Config实现微服务应用消息的动态更新等。
二、消息代理
消息代理是一种消息验证、传输、路由的架构模式。它在应用程序之间起到通信调度并最小化应用之间的依赖作用，使得应用程序可以高效地解耦通信过程。消息代理是一个中间件产品，它的核心是一个消息的路由程序，用来实现接受和分发消息，并根据设定好的消息处理流来转发给正确的应用。它包括独立的通信和消息传递协议，能够实现组织内部和组织间的网络通信。
现成的有：ActiveMQ、Kafka、RabbitMQ、RocketMQ
目前Spring Cloud Bus支持RabbitMQ(自动化配置)和Kafka(卡夫卡.。哈哈)，本文采用的是RabbitMQ。
三、开始实现spring cloud config的动态加载
1、修改pom.xml文件
2、修改配置文件
“*” 表示暴露所有 endpoints 出去，默认只有“health”，“info”，当然我们主要是需要用到“bus-refresh”来实现动态路由。
也可以在配置文件中添加spring.cloud.bus.trace.enabled=true。
spring.cloud.bus.trace.enabled=true配置之后，当我们动态加载获取配置文件之后访问/trace就可以跟踪总线事件。知道那个服务更新了配置文件（非常平易近人的设计，nice）。
3、启动RabbitMQ
真心将这个页面有点多余，我们目前只需要查看消息队列中是否有消息即Queues
4、启动配置中心
然后发现RabbitMQ的消息队列中已经有一条消息了。
5、在我们需要用到动态更新的服务中添加注解@RefreshScope（也就是config-client）
添加相关依赖
spring-boot-starter-actuator这个依赖也是必须的。如果缺了这个，当对服务端执行/actuator/bus-refresh的时候，
config-client接收不到信息。
然后启动这个服务。
现在已经有两个消息队列了。
6、开始测试是否可以动态加载git上的配置信息。
这个配置文件是网关的配置信息。配置信息告诉我们可以通过/bins这个路径访问端口号为8901中的信息。如：
我们访问到了，接下来修改git中的配置文件信息。将/bins路径修改为/superbin
然后我们通过postman发送一个post请求http://localhost:8888/actuator/bus-refresh让配置文件动态刷新。
这个必须要修改成json否则请求无法被解析。
此时我们再通过http://localhost:8661/bins/my/test这个路径访问就会报404
但是用http://localhost:8661/superbin/my/test路径就可以访问到。
至此实现spring cloud config的动态刷新。但是我们总不能每次在git上更新配置文件之后手动再发送一下post请求吧？git的webHooks为我们提供了完美的解决。
由于我的是内网，因此需要用到内网穿透才可以实现这点，本篇文章就不实现了。接下来的文章会介绍和实现内网穿透。
