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