Spring Cloud构建微服务架构（七）消息总线
一、简介
在微服务架构的系统中，我们通常会使用轻量级的消息代理来构建一个共用的消息主题让系统中所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，所以我们称它为消息总线。
本期我们来了解下 Spring Cloud 体系中的另外一个组件 Spring Cloud Bus (建议先熟悉 Spring Cloud Stream《Spring Cloud Stream》，不然无法理解 Spring Cloud Bus 内部的代码)。
Spring Cloud Bus 对自己的定位是 Spring Cloud 体系内的消息总线，使用 message broker 来连接分布式系统的所有节点。Bus 官方的 Reference 文档 比较简单，简单到连一张图都没有。
Srping cloud Bus的底层实现就是Spring Cloud Stream，Spring Cloud Stream的目的是用于构建基于消息驱动（或事件驱动）的微服务架构。Spring Cloud Stream本身对Spring Messaging、Spring Integration、Spring Boot Actuator、Spring Boot Externalized Configuration等模块进行封装（整合）和扩展。
二、消息代理
消息代理(Message Broker)是一种消息验证、传输、路由的架构模式。它在应用程序之间起到通信调度并最小化应用之间的依赖的作用，使得应用程序可以高效地解耦通信过程。消息代理是一个中间件产品，它的核心是一个消息的路由程序，用来实现接收和分发消息， 并根据设定好的消息处理流来转发给正确的应用。 它包括独立的通信和消息传递协议，能够实现组织内部和组织间的网络通信。设计代理的目的就是为了能够从应用程序中传入消息，并执行一些特别的操作，下面这些是在企业应用中，我们经常需要使用消息代理的场景：
- 将消息路由到一个或多个目的地。
- 消息转化为其他的表现方式。
- 执行消息的聚集、消息的分解，并将结果发送到它们的目的地，然后重新组合响应返回给消息用户。
- 调用Web服务来检索数据。
- 响应事件或错误。
- 使用发布－订阅模式来提供内容或基千主题的消息路由。
什么时候用cloud bus
spring cloud bus在整个后端服务中起到联通的作用，联通后端的多台服务器。我们为什么需要他做联通呢？
后端服务器一般都做了集群化，很多台服务器，而且在大促活动期经常发生服务的扩容、缩容、上线、下线。这样，后端服务器的数量、IP就会变来变去，如果我们想进行一些线上的管理和维护工作，就需要维护服务器的IP。
比如我们需要更新配置、比如我们需要同时失效所有服务器上的某个缓存，都需要向所有的相关服务器发送命令，也就是调用一个接口。
你可能会说，我们一般会采用zookeeper的方式，统一存储服务器的ip地址，需要的时候，向对应服务器发送命令。这是一个方案，但是他的解耦性、灵活性、实时性相比消息总线都差那么一点。
总的来说，就是在我们需要把一个操作散发到所有后端相关服务器的时候，就可以选择使用cloud bus了。
使用cloud bus之后，我们的服务端架构会变成这样：
cloud bus能做什么？
当前spring cloud bus提供了两个可用的接口:
- /bus/env用于设置某一个配置项
- /bus/refresh用于刷新所有绑定到刷新点的配置项
这两个接口是使用spring boot actuator方式发布出来的（可以参见：深入SpringBoot:自定义Endpoint一文），接收到消息后会使用spring的stream框架（可以参考：张开涛的解Spring事件驱动模型一文）把消息传播到所有注册的相关服务器。
/bus/env的参数格式：
name=&value=&destination=
/bus/refresh的参数格式：
destination=
当然了，上述的destination参数都可以不提供。
应用场景
1、spring cloud config 配合spring cloud bus实现配置信息更新 ， 见《通过消息总线Spring Cloud Bus实现配置文件刷新（使用Kafka或RocketMQ）》
