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

1. 引言??

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

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

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

2.1 痛點(diǎn)問題

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

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

2.2 價值

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

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

2.3 目標(biāo)

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

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

3.1 整體思路

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

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

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

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

3.2 概念定義

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

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

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

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

節(jié)點(diǎn)定義如下：

3.2.2 用戶視角定義

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

• 生產(chǎn)者：生產(chǎn)者服務(wù) -> 生產(chǎn)者代理 -> 消息中間件
• 消費(fèi)者：消費(fèi)者代理 -> 消費(fèi)者服務(wù)
• 全鏈路：生產(chǎn)者服務(wù) -> 生產(chǎn)者代理 -> 消息中間件 -> 消費(fèi)者代理 -> 消費(fèi)者服務(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é)點(diǎn)的關(guān)鍵元數(shù)據(jù)信息。
• 應(yīng)用訪問日志：云外(/home/logs/consul-nginx/access.log)，云內(nèi)(/home/logs/yanxuan-sidecar-envoy/access.log)，可獲取推送到消息訂閱方的上游節(jié)點(diǎn)信息，若是網(wǎng)關(guān)節(jié)點(diǎn)需再結(jié)合網(wǎng)關(guān)日志（僅采集消息中心服務(wù)實(shí)例上的日志）。
• 網(wǎng)關(guān)日志：根據(jù)網(wǎng)關(guān)日志獲取到真正接收請求方的上游節(jié)點(diǎn)信息。?

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

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

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

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

• 生產(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ù)

• 消費(fèi)者（topic+訂閱方）：

• 1d/1h/5min/1min 消費(fèi)量

• 1d/1h/5min/1min 消費(fèi)平均耗時

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

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

• 1d/1h/5min/1min 消費(fèi)平均延遲

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

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

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

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

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

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

4. 平臺功能?

4.1 消息鏈路查詢

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

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

提供拓?fù)浜腿罩緝煞N視圖模式，供用戶進(jìn)行切換展示。?

• 拓?fù)湟晥D：

• 日志視圖：

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

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

• 查看失敗原因：

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

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

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

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

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

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

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

• 消息數(shù)據(jù)平均大小統(tǒng)計(jì)圖：查看消息網(wǎng)絡(luò)傳輸包大小（【平均】是指時間窗口的聚合指標(biāo)數(shù)據(jù)）。?

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

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

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

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

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

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

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

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

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

可點(diǎn)擊消息拓?fù)洳榭磮D形化的發(fā)布訂閱關(guān)系，具體如下：

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

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

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

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

4.4 自助運(yùn)維

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

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

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

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

4.5 工單自動化審批

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

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

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

5.1 總結(jié)

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

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

5.2 展望

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

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

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

6. 附錄

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