一、訊息中心簡介
為了將各個應用系統之間進行業務解耦，對業務的透明化處理及技術架構的統一管理，方便對各應用的整體把控，保證系統的穩定性，也方便各應用的訊息中介軟體的快速搭建，因此搭建訊息中心，提供整體的解決方案。
相對於傳統應用間定時或事件驅動獲取資料的方式，使用訊息中心讓各應用感知其他應用的變動，採用主動推送的方式對資料的變化進行通知。
二、訊息中心業務場景
2.1應用系統間解耦合
應用之間的業務耦合過深，應用中的單個服務不可用可能會導致大面積的業務故障。
2.2 非同步
應用中或應用間的業務呼叫存在同步方法，呼叫時間過長導致效能下降，使用者體驗差。例如使用者登入時，需要記錄使用者的審計日誌等資訊，需要消耗時間，但是這是使用者登入所不必須的，使用訊息中心後可非同步實現，從而節約不必要的時間，快速登入提高使用者的登入體驗。
2.3 業務資料變化通知
各應用之間的資料變化需要通知其他應用並做相應的資料處理，比如基礎資料的業務變化需要通知到相關的業務系統。
2.4 業務事件通知
各業務系統的通知、提醒、待辦、待閱等資訊傳送到訊息中心，由訊息中心再傳送到對應的負責人。
2.5 流量控制
流量控制，
可以對大資料量的資料上傳通過訊息中心非同步儲存，提高系統的效能和穩定性。
2.6 大資料交換空間
應用中有大
量歷史資料需要遷移或者需要大資料量進行進行堆積處理，可通過訊息中心進行中轉。
三、訊息中心結構組成
3.1 認證授權和訪問控制
1）認證授權
第二：檢查是否有許可權操作虛擬主機中的資源（交換機和佇列）。
通過以上的檢查機制，訊息中心可以對使用者能夠訪問的資源列表進行控制，從而達到管理的目的。
2）訪問控制
對以上的認證授權機制外，還可以對接入
訊息中心的客戶端（傳送端和接收端）使用ip列表和接入的服務端檢查進行訪問控制,可使用外掛程式rabbitmq_auth_backend_ip_rang或rabbitmq_auth_backend_amqp；
3.2 可靠性
訊息傳送的可靠性需要保證：訊息傳送者把訊息傳送到訊息中心，訊息中心的訊息儲存和訊息中心把訊息投遞給訊息接收者。
其中訊息中心與訊息傳送端和接收端部門需要訊息傳送一致性進行支援，資料操作與訊息傳送放置在同一事務中，要不同時成立要不同時不成立。對於訊息中心本身的穩定及儲存安全保證設計一下的架構進行保證： 對最
終訊息架構選型rabbitmq集群部署，並提供只是乙個的磁碟節點（disc）和多個記憶體節點。使用haproxy對集群進行負載均衡分發，還可以對haproxy進行主備部署用keepalived進行負載。
3.3 安全
訊息中心的發生端和接收端的安全主要基於ssl和ca認證進行安全管理，可參見《訊息中心安全方案》。
3.4 訊息追蹤
傳送的所有訊息進行記錄，能夠進行查詢追蹤，可使用外掛程式rabbitmq_tracing(該外掛程式官方標註為實驗性外掛程式)，詳細資訊參見《訊息追蹤方案》。
3.5 訊息日誌分析
對於傳送的訊息進行轉存，然後根據資料的進行各種維度的分析。
四、訊息中心對應用的支援
各應用接入訊息中心時候，根據不同的業務要求訊息中心需要提供以下支援：
4.1 訊息傳送一致性
訊息傳送與應用的業務操作要求強一致性（兩者要不同時成立要不同時失敗）的需要提供相應的支援，具體可參見《訊息中心一致性方案》。訊息傳送的一致性要求保證與返回訊息狀態的速度成反比，平台可以根據訊息傳送一致性強弱要求和對效能的要求提供一下三種方案。
1）同步方式的完全一致性
將傳送訊息和業務操作在傳送端用進行事務管理，該情況是採用同步方式進行支援，傳送訊息的效率會比較慢，但是是唯一能保證完全一致性的方案。
2）非同步到交換器的一致性
非同步到交換器的一致性是指業務的操作與訊息的傳送同樣採用事務進行管理，但是訊息一致性要求不是特別高（比如登入大平台的時候會產生一條登入的審計資訊，但是該訊息有沒有被接收端接收，對平台的影響可以忽略並且相關資料的資料量特別大，則可採用該一致性方案）。該方案的訊息保證訊息進入交換器後非同步返回結果。
3）非同步到消費端的一致性
非同步到消費端的一致性是指資料一致性和處理效能都有一定要求的情況下，訊息傳送端非同步感知消費端對訊息的處理。
4.2 訊息傳送優先順序設定
當訊息中心內部訊息堆積量比較大的時候，訊息傳送的優先順序直接關係到訊息接收時效性，並且在同步一致性的情況下直接影響傳送的應用的反應效率。
4.3 訊息延遲傳送
延遲訊息訊息是指訊息傳送端傳送指定時間後訊息接收端才接收到訊息。比如使用者新增一張訂單後，要求在30分鐘之內進行付款，那可以要求訊息傳送端傳送訊息30分鐘後接收端再去檢查使用者的付款情況，並做相應處理。
延遲傳送（具體參見《訊息中心延遲傳送方案》）：
1）可以通過rabbitmq-delayed-message-exchange外掛程式實現；
2）需要rabbitmq的ttl與dle進行實現，延遲可以。架構大致如下：
4.4 保證訊息順序
保證訊息順序：對於多條依賴順序的訊息表達乙個資訊的時候，需要訊息消費者可以識別多條訊息的順序性，以正確讀取訊息的內容。應用場景：例如先後傳送兩天訊息，對同意使用者修改資訊和刪除使用者，接收端接收的訊息是先進行刪除操作，在進行修改操作。
4.5 重複訊息處理
由於訊息傳送各個環節、訊息傳送內部機制等原因，可能會導致一條訊息傳送之後訊息接收端接收到多條同樣的訊息，此時需要訊息接收端能夠判斷並處理相同訊息或訊息中心保證同一條訊息消費端只接收一次。
五、應用接入管理辦法
為了方便各應用能快速接入訊息中心加快開發進度，方便訊息中心對接入的應用進行統一管理，也為後續訊息中心進行訊息傳送的日誌和統計資訊等開展（對訊息中心的健壯性功能性的擴充套件），從以下方面制定接入訊息中心的管理辦法（具體參見《訊息中心接入管理辦法》）：
5.1 應用管理
1）對所有的鐵路管理系統的應用進行編號和編碼命名（比如基礎平台編號為1，編碼為base，即時通編號為5為jst）。
2）接入訊息中心時為該應用建立命名的使用者進行管理：一對一或一對多情況，在按照傳送端的應用建立的使用者內部建立虛擬主機，並建立相應的資源（exchange和queue）；多對一的情況按照接收端的應用建立的使用者內部建立虛擬主機；多對多建立單獨的應用並在內部進行關聯；
3）按照以上的管理辦法為每一類訊息進行統一的資源編號，並且進行全域性統一管理（比如平台1的審計資訊和登入審計的編號為1-1和1-2）。
5.2 訊息體管理
1）訊息設定唯一id進行管理；
2）訊息應用包含所屬應用的編號，如平台1訊息編號為1；
3）訊息設定傳送時間（方便追蹤）；
六、應用接入
7.1 前期對接
各應用接入訊息中心需要滿足以上的場景，若不符合以上場景卻想接入的需要與基礎平台組進行溝通，提出接入理由和應用場景等等。最後取得基礎平台組同意。
7.2 填寫接入對接文件
按照《訊息中心接入方案模板》填寫接入訊息中心的一下資訊：
1）傳送方、接收方；
2）訊息傳送的資料量；
3）大致訊息內容；
4）對訊息傳送一致性的要求；
5）訊息傳送的優先順序；
6）是否需要支援
延遲傳送訊息；
7）是否需要
支援訊息傳送順序控制；
8）重**送訊息處理的支援。
7.3 審核並接入
對接入文件進行審核，並分析應用現有訊息中心是否對即將接入的應用的業務支援，並按照以上的」應用接入管理辦法」為應用建立接入條件，並進行統一管理。
RabbitMq訊息中心 常用命令
為windiws的rabbitmq安裝外掛程式 rabbitmq plugins.bat enable rabbitmq management sbin目錄下執行後重啟rabbitmq 可在瀏覽器訪問 127.0.0.1 15672 進入管理介面 預設的使用者名稱密碼都是guest 1.搭建rabb...
RabbitMQ 訊息廣播
rabbitmq訊息模型的核心理念是 發布者 producer 不會直接傳送任何訊息給佇列。事實上，發布者 producer 甚至不知道訊息是否已經被投遞到佇列。發布者 producer 只需要把訊息傳送給乙個交換機 exchange 交換機非常簡單，它一邊從發布者方接收訊息，一邊把訊息推送到佇列。...
RabbitMQ 廣播訊息
定義 廣播訊息是指生產者產生的訊息將分發給所有訂閱這個訊息的消費者,而普通的模式是 一批訊息可以被多個人共同消費,如consumer1可能消費1,3,5記錄,而consumer2可能消費的是2,4,6這種模組就是共同消費模組 而今天說的是廣播訊息,它是指一些訊息同時被推送到多個訂閱者,而這些訂閱者收...