在上篇文章《微服務之配置中心》中寫到，客戶端可從服務端獲取配置資訊，當git倉庫中的配置檔案修改後，為了讓客戶端獲取最新的配置資訊，可以通過執行refresh操作進行手動重新整理。但是這樣有問題，當客戶端很多時（隨之系統的不斷擴大），如果需要每個客戶端都執行一遍，那就蛋疼了，顯然這種方案就不適合了。spring cloud作為微服務架構的乙個綜合解決方案，也提供了對應的解決方案spring cloud bus，即訊息匯流排。
這裡要理解乙個概念，訊息匯流排。簡單理解就是乙個訊息中心，眾多微服務例項可以連線到匯流排上，例項可以往訊息中心傳送或接收資訊（通過監聽）。比如：例項a傳送一條訊息到匯流排上，匯流排上的例項b可以接收到資訊（例項b訂閱了例項a），這樣的話，訊息匯流排就充當乙個中間者的角色，使得例項a和例項b解偶了，很方便。
spring cloud bus通過建立多個應用之間的通訊頻道，管理和傳播應用間的訊息，從技術角度來說，應用了amqp訊息**作為通道，通過mq的廣播機制實現訊息的傳送和接收。以其典型應用——配置中心客戶端重新整理為例，說明下工作流程：
（1）修改配置檔案，觸發webhook向clienta傳送bus/refresh；
（2）clienta重新從配置中心獲取新的配置資訊，同時傳送訊息到spring cloud bus；
（3）spring cloud bus收到訊息，同時通知clientb、clientc（訂閱配置更新事件）；
（4）clientb、clientc收到通知，重新請求配置中心，獲取新的配置資訊。
這樣，三個客戶端均得到最新的配置。
這個過程中，作為通道的amqp訊息**很重要。amqp（高階訊息佇列協議，是乙個標準）是乙個網路協議，從扮演角色來說，訊息**從生產者（producers）那兒接收訊息，並根據既定的路由規則把接收到的訊息傳送給處理訊息的消費者（consumers）,這個過程中的發布者，消費者，訊息**可以存在於不同的裝置上，下面簡單介紹下工作流程（其實跟上面的類似）：
訊息（message）被發布者（publisher）傳送給交換機（exchange），交換機常常被比喻成郵局或者郵箱。然後交換機將收到的訊息根據路由規則分發給繫結的佇列（queue）。最後amqp**會將訊息投遞給訂閱了此佇列的消費者，或者消費者按照需求自行獲取。
amqp作為乙個標準協議，主要實現方案有rabbitmq、activemq、qpid等。這裡我主要以rabbitmq為例進行說明，它是乙個優秀的微服務架構訊息中介軟體，與spring cloud bus能夠很好的結合使用。
下圖顯示了rabbitmq的web管理首頁：
（1）broker：訊息佇列伺服器，即負責接收生產者訊息，傳送至消費者的；
（2）connections：連線，即傳送者、訊息接收者、消費者之間的物理連線；
（3）channel：通道，連線生產者、消費者的邏輯結構。乙個connection可以對應多個channel；
（4）exchange：訊息交換機，訊息第乙個到達的地方，可以指定路由規則，決定訊息分發到不同的訊息佇列中去；
（5）queue：訊息佇列，訊息經exchange路由**至此，進入邏輯等待狀態（等待消費，即客戶端獲取）；
（6）binding：繫結，把exchange和queue按照路由規則進行繫結，即決定exchange接收訊息後，需要傳送到哪些queue中：
config server服務端
（1）在config server新增rabbitmq依賴，非常簡單：
（2）修改配置檔案，新增rabbitmq的配置資訊：
（3）啟動類加註解：
config client客戶端
（1）在config client新增rabbitmq依賴，非常簡單：
（2）修改配置檔案，新增rabbitmq的配置資訊：
eureka server註冊中心
省略。（1）啟動eureka server註冊中心、configserver服務端、config client客戶端（開啟兩個例項），如圖：
（2）客戶端獲取配置檔案的值，如圖：
（4）通過curl執行重新整理操作（配置服務端執行/bus/refresh），如圖：
（5）客戶端重新獲取配置檔案的值，可知已獲取最新配置資訊，如圖：
（6）至此完成配置自動重新整理，當部署正式環境時，可以在配置檔案修改時自動執行乙個操作：curl -x post http://localhost:8889/bus/refresh，在碼雲後台可以進行設定（這裡測試環境，設定不了，必須是公網位址），如圖：
有時我們只想重新整理部分微服務的配置，此時可通過/bus/refresh端點的destination引數來定位要重新整理的應用程式。
重新整理指定例項（某一服務）
執行：/bus/refresh?destination=customers:9000，
重新整理全部例項（某一服務）
執行：/bus/refresh?destination=customers:**，這樣就可以觸發customers微服務所有例項的配置重新整理。
注意：這裡的區分大小寫。
SpringCloud之訊息匯流排
spring cloud bus通過輕量訊息 連線各個分布的節點。這會用在廣播狀態的變化 例如配置變化 或者其他的訊息指令。spring bus的乙個核心思想是通過分布式的啟動器對spring boot應用進行擴充套件，也可以用來建立乙個多個應用之間的通訊頻道。目前唯一實現的方式是用amqp訊息 作...
SpringCloud 之Bus訊息匯流排
流程總結 架構優化 之前使用actuator監控中心完成重新整理功能，但是在config client服務端需要傳送post請求來手動重新整理，如果config client有很多的話，那麼需要乙個乙個地傳送post請求，這顯然是不現實的做法。使用訊息佇列中的topic，通過訊息實現通知。目前spr...
微服務 事件匯流排 非同步事務Cap
例如 事物 所有看到的一切都是事物，不能看到的也是事物 例如 團隊微服務，成員微服務，聚合微服務，閘道器api，認證中心等等包括類，物件 所有的事件都是事物變化的結果 事件就是指事物狀態的變化，每一次事物變化的結果都稱作為事件 就是用來管理所有的事件的一種機制就稱作為事件匯流排 包括事件發布，事件儲...