中通快遞每天有數千萬的運單在各個環節運轉，每個環節都有對應的多套業務系統來支撐，業務系統之間上下游關係較為密切，從上游的客戶訂單到下游轉運、結算、分析等每個環節都離不開訊息中介軟體，它主要解決了系統之前的耦合、業務的削峰填谷、非同步通訊、資料同步和冗餘儲存等等功能需求，是現有系統架構中，不同系統之間互動的主要方式之一。
在2023年中通開始大量採用訊息中間解決一些特定的問題，隨著業務的增長，各環節有了更精細化的產品，我們訊息中介軟體的資料體量越來越大，集群規模越來越多，中介軟體也越來越多樣化，統一管理這些訊息中介軟體變得尤為重要，因此我們研發了中通資訊中介軟體平台zms，主要基於rocketmq+kafka兩套業界比較主流訊息中介軟體，提供了自動化部署、主題/消費者的申請審核、統一的sdk、管理控制台、監控告警到無感知擴容遷移等一系列運維的功能，目前zms管理了17個集群，包括7個kafka集群和10個rocketmq集群，主題1000多個，消費組3000多個，日均訊息流轉達到百億級。
zms從最初的版本演進到現在，基本圍繞我們的最初設計的功能，根據每個階段的痛點不同，解決不同的問題。整個過程，根據不同階段的不同輸出，大體可以三個維度。
經公司內部評估，zms 已經成長為一套相對成熟的訊息中介軟體雲平台化解決方案，可以正式對外開放，與社會上的同行共同打磨，故決定於2023年5月26號正式開源，將**推送到github 倉庫，開源位址資訊如下：
自動化運維部署，主要是方便運維人員可以快速通過zms平台嚮導式初始化乙個集群，其架構設計如下圖所示。
zms-portal：zms 管理後台，可同時管理多個環境的資源，包括：新增主機、服務，訊息集群狀態監控、配置訊息集群告警規則，訊息集群資源管理等。
備註：所謂的環境我們可以簡單看出開發環境、測試環境、高保真環境、生產環境。在每台機器上首先需要安裝 zms-agent (**服務)、supervisor 等基礎元件，為了方便運維，zms 提供了一鍵初始化主機的指令碼，其操作流程如下：
運維人員只需要去指定的機器上覆制上述命令即可。這樣實現的目的是 zms-portal 無需管理宿主機器的使用者名稱、密碼等敏感資訊，做到安全可控。zms 能自動感知安裝了 zms-agent 的機器並將其納入 zms-portal 的管理運維體系。
在 zms 中我們統一將 kafka、rocketmq、zk、指標收集、監控告警等統一看成是乙個服務，在不同的環境中可以選擇性的安裝，其操作如下圖所示：
基於中通業務的特點在具體專案中採用了kafka與rocketmq 兩種不同的訊息中介軟體，如果業務方在自己專案中既要使用 kafka 的訊息中介軟體，又要使用 rocketmq 的訊息中介軟體，對於訊息中介軟體的使用來說要求非常高，因為需要了解這些相似又不同的 api，分別了解其配置引數與其代表的含義，因此為業務方提供統一的api顯得尤為重要與迫切。
zms-sdk 的主要設計理念：
zms-sdk 的整體架構設計如圖所示：
主要的互動與設計要點如下：
開發人員通過在 zms-portal 申請 topic、消費組。
運維人員在 zms-portal 中對使用者的申請進行審批，並根據使用者的需求分配到適合的集群中，topic 所在集群等元資訊會寫入到 zookeeper中。
開發人員通過 zms-sdk 向所申請的 topic 傳送訊息，zms-sdk 內部會從 zk 獲取 topic 對應的元資訊並建立對應的客戶端，最終完成訊息的傳送。
對訊息中介軟體進行監控並進行視覺化展示是運維最基本的需求，rocketmq、kafka 訊息中介軟體本身提供了監控資料的採集並儲存在各自的服務端記憶體，並且是非持久化的，在記憶體中只儲存當前時間段的呼叫資訊，並隨著時間的推進，舊的資料將被刪除。當然 rocketmq、kafka 都提供了相應的api方便客戶端採集儲存在服務端記憶體中的監控資料。
zmscollector 的整體架構設計如下圖所示：
zmscollector 的整體設計比較簡單，一方面通過定時排程的方式呼叫底層訊息中介軟體提供的api，將監控指標儲存到 influxdb，另外一方面採集 zms-sdk 採集的監控資料，zms-sdk採集的監控資料會傳送的乙個固定的 topic ，zmscollector 訂閱指定的 topic，對訊息進行加工後儲存在 influxdb中。
目前中通在異地容災方面還剛剛起步，目前只需要實現同城機房冷備，即乙個機房的入口網路發生故障，需要將流量切換到另外乙個備份機房。zms 訊息中介軟體運維平台天然支援多機房的部署架構，因為在 zms 的「眼中」，乙個不同的機房就相當於乙個環境，可以直接在 zms-portal 中完成乙個新機房的安裝部署服務。但由於發生故障後，兩個機房內部的網路有可能會斷開，故兩個機房中的元資料應該分開儲存，即 zms-sdk 所依懶的 zookeeper 集群不同，故需要完成 zookeeper 元資料的同步，該工作由 zmsbackupcluster 服務來承擔，其架構設計如下圖所示：
其基本的設計思路是 zmsbackupcluster 訂閱待同步機房的 zookeeper，一旦元資料有發生變化，會按照配置集群元資料對映關係將其同步到目標機房的 zookeeper中，這樣部署在備份機房中的應用可以無感知的接管主機房中所有的訊息傳送與訊息消費任務。
zms-portal 提供了集群自動化安裝部署、主題消費組審批、各種監控報表視覺化報表，接下來展示部分介面，詳細請移步 zms 開源倉庫。
本文由部落格**一文多發等運營工具平台 openwrite 發布
微服務實踐 服務運維
監控的基本目標是掌控在生成環境中的服務執行狀況，在系統發生故障後及時報警，並能夠通過監控資訊快速定位問題。監控的另乙個目標是故障預警，在故障發生之前根據設定的規則提前感知並通知維護人員，或者自動做出運維決策。監控所涉及的指標 微服務的監控策略 對於微服務架構的系統，其監控通常由四大模組組成 資料收集...
《開源安全運維平台 OSSIM最佳實踐》內容簡介
開源安全運維平台 ossim最佳實踐 李晨光 著 清華大學出版社出版 內 容 簡 介 在傳統的異構網路環境中，運維人員往往利用各種複雜的監管工具來管理網路，由於缺乏一種整合安 全運維平台，當遇到故障時總是處於被動 救火 狀態，如何將資產管理 流量監控 漏洞管理 入侵監 測 合規管理等重要環節，通過開...
資料分析在私有雲平台運維中的應用
隨著it技術的發展，各行各業的產生的資料正在以 性的速度增長。為了從這些資料中挖掘出可用的資訊並進行持續應用，資料分析變得越來越重要。資料分析使決策變得更加準確和精細，近年來已經逐漸發展成為乙個重要的it技術方向。雲計算技術的發展使得計算資源逐漸集中化 虛擬化。怎麼高效 可靠的運營這些雲計算平台上的...