隨著分布式架構轉型的推進，應用從單體架構逐步轉向分布式、微服務化，與此同時越來越多的系統開始了異步化改造工作，這些轉變帶來了大量的進程間、系統間的消息服務需求。為了解決各系統對消息服務的分散建設帶來的技術棧不統一、運行風險高、資源浪費等問題，G行結合業界技術發展趨勢和行內MQ產品使用情況，于2020年啟動了分布式消息平臺建設項目，旨在為G行業務系統提供統一、可靠的企業級消息服務能力。

經過3年的建設工作，G行分布式消息平臺（簡稱“平臺”）已經成為應用系統分布式、微服務轉型的關鍵支撐平臺。平臺以PaaS化服務模式向全行提供消息服務，其業務支撐范圍覆蓋了內部系統、關鍵業務系統以及核心類系統。本文主要對G行的分布式消息平臺項目建設歷程、關鍵設計以及其在行內的應用成效進行總結梳理，并結合建設過程總結了筆者對該平臺類項目的建設思考。

平臺建設：從架構設計、核心能力到周邊能力建設

平臺架構設計

G行分布式消息平臺建設以高可靠和靈活擴展為原則進行平臺架構設計，以提供豐富便捷的消息服務為目標進行核心功能建設，以高效運維為目標進行周邊運維能力建設。

圖1 分布式消息平臺基礎架構

分布式消息平臺整體架構包括五部分：

• 消息引擎層：平臺以開源RocketMQ為基礎構建底層消息服務引擎，通過跨機房的主從交叉架構和兼顧性能與可靠性的刷盤策略配置保障了底層消息集群的可靠性；
• 代理層：平臺引入代理層（Proxy）實現上層應用與底層消息引擎解耦，通過代理層的無狀態設計實現了平臺對外服務入口的靈活擴展；
• SDK層：平臺開發了統一風格的SDK實現上層應用的敏捷接入，并通過SDK端與代理層的鏈接管理實現了代理故障的自動轉移；
• Portal層：平臺設計的統一管理臺，管理平面實現對消息引擎和代理集群的統一配置管理，管理臺為無狀態設計可根據實際需求靈活擴展；
• 注冊中心：基于Consul搭建的服務注冊中心，用于服務端各組件的的信息發布和SDK的接入地址。

核心功能建設

圖2 分布式消息平臺核心功能

分布式消息平臺對標當前主流消息隊列產品，結合G行應用系統的實際使用需求進行核心功能設計與開發。平臺發布了Java、Python、C三種語言SDK，支持同步發送、異步發送、OneWay發送、Push消費、Pull消費、BathPush消費等常用的消息收發接口，同時與G行自研開發框架Poin深度融合，為G行的基于不同開發語言、不同開發框架的各類應用系統的接入提供了可選方案與便捷性。

在消息類型上，平臺除了支持普通消息，還支持順序消息、延遲消息、事務消息、過期消息等消息類型，滿足了G行應用系統對消息隊列復雜場景的使用需求；在資源管理上，平臺設計了主題權限共享功能，實現了不同租戶對同一主題資源的共同使用，為業務系統間的消息流轉提供了便捷；在監控指標上，平臺設計了死信消息計數、消息積壓數量、消息積壓時長等統計指標，通過提供豐富的運行統計指標實現對生產運行狀態的實時監控，保障業務系統的穩定運行。

周邊運維能力建設

圖3 消息軌跡查詢功能示例

• 消息軌跡查詢：該功能支持貫穿生產者客戶端-生產者代理層-消息集群-消費者代理-消費者客戶端的全鏈路消息軌跡查詢，使得業務系統能夠準確定位故障原因。
• 流量摘取：平臺通過對主題/訂閱組的權限控制實現了故障場景下對業務流量進行攔截，避免對平臺消息服務或應用系統的消費服務造成流量沖擊。
• 消息回溯：平臺通過對消費位點的管理，使業務系統能夠根據需要回溯到特定的消費位點，以確保消費時機的準確性。
• 死信重發：平臺為應用系統的死信消息提供了一鍵式批量重發的能力，大大簡化了死信消息處理的流程，提升了處理效率。

關鍵設計：代理層引入與單元化部署架構

圖4 代理層的引入

縱觀G行分布式消息平臺的建設，代理層的引入降低了上層應用和底層消息服務間的耦合度，而單元化的部署架構也實現了AZ級的流量收斂，本章節對分布式消息平臺的這兩項關鍵設計進行簡單的介紹。

實現應用與消息解耦的代理層

代理層的引入主要是為了實現上層應用于底層消息引擎的解耦，從而實現底層消息服務對上層應用的透明。其中生產者代理負責將生產者客戶端發送的消息轉發給后端的消息集群，消費者代理則負責從消息集群拉取消息轉發給消費者客戶端。而隨著代理層的引入，消息平臺將更多擴展能力集成在代理層，使得底層消息集群更純粹的承載消息服務、前端SDK更簡單地承載消息收發服務。

代理層的引入還帶來了以下優勢：

• 能力擴展：代理層為平臺的擴展能力建設提供了更大的空間，通過代理層實現了對SDK租戶權限控制、流量控制、鏈接管理、負載策略自定義等原生SDK不具備的功能。
• 負載前移：將消息集群的部分功能（鑒權、流控、隊列路由等）前移至代理層，降低了底層消息集群的負載，使得消息集群更純粹的負載消息的收發和存儲。
• 容量擴展：代理層的存在屏蔽了客戶端與底層消息隊列的直接連接，從而破除了原生消息隊列對Consumer客戶端數量的限制，支持更多的客戶端接入。
• 多形態接入的可能：由于SDK只需要與代理層進行交互，不再需要依賴底層消息集群的服務接口，因此多語言SDK的開發只需要實現與代理層的叫交互即可。

流量收斂的單元化部署架構

隨著分布式架構的轉型，單元化架構成為應用系統進行架構設計的重要選擇之一，為了更好的支撐應用架構部署需求，分布式消息平臺支持了單元化部署架構，實現了業務消息在AZ級別的流量收斂。

圖5 分布式消息平臺單元化部署架構

在單元化部署架構下，應用通過網關進行流量切分后通過各自AZ內的客戶端進行消息收發，分布式消息平臺保障生產的消息被AZ內的客戶端消費，實現業務流量的AZ級收斂，屏蔽了正常業務場景下跨AZ的消息服務調用。該架構的實現主要包含以下三個部分。

• SDK與代理層貼源：通過在SDK端攜帶AZ標識，客戶端在本地選擇代理時實現優先選擇本AZ的代理節點。
• 生產者代理到RocketMQ貼源：生產者代理節點會維護所有Broker節點的配置信息和AZ信息，收到SDK請求后會解析請求中AZ標識，并在向后端RMQ轉發時優先轉發到具有相同AZ標識的Broker節點。
• RocketMQ到消費者代理貼源：消息平臺修改了原生RocketMQ的ReblanceImpl實現類，從而使得消費者代理可以緩存AZ單元信息和Broker的AZ配置；消費者代理在創建連接消息集群的RMQConsumer實例時會在實例信息中附帶AZ單元標識，實現了在隊列Reblance時將AZ1的所有隊列負載給帶有AZ1標識的RMQConsumer實例。

應用成效：提供企業級服務能力的消息平臺

圖6 行內生態數據流轉中心

分布式消息平臺建設以來，隨著消息功能的完善和周邊運維能力的建設，越來越多的應用系統依賴消息平臺實現異步通信需求，截至目前生產環境已接入業務系統35個，日消息量3900W。

應用成效一：行內生態數據的流轉中心

為規范科技治理，G行設計了服務管理系統、架構管理系統、電子審批系統、安全溯源系統等對各領域的科技工作進行細致管理，然而在這些系統之間經常存在如人員變更、需求發布、系統架構、缺陷管理等信息的交互，在以往架構中，信息的發布方需要通過接口的方式將對應的信息發布給所有需要更新該內容的下游系統，不僅存在大量的接口對接問題，同一份信息也需要發布多次。

分布式消息平臺的使用則為行內這些科技生態數據的流轉提供了便利，在分布式消息平臺的支持下，各業務系統僅需將信息發布到分布式消息平臺，由各下游系統自行從平臺訂閱即可，這種消息流轉方式一方面使得發布方僅需要關注信息到消息平臺是否發布成功，無需關注下游系統對該信息的接收過程，另一方面各業務系統也僅需要關注與消息平臺的交互接口，大幅提高了開發效率。

應用成效二：核心類應用的異步通信平臺

在金融行業，核心級別應用的接入和使用是檢驗自研產品/平臺能力的關鍵。G行分布式消息平臺自建設以來，大部分功能點和運維能力的建設更是圍繞G行新核心的建設需求展開的。目前G行分布式消息平臺已在信用卡新核心投產上線，支持卡核心異步通信需求，業務類型上包括了交易流水、動賬通知、數據同步等多類型業務場景。

圖7 消息平臺在新一代分布式核心的功能支撐

后續G行分布式消息平臺將持續應用于總行新一代分布式核心系統，作為關鍵的異步通信平臺，承擔系統內交易流水、會記分錄、報文異步登記等功能，以及核心系統與外圍系統的動賬通知等功能。

建設思考：平臺自身能力建設與對外服務水平建設

G行分布式消息平臺項目建設迄今為止已3年有余，筆者有幸從項目立項之初便參與到平臺的設計中，并參與了平臺的全過程建設，然而隨著接入系統的不斷增多、接入系統重要性的不斷提高，筆者注意到在平臺建設過程中除了自身功能性硬實力的不斷增強外，平臺對外服務水平這一軟實力也越來越多地影響著平臺的發展。

平臺自身能力可靠是平臺“能用”的基礎保障。在項目建設之初應當對平臺的建設目標有明確的定位、對平臺的核心支持能力有清晰的認知，在建設的過程中要首先保障平臺核心支持能力的可靠性，并依托核心能力不斷進行功能擴展，核心功能的不可或缺性是任何一個企業級服務平臺的建設根本。

平臺周邊功能豐富是平臺“好用”的強大助力。對于分布式消息平臺的建設，除了核心的各類型消息收發能力之外，周邊能力如監控告警配置、故障排查工具、應急處置工具以及異常場景下的服務保障機制都是平臺能夠在各應用系統穩定運行中切實發揮作用的強大工具。

平臺對外服務便捷是平臺“易用”的第一印象。如果說自身能力的可靠和周邊功能的豐富是平臺的硬實力，那么對外服務的便捷性則是平臺在推廣使用過程中的軟實力。在平臺建設和推廣使用的過程中，項目經理應當適當的把自己從平臺建設本身中剝離出來，以一個產品經理的角色、站在用戶的角度思考平臺應當提供的附加能力。對于分布式消息平臺，接入流程是否便捷、用戶界面是否友好、說明文檔是否完善、SDK調用是否簡潔、生產配置是否靈活、版本更新是否及時等都是用戶在首次接觸消息平臺時非常關心的問題。