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

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

平臺建設：從架構(gòu)設計、核心能力到周邊能力建設

平臺架構(gòu)設計

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

圖1 分布式消息平臺基礎架構(gòu)

分布式消息平臺整體架構(gòu)包括五部分：

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

核心功能建設

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

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

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

周邊運維能力建設

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

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

關(guān)鍵設計：代理層引入與單元化部署架構(gòu)

圖4 代理層的引入

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

實現(xiàn)應用與消息解耦的代理層

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

代理層的引入還帶來了以下優(yōu)勢：

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

流量收斂的單元化部署架構(gòu)

隨著分布式架構(gòu)的轉(zhuǎn)型，單元化架構(gòu)成為應用系統(tǒng)進行架構(gòu)設計的重要選擇之一，為了更好的支撐應用架構(gòu)部署需求，分布式消息平臺支持了單元化部署架構(gòu)，實現(xiàn)了業(yè)務消息在AZ級別的流量收斂。

圖5 分布式消息平臺單元化部署架構(gòu)

在單元化部署架構(gòu)下，應用通過網(wǎng)關(guān)進行流量切分后通過各自AZ內(nèi)的客戶端進行消息收發(fā)，分布式消息平臺保障生產(chǎn)的消息被AZ內(nèi)的客戶端消費，實現(xiàn)業(yè)務流量的AZ級收斂，屏蔽了正常業(yè)務場景下跨AZ的消息服務調(diào)用。該架構(gòu)的實現(xiàn)主要包含以下三個部分。

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

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

圖6 行內(nèi)生態(tài)數(shù)據(jù)流轉(zhuǎn)中心

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

應用成效一：行內(nèi)生態(tài)數(shù)據(jù)的流轉(zhuǎn)中心

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

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

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

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

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

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

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

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

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

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

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