消息中心作為電商業(yè)務(wù)場景必不可少的核心組件，自嚴選上線以來，就開始了建設(shè)和演進迭代之路。截止目前，消息中心已接入200+服務(wù)，1500+消息，覆蓋基礎(chǔ)技術(shù)、供應(yīng)鏈、分銷客售、主站、交易訂單、數(shù)據(jù)算法等嚴選所有業(yè)務(wù)場景。本文對于消息中心的技術(shù)架構(gòu)演進不做詳細敘述，重點介紹面向業(yè)務(wù)使用方的消息中心管理平臺建設(shè)實踐經(jīng)驗。

1. 引言??

消息中心作為電商業(yè)務(wù)場景必不可少的核心組件，自嚴選上線以來，就開始了建設(shè)和演進迭代之路。截止目前，消息中心已接入200+服務(wù)，1500+消息，覆蓋基礎(chǔ)技術(shù)、供應(yīng)鏈、分銷客售、主站、交易訂單、數(shù)據(jù)算法等嚴選所有業(yè)務(wù)場景。

本文對于消息中心的技術(shù)架構(gòu)演進不做詳細敘述，重點介紹面向業(yè)務(wù)使用方的消息中心管理平臺建設(shè)實踐經(jīng)驗。

2. 平臺建設(shè)背景?

2.1 痛點問題

通過廣泛溝通收集需求，在消息中心研發(fā)運維過程中，經(jīng)常會碰到如下痛點問題：

• 影響研發(fā)效率：消息中心作為異步解耦的中間節(jié)點，串聯(lián)上下游服務(wù)，系統(tǒng)鏈路較長，由于缺失完整的消息鏈路查詢功能，當業(yè)務(wù)邏輯出現(xiàn)問題時，無論上下游服務(wù)都需要找消息中心開發(fā)排查問題，極大影響業(yè)務(wù)側(cè)的研發(fā)效率，同時提高了消息中心運維成本。
• 無法感知異常：消息中心異步解耦了上下游服務(wù)，導致在一些業(yè)務(wù)場景生產(chǎn)方無法感知消費方的處理異常，被動靠業(yè)務(wù)反饋才能發(fā)現(xiàn)問題。
• 運維成本高：由于生產(chǎn)者或者消費者監(jiān)控不足，需要依賴消息中心開發(fā)通知生產(chǎn)方發(fā)送消息失敗，或者通知消費方消費消息失敗或者消息積壓等，很大程度上加大了消息中心的運維成本。

2.2 價值

定位和處理上面這些問題，通常會花費較長時間，極大影響研發(fā)效率，更嚴重的還會影響線上業(yè)務(wù)。因此，亟需一個面向業(yè)務(wù)開發(fā)的消息中心管理平臺，提高研發(fā)效能：

• 提供完整的消息鏈路查詢能力，方便業(yè)務(wù)接入方可自助式的快速定位排查問題；
• 提供消息鏈路數(shù)據(jù)的準實時統(tǒng)計分析能力，提升系統(tǒng)可觀測性，方便業(yè)務(wù)方配置監(jiān)控報警（消息延遲、消費異常）；
• 提供消息鏈路數(shù)據(jù)的離線統(tǒng)計分析能力，方便業(yè)務(wù)使用方和消息中心自身進行風險評估，提升系統(tǒng)穩(wěn)定性；
• 提供初步的自動化運維能力，提升應(yīng)急止損處理響應(yīng)效率，降低人工運維成本。

2.3 目標

面向業(yè)務(wù)使用方：為了提升各位業(yè)務(wù)開發(fā)同學對各自負責系統(tǒng)的消息收發(fā)治理和問題排查定位的效率，建設(shè)嚴選消息中心管理平臺，通過整合串聯(lián)不同系統(tǒng)間的消息鏈路，統(tǒng)一并標準化定義消息鏈路的關(guān)鍵節(jié)點，基于元數(shù)據(jù)進行統(tǒng)計分析從而配置報警監(jiān)控，最終達到整個嚴選技術(shù)體系降本增效的目的。同時，通過自動化工單閉環(huán)消息發(fā)布、下線、消息訂閱、取消訂閱完整生命周期管理，入駐嚴選DevOps管理平臺天樞，將消息中心融入整個DevOps研發(fā)體系。

3. 平臺建設(shè)方案?

3.1 整體思路

核心思路就是通過提升消息中心的可觀測性，通過消息中心管理平臺給用戶提供可視化配置管理能力。一個好的可觀測系統(tǒng)，最后要做到的形態(tài)就是實現(xiàn)Metrics、Tracing、Logging的融合：

• Tracing：提供了一個請求從接收到處理完畢整個生命周期的跟蹤路徑，通常請求都是在分布式的系統(tǒng)中處理，所以也叫做分布式鏈路追蹤，消息中心場景就是完整的消息鏈路。
• Metrics：提供量化的系統(tǒng)內(nèi)/外部各個維度的指標，消息中心場景就是發(fā)送耗時、消費耗時、端到端的延遲、消息積壓等。
• Logging：提供系統(tǒng)/進程最精細化的信息，消息中心場景就是消息內(nèi)容、消息發(fā)送者元數(shù)據(jù)信息、消息消費者元數(shù)據(jù)信息等。這三者在可觀測性上缺一不可，基于Metrics的告警發(fā)現(xiàn)異常，通過Tracing定位問題模塊，根據(jù)模塊具體的Logging定位到錯誤根源，最后再基于這次問題排查經(jīng)驗調(diào)整Metrics告警閾值，達到預(yù)警效果。

在嚴選消息中心場景，在盡量復(fù)用現(xiàn)有組件能力的原則下，獲取這三者數(shù)據(jù)的具體執(zhí)行路徑如下：

• Tracing：復(fù)用嚴選分布式鏈路追蹤系統(tǒng)(APM)能力，消息中心接入caesar agent，將traceId和messageId等核心數(shù)據(jù)打印到業(yè)務(wù)日志。(消息中心的流量染色，壓測標識透傳也基于此思路)
• Metrics：復(fù)用嚴選實時計算平臺能力，自定義flink任務(wù)，將日志平臺采集的業(yè)務(wù)日志數(shù)據(jù)進行聚合計算，將實時指標數(shù)據(jù)存入網(wǎng)易時序數(shù)據(jù)庫(Ntsdb)。同時也可按需在嚴選數(shù)倉配置T+1離線任務(wù)，進行相關(guān)指標數(shù)據(jù)計算采集。
• Logging：復(fù)用?嚴選日志平臺能力??，打印業(yè)務(wù)日志，進行采集、存儲、查詢。

3.2 概念定義

3.2.1 消息鏈路節(jié)點定義?

消息中心以HTTP Proxy的模式對外提供服務(wù)，業(yè)務(wù)方不感知底層消息中間件，提供HTTP異步方式的發(fā)布訂閱功能。由如下三部分構(gòu)成了消息中心：

• 生產(chǎn)者代理
• 消息中間件
• 消費者代理

完整的消息鏈路如下圖所示：

節(jié)點定義如下：

3.2.2 用戶視角定義

不同的用戶視角關(guān)注的消息鏈路是不同的，用戶只需聚焦于自己的對應(yīng)的消息鏈路即可：

• 生產(chǎn)者：生產(chǎn)者服務(wù) -> 生產(chǎn)者代理 -> 消息中間件
• 消費者：消費者代理 -> 消費者服務(wù)
• 全鏈路：生產(chǎn)者服務(wù) -> 生產(chǎn)者代理 -> 消息中間件 -> 消費者代理 -> 消費者服務(wù)

3.3 數(shù)據(jù)流分層架構(gòu)?

3.3.1 數(shù)據(jù)源

數(shù)據(jù)源主要是基于如下三部分日志，可串聯(lián)整個消息鏈路：

• 應(yīng)用業(yè)務(wù)日志：消息中心三個集群打印messageId、traceId以及對應(yīng)鏈路節(jié)點的關(guān)鍵元數(shù)據(jù)信息。
• 應(yīng)用訪問日志：云外(/home/logs/consul-nginx/access.log)，云內(nèi)(/home/logs/yanxuan-sidecar-envoy/access.log)，可獲取推送到消息訂閱方的上游節(jié)點信息，若是網(wǎng)關(guān)節(jié)點需再結(jié)合網(wǎng)關(guān)日志（僅采集消息中心服務(wù)實例上的日志）。
• 網(wǎng)關(guān)日志：根據(jù)網(wǎng)關(guān)日志獲取到真正接收請求方的上游節(jié)點信息。?

3.3.2 數(shù)據(jù)采集層

復(fù)用日志平臺現(xiàn)有功能，在日志平臺配置業(yè)務(wù)日志采集任務(wù)，此處不詳述。

3.3.3 數(shù)據(jù)分析層

按需在數(shù)倉平臺配置T+1的離線分析任務(wù)，在嚴選實時計算平臺配置運行自定義flink任務(wù)，聚合時間窗口可根據(jù)實際情況配置，主要指標如下：

• 生產(chǎn)者（topic+發(fā)送方）：

• 1d/1h/5min/1min 發(fā)送量
• 1d/1h/5min/1min 發(fā)送平均耗時
• 1d/1h/5min/1min 發(fā)送慢請求率/數(shù)
• 1d/1h/5min/1min 發(fā)送失敗率/數(shù)

• 消費者（topic+訂閱方）：

• 1d/1h/5min/1min 消費量

• 1d/1h/5min/1min 消費平均耗時

• 1d/1h/5min/1min 消費慢請求率/數(shù)

• 1d/1h/5min/1min 消費失敗率/數(shù)

• 1d/1h/5min/1min 消費平均延遲

3.3.4 數(shù)據(jù)存儲層

• 日志平臺ES集群：用于消息鏈路實時查詢，日志平臺提供openapi接口給消息中心管理平臺進行鏈路查詢。
• HIVE：消息中心打印的業(yè)務(wù)日志通過日志平臺的日志采集傳輸鏈路會存到數(shù)倉的hive表。
• NTSDB：經(jīng)過流式計算生成的指標數(shù)據(jù)會存入網(wǎng)易時序數(shù)據(jù)庫，供消息中心管理平臺進行查詢生成統(tǒng)計圖表。
• 服務(wù)端DB：消息中心管理平臺一些基礎(chǔ)信息的維護與展示，比如監(jiān)控報警配置、自助運維審計日志等。?

3.3.5 數(shù)據(jù)展示層

• 消息鏈路查詢：支持traceId和messageId兩個維度的查詢。
• 數(shù)據(jù)統(tǒng)計分析：根據(jù)統(tǒng)計指標展示不同維度的圖表。
• 自助化運維：可從生產(chǎn)者和消費者兩個視角進行進行消息補推，并提供審計功能：

• 生產(chǎn)者：指定messageId、topic的生產(chǎn)狀態(tài)等篩選條件將消息重新寫入消息中間件（即推送所有訂閱方）。
• 消費者：指定messageId、topic的消費狀態(tài)等篩選條件將消息重新推到指定訂閱方。

• 元數(shù)據(jù)管理：主要是topic的生產(chǎn)訂閱關(guān)系的查詢功能及拓撲展示、重試策略配置、報警配置等。

4. 平臺功能?

4.1 消息鏈路查詢

?支持如下兩個維度的消息鏈路查詢：

• 消息id(messageId)搜索：對應(yīng)一條完整的消息鏈路（消息發(fā)送方確保消息id的唯一性）。
• 分布式鏈路(traceId)搜索：可能對應(yīng)多條消息鏈路（消息發(fā)送方接入APM）。

提供拓撲和日志兩種視圖模式，供用戶進行切換展示。?

• 拓撲視圖：

• 日志視圖：

拓撲視圖下可點擊查看消息內(nèi)容、消費失敗原因、發(fā)送耗時、消費耗時、端到端延遲。默認展示消息的所有消費者，用戶可點擊篩選只展示自己感興趣的消費者消費鏈路。

• 查看消息內(nèi)容：

• 查看失敗原因：

4.2 數(shù)據(jù)統(tǒng)計分析

4.2.1 業(yè)務(wù)方使用視角

可篩選查看topic 【指定時間范圍內(nèi) + 指定時間間隔】的聚合指標數(shù)據(jù)，相關(guān)統(tǒng)計圖具體如下：

• 生產(chǎn)消費數(shù)量統(tǒng)計圖：排查消息消費是否存在堆積。?

• 生產(chǎn)消費失敗統(tǒng)計圖：排查消息生產(chǎn)/消費是否存在異常。?

• 生產(chǎn)消費平均耗時統(tǒng)計圖：排查生產(chǎn)/消費的性能（【平均】是指時間窗口的聚合指標數(shù)據(jù)）。?

• 消費平均延遲統(tǒng)計圖：排查端到端的延遲（【平均】是指時間窗口的聚合指標數(shù)據(jù)）。?

• 消息數(shù)據(jù)平均大小統(tǒng)計圖：查看消息網(wǎng)絡(luò)傳輸包大?。ā酒骄渴侵笗r間窗口的聚合指標數(shù)據(jù)）。?

4.2.2 系統(tǒng)管理員視角

系統(tǒng)管理員不關(guān)注具體某個topic，而是關(guān)注消息中心集群的整體運行情況，相關(guān)統(tǒng)計圖表具體如下：

• 消費訂閱系統(tǒng)級延遲圖：通過85線、95線、99線查看消息系統(tǒng)整體端到端的延遲情況。?

• 消息消費延遲最大值Top排行表：用于通知消息消費者對于消息時效性的邏輯處理優(yōu)化。?

• 消息消費耗時最大值Top排行表：用于通知消息消費方進行消費邏輯的性能優(yōu)化。?

• 發(fā)送消費統(tǒng)計圖：用于統(tǒng)計消息量較大的消息。?

4.3 元數(shù)據(jù)管理

支持從消息主題、發(fā)布方、訂閱方三個維度分頁查詢消息元數(shù)據(jù)信息，主要包括消息主題、發(fā)布方CMDB服務(wù)編碼、訂閱方CMDB服務(wù)編碼、訂閱url等相關(guān)配置，具體如下：

可點擊消息詳情，查看消息元數(shù)據(jù)、消息格式、消息示例信息，具體如下：

可點擊消息拓撲查看圖形化的發(fā)布訂閱關(guān)系，具體如下：

可查看消息失敗重試策略，工單申請調(diào)整重試策略，具體如下：

可查看報警配置，消息訂閱方所屬服務(wù)技術(shù)負責人可調(diào)整告警配置，主要分為兩種類型的告警：

• 消息失敗告警：達到失敗重試次數(shù)的消息認為消費失敗。
• 消息延遲告警：端到端的延遲告警，對于消息時效性敏感的消息可根據(jù)實際情況調(diào)整。

報警的指標數(shù)據(jù)是通過flink實時任務(wù)聚合采集存入Ntsdb，告警通知對接嚴選告警平臺，告警接收人員即為線上服務(wù)所對應(yīng)的線上監(jiān)控人員角色。

4.4 自助運維

當消息中心上下游系統(tǒng)出現(xiàn)異常時，只要確保消息已成功投遞到消息中心，消息中心可提供自助補推功能，來輔助業(yè)務(wù)快速恢復(fù)。支持根據(jù)消息id或者消息狀態(tài)篩選查詢指定時間范圍內(nèi)的消息，來決定是給消息的所有訂閱者推送還是給某個訂閱者推送。

消息推送對操作人進行嚴格的數(shù)據(jù)權(quán)限隔離：

• 如果要給消息的所有訂閱者推送，則必須是所屬消息服務(wù)的技術(shù)負責人，需要與涉及的所有訂閱方技術(shù)負責人充分溝通，再進行推送。
• 如果要給消息的某個訂閱者推送，則必須是該訂閱者服務(wù)的技術(shù)負責人，操作人對此次操作負責。

消息補推屬于高危操作，所有操作都會進行記錄進行事后審計跟蹤，并可查看每條推送記錄的具體詳情：

4.5 工單自動化審批

通過自動化工單閉環(huán)消息發(fā)布、下線、消息訂閱、取消訂閱完整生命周期管理，入駐嚴選DevOps管理平臺天樞，有機的將消息中心融入整個DevOps研發(fā)體系。

同時將消息工單作為一個變更事件，基于天樞平臺自動將測試環(huán)境的工單同步到線上。同時作為需求發(fā)布上線的風險變更管控卡點項，有效規(guī)避漏申請消息發(fā)布/訂閱的情況而導致的業(yè)務(wù)異常。

5. 總結(jié)與展望?

5.1 總結(jié)

消息中心管理平臺自上線以來，受到了不少業(yè)務(wù)方的好評，也廣泛收集建議進行了一些功能迭代優(yōu)化，初步達成了預(yù)期目標：

• 業(yè)務(wù)賦能：消息中心已接入200+服務(wù)，1500+消息，覆蓋基礎(chǔ)技術(shù)、供應(yīng)鏈、分銷客售、主站、交易訂單、數(shù)據(jù)算法等嚴選所有業(yè)務(wù)場景。
• 運維成本大幅度降低：技術(shù)咨詢數(shù)量從上線前周均50+，降低到目前周均小于10次。
• 研發(fā)效率逐步提升：業(yè)務(wù)方高效便捷的自行排查問題和自助補推消息，消息工單完結(jié)率提升到超過90%。

5.2 展望

消息中心管理平臺下一步的重點方向是數(shù)字化建設(shè)，借鑒當前比較流行的FinOps執(zhí)行路徑：成本展示 -> 成本分析 -> 成本優(yōu)化：

• 展示層面：當前消息中心管理平臺雖然有不少統(tǒng)計圖表，僅僅是基于topic視角或者系統(tǒng)管理員的全局視角，也收到不少業(yè)務(wù)方的反饋意見，如何從業(yè)務(wù)方視角更好地將數(shù)據(jù)聚合展示推送觸達用戶，是接下來要考慮的問題。
• 分析層面：目前僅僅是支持消息消費失敗和消息消費延遲兩類告警規(guī)則，進一步的數(shù)據(jù)分析和優(yōu)化建議是缺失的，這也是業(yè)界普遍公認的技術(shù)難點，需要結(jié)合實際的業(yè)務(wù)場景進行分析。
• 優(yōu)化層面：目前也僅僅是線下人工通知，比如基于消費最大耗時top排行榜提醒相關(guān)業(yè)務(wù)方進行消費邏輯優(yōu)化，從消費最大延遲top排行榜通知業(yè)務(wù)方消費能力不足是否需要擴容。希望達到的效果是，管理平臺基于數(shù)據(jù)分析生成優(yōu)化建議，自動推送送給業(yè)務(wù)方，并將業(yè)務(wù)方的反饋和執(zhí)行結(jié)果跟蹤到底，達到全流程的自動化閉環(huán)。

當然，作為一個消息中心管理平臺，對于底層消息中間件的運維、部署、監(jiān)控也是必不可少的。當前在嚴選的落地實踐是，廣泛調(diào)研并引入開源組件EFAK、rocketmq-dashboard，二次開發(fā)接入嚴選監(jiān)控告警體系，再結(jié)合嚴選OF監(jiān)控，低成本、高效的解決了消息中間件集群及機器維度的運維監(jiān)控管理問題。至于后續(xù)是否需要將這部分功能統(tǒng)一集成到消息中心管理平臺，需要結(jié)合實際業(yè)務(wù)訴求和成本收益再進行決策。

6. 附錄

• EFAK：https://github.com/smartloli/EFAK
• rocketmq-dashboard：https://github.com/apache/rocketmq-dashboard