一、簡介
在微服務架構的系統中，我們通常會使用輕量級的消息代理來構建一個共用的消息主題讓系統中所有微服務實例都連接上來，由於該主題中產生的消息會被所有實例監聽和消費，所以我們稱它為消息總線。
本期我們來了解下 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）》