中通訊息服務運維平臺實踐（已開源）

中通快遞 （歡迎進入?中通快遞官網瞭解更多資訊） 每天有數千萬的運單在各個環節運轉，每個環節都有對應的多套業務系統來支撐，業務系統之間上下游關係較為密切，從上游的客戶訂單到下游轉運、結算、分析等每個環節都離不開訊息中介軟體，它主要解決了系統之間的耦合、業務的削峰填谷、非同步通訊、資料同步和冗餘儲存等等功能需求，是現有系統架構中不可或缺的重要一環。

在2015年中通開始大量採用訊息中間解決一些特定的問題，隨著業務的增長，各環節有了更精細化的產品，我們訊息中介軟體的資料體量越來越大，叢集規模越來越多，中介軟體也越來越多樣化，統一管理這些訊息中介軟體變得尤為重要，因此我們研發了中通訊息中介軟體平臺 ZMS，主要基於 RocketMQ+Kafka 兩套業界比較主流訊息中介軟體，提供了自動化部署、主題/消費者的申請稽核、統一的SDK、管理控制檯、監 控告警到無感知擴容遷移等一系列運維的功能，目前ZMS管理了17個叢集，包括 7個 Kafka 叢集和 10個 RocketMQ 叢集，主題近2000個，消費組3000+，訊息儲存空間超過140TB，日均訊息流轉更是達到千億級別。

ZMS 從最初的版本演進到現在基本根據每個階段的痛點不同，解決不同的問題。 其發展階段大概分為 如下三個維度展開。

經公司內部評估，ZMS 已經成長為一套相對成熟的訊息中介軟體雲平臺化解決方案，可以正式對外開放，與社會上的同行共同打磨，故決定於2020年5月26號正式開源，將程式碼推送到 github 倉庫。

★ 倉庫地址：

0 1

自動化運維與部署

自動化運維部署，主要是方便運維人員可以快速透過ZMS平臺嚮導式初始化一個叢集，其架構設計如下圖所示。

zms-portal： zms 管理後臺，可同時管理多個環境的資源，包括：新增主機、服務，訊息叢集狀態監控、配置訊息叢集告警規則，訊息叢集資源管理等。

備註： 所謂的環境我們可以簡單看成是開發環境、測試環境、高保真環境、生產環境。

在每臺機器上首先需要安裝 zms-agent (代理服務)、supervisor 等基礎元件，為了方便運維，ZMS 提供了一鍵初始化主機的指令碼，自動在目標主機上安裝基礎服務元件，其操作流程如下：

運維人員只需要去指定的機器上覆制上述命令即可。這樣實現的目的是 zms-portal 無需管理宿主機器的使用者名稱、密碼等敏感資訊，做到安全可控。zms 能自動感知安裝了 zms-agent 的機器並將其納入 zms-portal 的管理運維體系。

在 ZMS 中我們統一將 Kafka、RocketMQ、ZK、監控指標採集、監控告警等統一看成是一個服務，在不同的環境中可以選擇性的安裝，其操作如下圖所示：

0 2

統一的客戶端 SDK

基於中通業務的特點專案中主要採用了 Kafka 與 RocketMQ 兩種不同的訊息中介軟體，如果業務方在自己專案中既要使用 Kafka 的訊息中介軟體，又要使用 RocketMQ 的訊息中介軟體，對於訊息中介軟體的使用來說要求非常高，因為需要了解這些相似又不同的 API，分別瞭解其配置引數與其代表的含義，因此為業務方提供統一的 API 顯得尤為重要與迫切。

zms-sdk 的主要設計理念：

﹡  遮蔽底層訊息中介軟體型別，提供統一標準的API。

﹡  提供標準的埋點，方便打造完備的監控體系。

﹡  雲平臺化，開發人員只需關注 TOPIC、消費組本身，無需關注 TOPIC 儲存在哪個叢集上，即 TOPIC、消費組b被定義成資源，使用者只需按需向平臺申請 topic、消費組即可。

zms-sdk 的整體架構設計如圖所示：

主要的互動與設計要點如下：

﹡ 運維人員透過 zms-portal 線上安裝叢集，叢集的後設資料將會存在 zookeeper 中。

﹡ 開發人員透過在 zms-portal 申請 topic、消費組。

﹡ 運維人員在 zms-portal 中對使用者的申請進行審批，並根據使用者的需求分配到適合的叢集中，topic 所在叢集等元資訊會寫入到 zookeeper中。

﹡ 開發人員透過 zms-sdk 向所申請的 topic 傳送訊息，zms-sdk 內部會從 zk 獲取 topic 對應的元資訊並建立對應的客戶端，最終完成訊息的傳送。

整個設計的核心是引入 zookeeper 作為後設資料的儲存倉庫，並充分利用其事件監聽機制，能完成很多“高大上”的功能，例如主題線上遷移功能。

試想一下在雙十一等大促場景，如果一個叢集負載很高從而達到瓶頸，一方面是可以對叢集進行擴容，另外一種可行的方法是 將該叢集中的 topic 遷移到其他空閒叢集，正是依託於 zookeeper 的事件機制，應用客戶端無需重啟就可以自動感知 topic 的配置發生了變化，從而重新構建到新叢集的客戶端物件，完成訊息傳送的不停機線上遷移。

0 3

監控資料採集服務

對訊息中介軟體進行監控並進行視覺化展示是運維最基本的需求，RocketMQ、Kafka 訊息中介軟體本身提供了監控資料的採集並儲存在各自的伺服器記憶體中，但是是非持久化的，在記憶體中只儲存當前時間段的呼叫資訊，並隨著時間的推進，舊的資料將被刪除。當然 RocketMQ、Kafka 都提供了相應的API方便客戶端採集儲存在服務端記憶體中的監控資料。

ZMSCollector 的職責就是定時向 RocketMQ、Kafka 叢集採集相關的呼叫資訊並持久化到 influxdb 中，為後續的視覺化展示提供必要的基礎，ZMSCollector 已經被服務化，可以透過 zms-portal 線上安裝。

ZMSCollector 的整體架構設計如下圖所示：

ZMSCollector 的整體設計比較簡單，一方面透過定時排程的方式呼叫底層訊息中介軟體提供的 API，將監控指標儲存到 influxDb，另外一方面採集 zms-sdk 採集的監控資料，zms-sdk採集的監控資料會傳送的一個固定的 topic ，ZMSCollector 訂閱指定的 topic，對訊息進行加工後儲存在 influxDb 中。

0 4

多機房解決方案

目前中通在異地容災方面還剛剛起步，目前只需要實現同城機房冷備，即一個機房的入口網路發生故障，將流量切換到另外一個備份機房即可。ZMS 訊息中介軟體運維平臺天然支援多機房的部署架構，因為在 ZMS 的視野中，一個不同的機房就相當於一個環境，可以直接在 zms-portal 中完成一個新機房的安裝部署服務。但由於發生故障後，兩個機房內部的網路有可能會斷開，故兩個機房中的後設資料應該分開儲存，即 zms-sdk 所依賴的 zookeeper 叢集不同，故需要完成 zookeeper 後設資料的同步，該工作由 ZMSBackupCluster 服務來承擔，其架構設計如下圖所示：

其基本的設計思路是 ZMSBackupCluster 訂閱待同步機房的 zookeeper，一旦後設資料有發生變化，會按照配置叢集後設資料對映關係將其同步到目標機房的 zookeeper中，這樣部署在備份機房中的應用可以無感知的接管主機房中所有的訊息傳送與訊息消費任務。

0 5

zms-portal 部分介面展示

zms-portal 提供了叢集自動化安裝部署、主題消費組審批、各種監控報表視覺化報表，接下來展示部分介面，詳細請移步 zms 開源倉庫。

0 6 

Z MS 開源資訊

中通科技正式開源內部的訊息Pass雲平臺化產品ZMS，倉庫地址：  ，包含了 ZMS 的使用說明、架構設計文件、技術交流群。開源只是完成萬里長征第一步，後續希望更多的開源愛好者加入到該專案中，共同打造一體化的智慧訊息運維平臺。

歡迎大家前往我們的倉庫，關注我們、加入我們。