建站
咨詢
售后
建站咨詢
新聞中心
隨著分布式架構(gòu)轉(zhuǎn)型的推進(jìn)，應(yīng)用從單體架構(gòu)逐步轉(zhuǎn)向分布式、微服務(wù)化，與此同時(shí)越來(lái)越多的系統(tǒng)開始了異步化改造工作，這些轉(zhuǎn)變帶來(lái)了大量的進(jìn)程間、系統(tǒng)間的消息服務(wù)需求。為了解決各系統(tǒng)對(duì)消息服務(wù)的分散建設(shè)帶來(lái)的技術(shù)棧不統(tǒng)一、運(yùn)行風(fēng)險(xiǎn)高、資源浪費(fèi)等問(wèn)題，G行結(jié)合業(yè)界技術(shù)發(fā)展趨勢(shì)和行內(nèi)MQ產(chǎn)品使用情況，于2020年啟動(dòng)了分布式消息平臺(tái)建設(shè)項(xiàng)目，旨在為G行業(yè)務(wù)系統(tǒng)提供統(tǒng)一、可靠的企業(yè)級(jí)消息服務(wù)能力。
經(jīng)過(guò)3年的建設(shè)工作，G行分布式消息平臺(tái)（簡(jiǎn)稱“平臺(tái)”）已經(jīng)成為應(yīng)用系統(tǒng)分布式、微服務(wù)轉(zhuǎn)型的關(guān)鍵支撐平臺(tái)。平臺(tái)以PaaS化服務(wù)模式向全行提供消息服務(wù)，其業(yè)務(wù)支撐范圍覆蓋了內(nèi)部系統(tǒng)、關(guān)鍵業(yè)務(wù)系統(tǒng)以及核心類系統(tǒng)。本文主要對(duì)G行的分布式消息平臺(tái)項(xiàng)目建設(shè)歷程、關(guān)鍵設(shè)計(jì)以及其在行內(nèi)的應(yīng)用成效進(jìn)行總結(jié)梳理，并結(jié)合建設(shè)過(guò)程總結(jié)了筆者對(duì)該平臺(tái)類項(xiàng)目的建設(shè)思考。
平臺(tái)建設(shè)：從架構(gòu)設(shè)計(jì)、核心能力到周邊能力建設(shè)
平臺(tái)架構(gòu)設(shè)計(jì)
G行分布式消息平臺(tái)建設(shè)以高可靠和靈活擴(kuò)展為原則進(jìn)行平臺(tái)架構(gòu)設(shè)計(jì)，以提供豐富便捷的消息服務(wù)為目標(biāo)進(jìn)行核心功能建設(shè)，以高效運(yùn)維為目標(biāo)進(jìn)行周邊運(yùn)維能力建設(shè)。
圖1 分布式消息平臺(tái)基礎(chǔ)架構(gòu)
分布式消息平臺(tái)整體架構(gòu)包括五部分：
- 消息引擎層：平臺(tái)以開源RocketMQ為基礎(chǔ)構(gòu)建底層消息服務(wù)引擎，通過(guò)跨機(jī)房的主從交叉架構(gòu)和兼顧性能與可靠性的刷盤策略配置保障了底層消息集群的可靠性；
- 代理層：平臺(tái)引入代理層（Proxy）實(shí)現(xiàn)上層應(yīng)用與底層消息引擎解耦，通過(guò)代理層的無(wú)狀態(tài)設(shè)計(jì)實(shí)現(xiàn)了平臺(tái)對(duì)外服務(wù)入口的靈活擴(kuò)展；
- SDK層：平臺(tái)開發(fā)了統(tǒng)一風(fēng)格的SDK實(shí)現(xiàn)上層應(yīng)用的敏捷接入，并通過(guò)SDK端與代理層的鏈接管理實(shí)現(xiàn)了代理故障的自動(dòng)轉(zhuǎn)移；
- Portal層：平臺(tái)設(shè)計(jì)的統(tǒng)一管理臺(tái)，管理平面實(shí)現(xiàn)對(duì)消息引擎和代理集群的統(tǒng)一配置管理，管理臺(tái)為無(wú)狀態(tài)設(shè)計(jì)可根據(jù)實(shí)際需求靈活擴(kuò)展；
- 注冊(cè)中心：基于Consul搭建的服務(wù)注冊(cè)中心，用于服務(wù)端各組件的的信息發(fā)布和SDK的接入地址。
核心功能建設(shè)
圖2 分布式消息平臺(tái)核心功能
分布式消息平臺(tái)對(duì)標(biāo)當(dāng)前主流消息隊(duì)列產(chǎn)品，結(jié)合G行應(yīng)用系統(tǒng)的實(shí)際使用需求進(jìn)行核心功能設(shè)計(jì)與開發(fā)。平臺(tái)發(fā)布了Java、Python、C三種語(yǔ)言SDK，支持同步發(fā)送、異步發(fā)送、OneWay發(fā)送、Push消費(fèi)、Pull消費(fèi)、BathPush消費(fèi)等常用的消息收發(fā)接口，同時(shí)與G行自研開發(fā)框架Poin深度融合，為G行的基于不同開發(fā)語(yǔ)言、不同開發(fā)框架的各類應(yīng)用系統(tǒng)的接入提供了可選方案與便捷性。
在消息類型上，平臺(tái)除了支持普通消息，還支持順序消息、延遲消息、事務(wù)消息、過(guò)期消息等消息類型，滿足了G行應(yīng)用系統(tǒng)對(duì)消息隊(duì)列復(fù)雜場(chǎng)景的使用需求；在資源管理上，平臺(tái)設(shè)計(jì)了主題權(quán)限共享功能，實(shí)現(xiàn)了不同租戶對(duì)同一主題資源的共同使用，為業(yè)務(wù)系統(tǒng)間的消息流轉(zhuǎn)提供了便捷；在監(jiān)控指標(biāo)上，平臺(tái)設(shè)計(jì)了死信消息計(jì)數(shù)、消息積壓數(shù)量、消息積壓時(shí)長(zhǎng)等統(tǒng)計(jì)指標(biāo)，通過(guò)提供豐富的運(yùn)行統(tǒng)計(jì)指標(biāo)實(shí)現(xiàn)對(duì)生產(chǎn)運(yùn)行狀態(tài)的實(shí)時(shí)監(jiān)控，保障業(yè)務(wù)系統(tǒng)的穩(wěn)定運(yùn)行。
周邊運(yùn)維能力建設(shè)
圖3 消息軌跡查詢功能示例
- 消息軌跡查詢：該功能支持貫穿生產(chǎn)者客戶端-生產(chǎn)者代理層-消息集群-消費(fèi)者代理-消費(fèi)者客戶端的全鏈路消息軌跡查詢，使得業(yè)務(wù)系統(tǒng)能夠準(zhǔn)確定位故障原因。
- 流量摘?。浩脚_(tái)通過(guò)對(duì)主題/訂閱組的權(quán)限控制實(shí)現(xiàn)了故障場(chǎng)景下對(duì)業(yè)務(wù)流量進(jìn)行攔截，避免對(duì)平臺(tái)消息服務(wù)或應(yīng)用系統(tǒng)的消費(fèi)服務(wù)造成流量沖擊。
- 消息回溯：平臺(tái)通過(guò)對(duì)消費(fèi)位點(diǎn)的管理，使業(yè)務(wù)系統(tǒng)能夠根據(jù)需要回溯到特定的消費(fèi)位點(diǎn)，以確保消費(fèi)時(shí)機(jī)的準(zhǔn)確性。
- 死信重發(fā)：平臺(tái)為應(yīng)用系統(tǒng)的死信消息提供了一鍵式批量重發(fā)的能力，大大簡(jiǎn)化了死信消息處理的流程，提升了處理效率。
關(guān)鍵設(shè)計(jì)：代理層引入與單元化部署架構(gòu)
圖4 代理層的引入
縱觀G行分布式消息平臺(tái)的建設(shè)，代理層的引入降低了上層應(yīng)用和底層消息服務(wù)間的耦合度，而單元化的部署架構(gòu)也實(shí)現(xiàn)了AZ級(jí)的流量收斂，本章節(jié)對(duì)分布式消息平臺(tái)的這兩項(xiàng)關(guān)鍵設(shè)計(jì)進(jìn)行簡(jiǎn)單的介紹。
實(shí)現(xiàn)應(yīng)用與消息解耦的代理層
代理層的引入主要是為了實(shí)現(xiàn)上層應(yīng)用于底層消息引擎的解耦，從而實(shí)現(xiàn)底層消息服務(wù)對(duì)上層應(yīng)用的透明。其中生產(chǎn)者代理負(fù)責(zé)將生產(chǎn)者客戶端發(fā)送的消息轉(zhuǎn)發(fā)給后端的消息集群，消費(fèi)者代理則負(fù)責(zé)從消息集群拉取消息轉(zhuǎn)發(fā)給消費(fèi)者客戶端。而隨著代理層的引入，消息平臺(tái)將更多擴(kuò)展能力集成在代理層，使得底層消息集群更純粹的承載消息服務(wù)、前端SDK更簡(jiǎn)單地承載消息收發(fā)服務(wù)。
代理層的引入還帶來(lái)了以下優(yōu)勢(shì)：
- 能力擴(kuò)展：代理層為平臺(tái)的擴(kuò)展能力建設(shè)提供了更大的空間，通過(guò)代理層實(shí)現(xiàn)了對(duì)SDK租戶權(quán)限控制、流量控制、鏈接管理、負(fù)載策略自定義等原生SDK不具備的功能。
- 負(fù)載前移：將消息集群的部分功能（鑒權(quán)、流控、隊(duì)列路由等）前移至代理層，降低了底層消息集群的負(fù)載，使得消息集群更純粹的負(fù)載消息的收發(fā)和存儲(chǔ)。
- 容量擴(kuò)展：代理層的存在屏蔽了客戶端與底層消息隊(duì)列的直接連接，從而破除了原生消息隊(duì)列對(duì)Consumer客戶端數(shù)量的限制，支持更多的客戶端接入。
- 多形態(tài)接入的可能：由于SDK只需要與代理層進(jìn)行交互，不再需要依賴底層消息集群的服務(wù)接口，因此多語(yǔ)言SDK的開發(fā)只需要實(shí)現(xiàn)與代理層的叫交互即可。
流量收斂的單元化部署架構(gòu)
隨著分布式架構(gòu)的轉(zhuǎn)型，單元化架構(gòu)成為應(yīng)用系統(tǒng)進(jìn)行架構(gòu)設(shè)計(jì)的重要選擇之一，為了更好的支撐應(yīng)用架構(gòu)部署需求，分布式消息平臺(tái)支持了單元化部署架構(gòu)，實(shí)現(xiàn)了業(yè)務(wù)消息在AZ級(jí)別的流量收斂。
圖5 分布式消息平臺(tái)單元化部署架構(gòu)
在單元化部署架構(gòu)下，應(yīng)用通過(guò)網(wǎng)關(guān)進(jìn)行流量切分后通過(guò)各自AZ內(nèi)的客戶端進(jìn)行消息收發(fā)，分布式消息平臺(tái)保障生產(chǎn)的消息被AZ內(nèi)的客戶端消費(fèi)，實(shí)現(xiàn)業(yè)務(wù)流量的AZ級(jí)收斂，屏蔽了正常業(yè)務(wù)場(chǎng)景下跨AZ的消息服務(wù)調(diào)用。該架構(gòu)的實(shí)現(xiàn)主要包含以下三個(gè)部分。
- SDK與代理層貼源：通過(guò)在SDK端攜帶AZ標(biāo)識(shí)，客戶端在本地選擇代理時(shí)實(shí)現(xiàn)優(yōu)先選擇本AZ的代理節(jié)點(diǎn)。
- 生產(chǎn)者代理到RocketMQ貼源：生產(chǎn)者代理節(jié)點(diǎn)會(huì)維護(hù)所有Broker節(jié)點(diǎn)的配置信息和AZ信息，收到SDK請(qǐng)求后會(huì)解析請(qǐng)求中AZ標(biāo)識(shí)，并在向后端RMQ轉(zhuǎn)發(fā)時(shí)優(yōu)先轉(zhuǎn)發(fā)到具有相同AZ標(biāo)識(shí)的Broker節(jié)點(diǎn)。
- RocketMQ到消費(fèi)者代理貼源：消息平臺(tái)修改了原生RocketMQ的ReblanceImpl實(shí)現(xiàn)類，從而使得消費(fèi)者代理可以緩存AZ單元信息和Broker的AZ配置；消費(fèi)者代理在創(chuàng)建連接消息集群的RMQConsumer實(shí)例時(shí)會(huì)在實(shí)例信息中附帶AZ單元標(biāo)識(shí)，實(shí)現(xiàn)了在隊(duì)列Reblance時(shí)將AZ1的所有隊(duì)列負(fù)載給帶有AZ1標(biāo)識(shí)的RMQConsumer實(shí)例。
應(yīng)用成效：提供企業(yè)級(jí)服務(wù)能力的消息平臺(tái)
圖6 行內(nèi)生態(tài)數(shù)據(jù)流轉(zhuǎn)中心
分布式消息平臺(tái)建設(shè)以來(lái)，隨著消息功能的完善和周邊運(yùn)維能力的建設(shè)，越來(lái)越多的應(yīng)用系統(tǒng)依賴消息平臺(tái)實(shí)現(xiàn)異步通信需求，截至目前生產(chǎn)環(huán)境已接入業(yè)務(wù)系統(tǒng)35個(gè)，日消息量3900W。
應(yīng)用成效一：行內(nèi)生態(tài)數(shù)據(jù)的流轉(zhuǎn)中心
為規(guī)范科技治理，G行設(shè)計(jì)了服務(wù)管理系統(tǒng)、架構(gòu)管理系統(tǒng)、電子審批系統(tǒng)、安全溯源系統(tǒng)等對(duì)各領(lǐng)域的科技工作進(jìn)行細(xì)致管理，然而在這些系統(tǒng)之間經(jīng)常存在如人員變更、需求發(fā)布、系統(tǒng)架構(gòu)、缺陷管理等信息的交互，在以往架構(gòu)中，信息的發(fā)布方需要通過(guò)接口的方式將對(duì)應(yīng)的信息發(fā)布給所有需要更新該內(nèi)容的下游系統(tǒng)，不僅存在大量的接口對(duì)接問(wèn)題，同一份信息也需要發(fā)布多次。
分布式消息平臺(tái)的使用則為行內(nèi)這些科技生態(tài)數(shù)據(jù)的流轉(zhuǎn)提供了便利，在分布式消息平臺(tái)的支持下，各業(yè)務(wù)系統(tǒng)僅需將信息發(fā)布到分布式消息平臺(tái)，由各下游系統(tǒng)自行從平臺(tái)訂閱即可，這種消息流轉(zhuǎn)方式一方面使得發(fā)布方僅需要關(guān)注信息到消息平臺(tái)是否發(fā)布成功，無(wú)需關(guān)注下游系統(tǒng)對(duì)該信息的接收過(guò)程，另一方面各業(yè)務(wù)系統(tǒng)也僅需要關(guān)注與消息平臺(tái)的交互接口，大幅提高了開發(fā)效率。
應(yīng)用成效二：核心類應(yīng)用的異步通信平臺(tái)
在金融行業(yè)，核心級(jí)別應(yīng)用的接入和使用是檢驗(yàn)自研產(chǎn)品/平臺(tái)能力的關(guān)鍵。G行分布式消息平臺(tái)自建設(shè)以來(lái)，大部分功能點(diǎn)和運(yùn)維能力的建設(shè)更是圍繞G行新核心的建設(shè)需求展開的。目前G行分布式消息平臺(tái)已在信用卡新核心投產(chǎn)上線，支持卡核心異步通信需求，業(yè)務(wù)類型上包括了交易流水、動(dòng)賬通知、數(shù)據(jù)同步等多類型業(yè)務(wù)場(chǎng)景。
圖7 消息平臺(tái)在新一代分布式核心的功能支撐
后續(xù)G行分布式消息平臺(tái)將持續(xù)應(yīng)用于總行新一代分布式核心系統(tǒng)，作為關(guān)鍵的異步通信平臺(tái)，承擔(dān)系統(tǒng)內(nèi)交易流水、會(huì)記分錄、報(bào)文異步登記等功能，以及核心系統(tǒng)與外圍系統(tǒng)的動(dòng)賬通知等功能。
建設(shè)思考：平臺(tái)自身能力建設(shè)與對(duì)外服務(wù)水平建設(shè)
G行分布式消息平臺(tái)項(xiàng)目建設(shè)迄今為止已3年有余，筆者有幸從項(xiàng)目立項(xiàng)之初便參與到平臺(tái)的設(shè)計(jì)中，并參與了平臺(tái)的全過(guò)程建設(shè)，然而隨著接入系統(tǒng)的不斷增多、接入系統(tǒng)重要性的不斷提高，筆者注意到在平臺(tái)建設(shè)過(guò)程中除了自身功能性硬實(shí)力的不斷增強(qiáng)外，平臺(tái)對(duì)外服務(wù)水平這一軟實(shí)力也越來(lái)越多地影響著平臺(tái)的發(fā)展。
平臺(tái)自身能力可靠是平臺(tái)“能用”的基礎(chǔ)保障。在項(xiàng)目建設(shè)之初應(yīng)當(dāng)對(duì)平臺(tái)的建設(shè)目標(biāo)有明確的定位、對(duì)平臺(tái)的核心支持能力有清晰的認(rèn)知，在建設(shè)的過(guò)程中要首先保障平臺(tái)核心支持能力的可靠性，并依托核心能力不斷進(jìn)行功能擴(kuò)展，核心功能的不可或缺性是任何一個(gè)企業(yè)級(jí)服務(wù)平臺(tái)的建設(shè)根本。
平臺(tái)周邊功能豐富是平臺(tái)“好用”的強(qiáng)大助力。對(duì)于分布式消息平臺(tái)的建設(shè)，除了核心的各類型消息收發(fā)能力之外，周邊能力如監(jiān)控告警配置、故障排查工具、應(yīng)急處置工具以及異常場(chǎng)景下的服務(wù)保障機(jī)制都是平臺(tái)能夠在各應(yīng)用系統(tǒng)穩(wěn)定運(yùn)行中切實(shí)發(fā)揮作用的強(qiáng)大工具。
平臺(tái)對(duì)外服務(wù)便捷是平臺(tái)“易用”的第一印象。如果說(shuō)自身能力的可靠和周邊功能的豐富是平臺(tái)的硬實(shí)力，那么對(duì)外服務(wù)的便捷性則是平臺(tái)在推廣使用過(guò)程中的軟實(shí)力。在平臺(tái)建設(shè)和推廣使用的過(guò)程中，項(xiàng)目經(jīng)理應(yīng)當(dāng)適當(dāng)?shù)陌炎约簭钠脚_(tái)建設(shè)本身中剝離出來(lái)，以一個(gè)產(chǎn)品經(jīng)理的角色、站在用戶的角度思考平臺(tái)應(yīng)當(dāng)提供的附加能力。對(duì)于分布式消息平臺(tái)，接入流程是否便捷、用戶界面是否友好、說(shuō)明文檔是否完善、SDK調(diào)用是否簡(jiǎn)潔、生產(chǎn)配置是否靈活、版本更新是否及時(shí)等都是用戶在首次接觸消息平臺(tái)時(shí)非常關(guān)心的問(wèn)題。
新聞名稱：G行分布式消息平臺(tái)建設(shè)與思考
網(wǎng)頁(yè)路徑：http://fisionsoft.com.cn/article/dpiecoc.html
