消息總線 Message bus

場景：

　　在一個集成環境中存在不一樣應用，這些應用的提供者不一樣且這些應用運行在各類各樣的平臺上。其中的一些

應用程序生產消息，其餘不少應用程序消費這些消息。

　　例如，某金融方面應用程序集成了貿易工具、投資管理應用、模型和風險分析工具、貿易指示以及自動收報機。

市場活動致使系統的交換。例如，一個貿易系統經過發送消息到其餘貿易應用程序來實現賣出事務的操做。貿易

系統各自鏈接每個貿易應用程序。在應用程序較少的時候這些操做可以執行，可是隨着應用程序數量的增長，

系統負擔將愈來愈重。而實際上，增長或刪除貿易程序不該該影響貿易的處理過程。

 

問題：

　　隨着集成環境愈來愈複雜，如何才能下降添加或刪除應用所帶來的開銷？

 

約束：

　　添加一個應用程序到集成環境或刪除集成環境中的一個應用須要平衡下列約束：

　　1. 應用程序間的通訊一般需建立程序間的依賴，發送端必須能與接收端通訊，接收端必須能識別從全部發送

端發來的消息。這些依賴轉化成不一樣應用間的耦合。

　　2. 當採用點對點的方式來鏈接時，耦合數隨着應用程序的增長呈平方增加。例如，三個已鏈接的應用程序

須要三個鏈接，可是10個應用程序須要45個鏈接。而鏈接數愈來愈多，維護管理、修改和集成的難度愈來愈大。

　　3. 一般，應用程序集成解決方案有不一樣接口。修改應用程序的接口難度是很大的，即便能改變一個應用程序

的接口，改變全部應用的接口幾乎是不可能的。

　　4. 一些集成解決方案由一組固定的程序組成。一個集成解決方案很難擴展或修改需求，當他不須要適應新

應用時。

 

解決方案：

　　經過一個邏輯組件，即消息總線來完成全部應用程序的鏈接，一個消息總線明確消息傳遞的發送方和接

收方。一個消息總線包含三個關鍵的元素：

　　1. 一組達成一致的消息計劃。

　　2. 一組公共命令消息。

　　3. 共享通訊基礎框架來發送總線消息到接收端。

 使用消息總線時，應用程序發送消息再也不單獨鏈接其餘應用程序，只須要將消息發佈到消息總線上，消息總線將

消息發送到全部其餘監聽總線上消息的應用上。一樣，應用程序再也不直接接收來自其餘發送者的消息，而是從

消息總線上獲取消息。實際上，消息總線減小了每一個應用輸出端的數量，由多個減小到一個。

　　一般，總線不保證消息秩序。內部的優化、路由選擇、緩衝等甚至優先傳輸機制可能影響消息具體傳遞到

接收端的方式。所以，消息到達的順序是不肯定的。例如，發送端可以插入有序的數據到消息中，而後接收端

可使用這些數據並進行重排，邏輯順序能夠由總線提供，且邏輯順序對於應用程序能夠是透明的。然而，

這種附加的邏輯不是必須的。

　　下圖一描述了一個集成環境下使用消息總線的形式。經過總線發送消息的應用程序必須準備好消息，以便消息符合總線指望的消息類型。相似的，應用程序接收消息時必須可以理解消息類型。若是集成環境中全部的應用程序都實現

了總線接口，增長或移除應用程序對總線沒有影響。

　　消息總線與應用程序間共享的基礎通訊框架可使用消息路由來實現，而消息路由可使用訂閱發佈機制來實現。

以下圖，展現了消息總線與訂閱發佈模式的關係。

　　期待將某一特殊的消息總線運用在訂閱發佈的實現中，對消息總線架構產生了深遠的影響。實現訂閱發佈模式

包含三類方式：http://www.cnblogs.com/svenzhang9527/p/7351769.html

 

消息總線與基於鏈表的訂閱發佈模式

Message Bus with List-Based Publish/Subscribe

　　基於鏈表的訂閱發佈模式本質包含兩點，一是維護包含發佈主題和訂閱者信息的鏈表，二是當事件發生時，通知

該鏈表中的元素處理事件信息。

　　爲了使用包含基於鏈表的訂閱發佈機制的消息總線，當系統發送命令消息到消息總線時，消息總線檢查全部感

興趣的消息總線訂閱方，並給每一個消息總線發送一個原始消息的拷貝。任何同消息有關的數據都使用通用格式，以便

全部系統都能理解命令和數據，並給出合理回覆。

 

消息總線與基於廣播的訂閱發佈模式

Message Bus with Broadcast-Based Publish/Subscribe