Bus 一

    前面说了一下Config的动态刷新配置，但是动态刷新配置的时候我们需要手动的去Client端访问/refresh才能刷新配置，问题来了，随着服务的不断增加，我们需要手动去更新的服务会不断的增加。此时我们就需要一个能够快速帮我们刷新配置的项目。Bus就能帮我们很方便的去刷新这些配置。

    在微服务架构的系统中， 我们通常会使用轻量级的消息代理来构建一个共用的消息主题让系统中所有微服务实例都连接上来， 由于该主题中产生的消息会被所有实例监听和消费， 所以我们称它为消息总线。 在总线上的各个实例都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息， 例如配置信息的变更或者其他一些管理操作等。

    由于消息总线在微服务架构系统中被广泛使用， 所以它同配置中心一样， 几乎是微服务架构中的必备组件。 Spring Cloud 作为微服务架构综合性的解决方案，对此自然也有自己的实现， 这就是本章我们将要具体介绍的 Spring Cloud Bus。 通过使用 Spring Cloud Bus,可以非常容易地搭建起消息总线， 同时实现了一些消息总线中的常用功能， 比如， 配合Spring Cloud Config 实现微服务应用配置信息的动态更新等。

    消息代理:

    消息代理 (Message Broker) 是一种消息验证、 传输、 路由的架构模式。 它在应用程序之间起到通信调度并最小化应用之间的依赖的作用， 使得应用程序可以高效地解耦通信过程。 消息代理是一个中间件产品， 它的核心是一个消息的路由程序， 用来实现接收和分发消息， 并根据设定好的消息处理流来转发给正确的应用。 它包括独立的通信和消息传递协议， 能够实现组织内部和组织间的网络通信。 设计代理的目的就是为了能够从应用程序中传入消息， 并执行一些特别的操作， 下面这些是在企业应用中， 我们经常需要使用消息代理的场景：

 将消息路由到一个或多个目的地。

 消息转化为其他的表现方式。

 执行消息的聚集、 消息的分解， 并将结果发送到它们的目的地， 然后重新组合响应返回给消息用户。

 调用Web服务来检索数据。

响应事件或错误。

 使用发布－订阅模式来提供内容或基千主题的消息路由。

目前已经有非常多的开源产品可以供大家使用， 比如：• ActiveMQ• Kafka• RabbitMQ• RocketMQ．当前版本的Spring Cloud Bus仅支待两款中间件产品： RabbitMQ和Kafka。

RabbitMQ和Kafka的实现我在前面都去实现过，所以在这里就不重复的讲解了。

    从这里就可以看出，Bus就是一个MQ，通过消息队列的方法将微服务串起来，这样就可以将各个微服务之间耦合度降低，也可以达到异步执行的效果。

这里就不多介绍了，现在主要的目的是如何用Bus来达到我们动态刷新的效果。

努力吧，皮卡丘。