嚴選消息中心管理平臺建設實踐
消息中心作為電商業務場景必不可少的核心組件，自嚴選上線以來，就開始了建設和演進迭代之路。截止目前，消息中心已接入200+服務，1500+消息，覆蓋基礎技術、供應鏈、分銷客售、主站、交易訂單、數據算法等嚴選所有業務場景。本文對于消息中心的技術架構演進不做詳細敘述，重點介紹面向業務使用方的消息中心管理平臺建設實踐經驗。
1. 引言??
消息中心作為電商業務場景必不可少的核心組件，自嚴選上線以來，就開始了建設和演進迭代之路。截止目前，消息中心已接入200+服務，1500+消息，覆蓋基礎技術、供應鏈、分銷客售、主站、交易訂單、數據算法等嚴選所有業務場景。
本文對于消息中心的技術架構演進不做詳細敘述，重點介紹面向業務使用方的消息中心管理平臺建設實踐經驗。
2. 平臺建設背景?
2.1 痛點問題
通過廣泛溝通收集需求，在消息中心研發運維過程中，經常會碰到如下痛點問題：
- 影響研發效率：消息中心作為異步解耦的中間節點，串聯上下游服務，系統鏈路較長，由于缺失完整的消息鏈路查詢功能，當業務邏輯出現問題時，無論上下游服務都需要找消息中心開發排查問題，極大影響業務側的研發效率，同時提高了消息中心運維成本。
- 無法感知異常：消息中心異步解耦了上下游服務，導致在一些業務場景生產方無法感知消費方的處理異常，被動靠業務反饋才能發現問題。
- 運維成本高：由于生產者或者消費者監控不足，需要依賴消息中心開發通知生產方發送消息失敗，或者通知消費方消費消息失敗或者消息積壓等，很大程度上加大了消息中心的運維成本。
2.2 價值
定位和處理上面這些問題，通常會花費較長時間，極大影響研發效率，更嚴重的還會影響線上業務。因此，亟需一個面向業務開發的消息中心管理平臺，提高研發效能：
- 提供完整的消息鏈路查詢能力，方便業務接入方可自助式的快速定位排查問題；
- 提供消息鏈路數據的準實時統計分析能力，提升系統可觀測性，方便業務方配置監控報警（消息延遲、消費異常）；
- 提供消息鏈路數據的離線統計分析能力，方便業務使用方和消息中心自身進行風險評估，提升系統穩定性；
- 提供初步的自動化運維能力，提升應急止損處理響應效率，降低人工運維成本。
2.3 目標
面向業務使用方：為了提升各位業務開發同學對各自負責系統的消息收發治理和問題排查定位的效率，建設嚴選消息中心管理平臺，通過整合串聯不同系統間的消息鏈路，統一并標準化定義消息鏈路的關鍵節點，基于元數據進行統計分析從而配置報警監控，最終達到整個嚴選技術體系降本增效的目的。同時，通過自動化工單閉環消息發布、下線、消息訂閱、取消訂閱完整生命周期管理，入駐嚴選DevOps管理平臺天樞，將消息中心融入整個DevOps研發體系。
3. 平臺建設方案?
3.1 整體思路
核心思路就是通過提升消息中心的可觀測性，通過消息中心管理平臺給用戶提供可視化配置管理能力。一個好的可觀測系統，最后要做到的形態就是實現Metrics、Tracing、Logging的融合：
- Tracing：提供了一個請求從接收到處理完畢整個生命周期的跟蹤路徑，通常請求都是在分布式的系統中處理，所以也叫做分布式鏈路追蹤，消息中心場景就是完整的消息鏈路。
- Metrics：提供量化的系統內/外部各個維度的指標，消息中心場景就是發送耗時、消費耗時、端到端的延遲、消息積壓等。
- Logging：提供系統/進程最精細化的信息，消息中心場景就是消息內容、消息發送者元數據信息、消息消費者元數據信息等。這三者在可觀測性上缺一不可，基于Metrics的告警發現異常，通過Tracing定位問題模塊，根據模塊具體的Logging定位到錯誤根源，最后再基于這次問題排查經驗調整Metrics告警閾值，達到預警效果。
在嚴選消息中心場景，在盡量復用現有組件能力的原則下，獲取這三者數據的具體執行路徑如下：
- Tracing：復用嚴選分布式鏈路追蹤系統(APM)能力，消息中心接入caesar agent，將traceId和messageId等核心數據打印到業務日志。(消息中心的流量染色，壓測標識透傳也基于此思路)
- Metrics：復用嚴選實時計算平臺能力，自定義flink任務，將日志平臺采集的業務日志數據進行聚合計算，將實時指標數據存入網易時序數據庫(Ntsdb)。同時也可按需在嚴選數倉配置T+1離線任務，進行相關指標數據計算采集。
- Logging：復用?嚴選日志平臺能力??，打印業務日志，進行采集、存儲、查詢。
3.2 概念定義
3.2.1 消息鏈路節點定義?
消息中心以HTTP Proxy的模式對外提供服務，業務方不感知底層消息中間件，提供HTTP異步方式的發布訂閱功能。由如下三部分構成了消息中心：
- 生產者代理
- 消息中間件
- 消費者代理
完整的消息鏈路如下圖所示：
節點定義如下：
節點編碼 | 節點描述 |
message_received_success | 生產者代理成功接收到消息 |
message_received_failed | 生產者代理接收到消息失敗，一般是數據非法之類的異常 |
mq_received_success | 消息中間件寫入消息成功 |
mq_received_failed | 消息中間件寫入消息失敗 |
polled | 消費者代理從消息中間件中拉取消息成功 |
consumed | 消費者代理推送消息到訂閱方成功 |
consume_failed | 消費者代理推送消息到訂閱方失敗 |
failover_retry | 消費者代理失敗重試場景從消息中間件拉取消息成功 |
retry_failed | 消費者代理消息失敗重試場景推送消息到訂閱方再次失敗 |
meet_max_retry_times | 消費者代理消息失敗重試場景達到最大失敗次數，此后不會再重推 |
over_duration_time | 消費者代理消息失敗重試場景超過重試時長，此后不會再重推 |
3.2.2 用戶視角定義
不同的用戶視角關注的消息鏈路是不同的，用戶只需聚焦于自己的對應的消息鏈路即可：
- 生產者：生產者服務 -> 生產者代理 -> 消息中間件
- 消費者：消費者代理 -> 消費者服務
- 全鏈路：生產者服務 -> 生產者代理 -> 消息中間件 -> 消費者代理 -> 消費者服務
3.3 數據流分層架構?
3.3.1 數據源
數據源主要是基于如下三部分日志，可串聯整個消息鏈路：
- 應用業務日志：消息中心三個集群打印messageId、traceId以及對應鏈路節點的關鍵元數據信息。
- 應用訪問日志：云外(/home/logs/consul-nginx/access.log)，云內(/home/logs/yanxuan-sidecar-envoy/access.log)，可獲取推送到消息訂閱方的上游節點信息，若是網關節點需再結合網關日志（僅采集消息中心服務實例上的日志）。
- 網關日志：根據網關日志獲取到真正接收請求方的上游節點信息。?
3.3.2 數據采集層
復用日志平臺現有功能，在日志平臺配置業務日志采集任務，此處不詳述。
3.3.3 數據分析層
按需在數倉平臺配置T+1的離線分析任務，在嚴選實時計算平臺配置運行自定義flink任務，聚合時間窗口可根據實際情況配置，主要指標如下：
- 生產者（topic+發送方）：
- 1d/1h/5min/1min 發送量
- 1d/1h/5min/1min 發送平均耗時
- 1d/1h/5min/1min 發送慢請求率/數
- 1d/1h/5min/1min 發送失敗率/數
- 消費者（topic+訂閱方）：
1d/1h/5min/1min 消費量
1d/1h/5min/1min 消費平均耗時
1d/1h/5min/1min 消費慢請求率/數
1d/1h/5min/1min 消費失敗率/數
1d/1h/5min/1min 消費平均延遲
3.3.4 數據存儲層
- 日志平臺ES集群：用于消息鏈路實時查詢，日志平臺提供openapi接口給消息中心管理平臺進行鏈路查詢。
- HIVE：消息中心打印的業務日志通過日志平臺的日志采集傳輸鏈路會存到數倉的hive表。
- NTSDB：經過流式計算生成的指標數據會存入網易時序數據庫，供消息中心管理平臺進行查詢生成統計圖表。
- 服務端DB：消息中心管理平臺一些基礎信息的維護與展示，比如監控報警配置、自助運維審計日志等。?
3.3.5 數據展示層
- 消息鏈路查詢：支持traceId和messageId兩個維度的查詢。
- 數據統計分析：根據統計指標展示不同維度的圖表。
- 自助化運維：可從生產者和消費者兩個視角進行進行消息補推，并提供審計功能：
- 生產者：指定messageId、topic的生產狀態等篩選條件將消息重新寫入消息中間件（即推送所有訂閱方）。
- 消費者：指定messageId、topic的消費狀態等篩選條件將消息重新推到指定訂閱方。
- 元數據管理：主要是topic的生產訂閱關系的查詢功能及拓撲展示、重試策略配置、報警配置等。
4. 平臺功能?
4.1 消息鏈路查詢
?支持如下兩個維度的消息鏈路查詢：
- 消息id(messageId)搜索：對應一條完整的消息鏈路（消息發送方確保消息id的唯一性）。
- 分布式鏈路(traceId)搜索：可能對應多條消息鏈路（消息發送方接入APM）。
提供拓撲和日志兩種視圖模式，供用戶進行切換展示。?
- 拓撲視圖：
- 日志視圖：
拓撲視圖下可點擊查看消息內容、消費失敗原因、發送耗時、消費耗時、端到端延遲。默認展示消息的所有消費者，用戶可點擊篩選只展示自己感興趣的消費者消費鏈路。
- 查看消息內容：
- 查看失敗原因：
4.2 數據統計分析
4.2.1 業務方使用視角
可篩選查看topic 【指定時間范圍內 + 指定時間間隔】的聚合指標數據，相關統計圖具體如下：
- 生產消費數量統計圖：排查消息消費是否存在堆積。?
- 生產消費失敗統計圖：排查消息生產/消費是否存在異常。?
- 生產消費平均耗時統計圖：排查生產/消費的性能（【平均】是指時間窗口的聚合指標數據）。?
- 消費平均延遲統計圖：排查端到端的延遲（【平均】是指時間窗口的聚合指標數據）。?
- 消息數據平均大小統計圖：查看消息網絡傳輸包大小（【平均】是指時間窗口的聚合指標數據）。?
4.2.2 系統管理員視角
系統管理員不關注具體某個topic，而是關注消息中心集群的整體運行情況，相關統計圖表具體如下：
- 消費訂閱系統級延遲圖：通過85線、95線、99線查看消息系統整體端到端的延遲情況。?
- 消息消費延遲最大值Top排行表：用于通知消息消費者對于消息時效性的邏輯處理優化。?
- 消息消費耗時最大值Top排行表：用于通知消息消費方進行消費邏輯的性能優化。?
- 發送消費統計圖：用于統計消息量較大的消息。?
4.3 元數據管理
支持從消息主題、發布方、訂閱方三個維度分頁查詢消息元數據信息，主要包括消息主題、發布方CMDB服務編碼、訂閱方CMDB服務編碼、訂閱url等相關配置，具體如下：
可點擊消息詳情，查看消息元數據、消息格式、消息示例信息，具體如下：
可點擊消息拓撲查看圖形化的發布訂閱關系，具體如下：
可查看消息失敗重試策略，工單申請調整重試策略，具體如下：
可查看報警配置，消息訂閱方所屬服務技術負責人可調整告警配置，主要分為兩種類型的告警：
- 消息失敗告警：達到失敗重試次數的消息認為消費失敗。
- 消息延遲告警：端到端的延遲告警，對于消息時效性敏感的消息可根據實際情況調整。
報警的指標數據是通過flink實時任務聚合采集存入Ntsdb，告警通知對接嚴選告警平臺，告警接收人員即為線上服務所對應的線上監控人員角色。
4.4 自助運維
當消息中心上下游系統出現異常時，只要確保消息已成功投遞到消息中心，消息中心可提供自助補推功能，來輔助業務快速恢復。支持根據消息id或者消息狀態篩選查詢指定時間范圍內的消息，來決定是給消息的所有訂閱者推送還是給某個訂閱者推送。
消息推送對操作人進行嚴格的數據權限隔離：
- 如果要給消息的所有訂閱者推送，則必須是所屬消息服務的技術負責人，需要與涉及的所有訂閱方技術負責人充分溝通，再進行推送。
- 如果要給消息的某個訂閱者推送，則必須是該訂閱者服務的技術負責人，操作人對此次操作負責。
消息補推屬于高危操作，所有操作都會進行記錄進行事后審計跟蹤，并可查看每條推送記錄的具體詳情：
4.5 工單自動化審批
通過自動化工單閉環消息發布、下線、消息訂閱、取消訂閱完整生命周期管理，入駐嚴選DevOps管理平臺天樞，有機的將消息中心融入整個DevOps研發體系。
同時將消息工單作為一個變更事件，基于天樞平臺自動將測試環境的工單同步到線上。同時作為需求發布上線的風險變更管控卡點項，有效規避漏申請消息發布/訂閱的情況而導致的業務異常。
5. 總結與展望?
5.1 總結
消息中心管理平臺自上線以來，受到了不少業務方的好評，也廣泛收集建議進行了一些功能迭代優化，初步達成了預期目標：
- 業務賦能：消息中心已接入200+服務，1500+消息，覆蓋基礎技術、供應鏈、分銷客售、主站、交易訂單、數據算法等嚴選所有業務場景。
- 運維成本大幅度降低：技術咨詢數量從上線前周均50+，降低到目前周均小于10次。
- 研發效率逐步提升：業務方高效便捷的自行排查問題和自助補推消息，消息工單完結率提升到超過90%。
5.2 展望
消息中心管理平臺下一步的重點方向是數字化建設，借鑒當前比較流行的FinOps執行路徑：成本展示 -> 成本分析 -> 成本優化：
- 展示層面：當前消息中心管理平臺雖然有不少統計圖表，僅僅是基于topic視角或者系統管理員的全局視角，也收到不少業務方的反饋意見，如何從業務方視角更好地將數據聚合展示推送觸達用戶，是接下來要考慮的問題。
- 分析層面：目前僅僅是支持消息消費失敗和消息消費延遲兩類告警規則，進一步的數據分析和優化建議是缺失的，這也是業界普遍公認的技術難點，需要結合實際的業務場景進行分析。
- 優化層面：目前也僅僅是線下人工通知，比如基于消費最大耗時top排行榜提醒相關業務方進行消費邏輯優化，從消費最大延遲top排行榜通知業務方消費能力不足是否需要擴容。希望達到的效果是，管理平臺基于數據分析生成優化建議，自動推送送給業務方，并將業務方的反饋和執行結果跟蹤到底，達到全流程的自動化閉環。
當然，作為一個消息中心管理平臺，對于底層消息中間件的運維、部署、監控也是必不可少的。當前在嚴選的落地實踐是，廣泛調研并引入開源組件EFAK、rocketmq-dashboard，二次開發接入嚴選監控告警體系，再結合嚴選OF監控，低成本、高效的解決了消息中間件集群及機器維度的運維監控管理問題。至于后續是否需要將這部分功能統一集成到消息中心管理平臺，需要結合實際業務訴求和成本收益再進行決策。
6. 附錄
- EFAK：https://github.com/smartloli/EFAK
- rocketmq-dashboard：https://github.com/apache/rocketmq-dashboard
