簡介：近年來，消息領域的全面云原生化逐漸走向深入，比如 RocketMQ 5.0 版本的存算分離設計和 raft 模式，再比如 Kafka3.0 引入了分層設計的方式（tiered storage）和 raft 模式，以及近年來新崛起的 Pulsar 也開始采用云原生架構，在未來都可以針對具體業務需求引入進行功能迭代，發揮組件的最大價值。

作者：張億皓｜小紅書消息中間件負責人

一、消息隊列業務場景與挑戰

1、整體規模

下圖展示了 RocketMQ 和 Kafka 的總體規模。其中峰值 ?TPS 的 8000w/s 一般出現在晚上下班以后的時間段，寫入量達到50GB/s，每天新增2-3PB數據，節點數1200+個。

2、業務架構

雖然 RocketMQ 和 Kafka 的性能相似，但在使用場景上還是有所區別的。RocketMQ 豐富的業務特性更適用于在線業務場景，而 Kafka 的高吞吐性使其更偏向離線、近線業務。當然，在實際應用中也會有交叉使用的現象，有時在線業務也會使用 Kafka 解耦，有的流處理數據也會使用 RocketMQ 存儲。

業務總體架構如下圖所示，業務日志和APP用戶行為打點類的內容會發給 Kafka，數據庫增量日志、在線業務、線上數據交換等會發給 RocketMQ。Kafka 和 RocketMQ 中的數據會有一部分流入 flink 中構建實時數倉、離線數倉以及一些數據產品（如報表、監控，等），RocketMQ 中另一部分數據會用于在線業務APP異步解耦。

消息隊列業務架構

3、穩定性挑戰

a. ? 背景：

小紅書整體收斂消息組件較晚，公司技術架構最大的目標是提升系統穩定性；

b. ? 挑戰：

現存消息組件使用量極大，但沒有穩定性保障；同時面臨人手緊缺、時間緊，對MQ原理了解不深入的困境；

c. ? 策略：

先做監控，增強集群的可觀測能力是了解其健康狀況的最高效手段。

4、穩定性治理

除了監控告警，我們在穩定性治理方面還做了以下改造工作：

a. ? 引擎：資源隔離，新增監控打點等；

b. ? 平臺：工單審核，權限管控，業務追溯；

c. ? 治理：針對集群可視化能力和集群可運維能力的建設；

二、消息隊列治理實踐

1、集群可視化：監控metrics

下圖是基于 Prometheus Grafana 構建的消息中間件體系架構。

消息中間件監控體系架構圖

圖中包含三個監控維度：硬件維度、服務維度和業務維度，累計收集監控指標150+項。

那么如何定義這三個維度的監控指標呢？

a. 硬件維度：主要包括網絡帶寬、CPU使用率、磁盤容量/IO、TCP丟包/延遲等資源指標；

b. 服務維度：主要指運行狀況的指標，如：宕機監控、JVM指標、讀寫時延、請求隊列等；

c. 業務維度：即面向用戶的指標，這是客戶比較關心的指標，如：消費延遲/積壓、QPS、Topic吞吐量、Offset等；

由于公司內部規定一個節點只能使用一個端口給Prometheus，而各項監控指標大多是分開收集，于是設計了指標聚合服務 MAS 將所有指標匯集在一起，同時又增加了一些元信息幫助進一步排查問題。這里 MAS 相當于metric 的一個代理層，可以根據業務的實際情況來添加。

2、告警處理

下圖列舉了一些發生在監控體系剛建立時候的告警信息，當時每天的告警信息約有600-700條之多，告警的問題也是各式各樣，根本無法處理，造成監控系統形同虛設。

鑒于以上情況，我們提出監控的核心原則要寧缺毋濫，不要淹沒在告警海中，告警太多和沒有告警沒什么區別。根據這一原則制定了一系列應對策略：

• 初期：關閉低優告警，以確保每一條高優告警能得到及時發現和處理；
• 中期：隨著高優告警的減少，逐步打開之前屏蔽的告警，進一步處理，實現告警數量逐步減少；
• 后期：打開全部告警，確保日常告警每一條都能及時發現和處理。

根據我們的經驗，到后期基本不會有“服務不可用”這類的告警，大部分告警屬于預警，如果預警能及時介入處理，就可以確保在問題進一步擴大之前解決。

告警處理階段性策略

3、集群可視化：metric設計與優化

RocketMQ 的服務、業務指標監控，基于開源 RocketMQ-exporter 進行改造，解決 metrics 泄漏、部分指標采集偏差等問題。

這里著重介紹兩個比較重要的改造：

a. ? lag監控優化

• 問題一：consumer metric 泄露，exporter 運行幾天指標量就可達到 300w+，curl 一次接口花費時間 25s，log文本有600MB； ? ?

原因：如下圖所示，每接入新的客戶端，端口值就會增加，由于exporter實現中沒能將離線客戶端指標值及時清理造成客戶端端口持續增加導致系統告警。

改造：在exporter中加入metric expire模塊；

結果：curl一次接口花費的時間降到2s；

• 問題二：lag指標不準，造成線上誤告警

原因：export只提供group維度的 rocketmq_group_diff，沒有 broker 維度的，要額外計算；

改造：在 broker 中加入計算邏輯，先將 lag 計算好；

結果：可以從下圖中看到，消息積壓值從 6K 的抖動恢復成平穩值；

b. ? 分位線/滑動窗優化

• 問題一：線上時常會遇到 broker busy 的問題，需要對發生的時間點進行監控。雖然 exporter自帶 send pool 等指標，但為瞬時值，幾乎沒有參考意義；

改造：在 broker 中加入計算5分鐘內最大值的指標；

結果：

• 問題二：消息寫入耗時是歷史最大值，參考作用有限；

改造：優化為5分鐘內耗時，以及P99/P999等分位值；

結果：得到準確的消息寫入耗時。

4、集群可視化：巡檢系統

巡檢系統與監控系統的區別是：監控系統是反應瞬時的問題，變化很快，需要及時發現和處理，呈現形式相對固定；巡檢系統則是長期工作的監督，針對靜態環境和配置，變化較少，呈現形式更加自由。

隨著治理工作的持續開展，如何確認一個集群達到健康狀態？

a. ?嚴格按照部署標準部署集群，包括硬件配置、運行參數、可用區等，對所有集群進行定期巡檢，產出報表反映集群狀況;

b. ?共制定核心標準20+項，巡檢結果以表格形式呈現，如下圖表格。

c. ?由于指標過多無法從判斷問題，因此設定了集群健康分體系，是基于集群的可用性只能通過唯一指標反映的思想，將每個指標設置一個權重，通過最終的分值來判斷集群是否存在問題，如下圖所示：

5、集群可視化：消息對賬監控

在設計告警時，總會有些沒有考慮到的告警項，這里的解決方案是消息對賬系統，它可以有效監控消息延遲、丟失和集群健康度。

消息對賬系統的優勢在于它提供端對端的監控，包羅多項監控的效果，并且它的自驅力可以替沒有考慮到的告警項兜底，故障的發現和定位也被獨立開。

消息對賬監控系統

在 Kafka 社區提供了相應的 Kafka Monitor 組件，我們將這個組件進行服務化改造，提供自動化添加新集群監控的能力，減輕運維的壓力。

6、集群可運維：自動化平臺

可運維能力的建設是通過自動化來實現的，其根本目的是釋放人力。

下圖展示的是topic遷移工具，從RocketMQ和Kafka兩部分改造：

a. ? RocketMQ

• 修改 nameserver delete 邏輯，支持在 broker 間自動遷移 topic；
• 同時處理 consumer-group，retry/dlq topic；
• 依賴自研管理平臺；

b. ? Kafka

• 基于 reassign 改造，自定義 reassign 算法，減少 partition 搬遷的影響；
• stage 工作流化，每一步自動執行，人工確認下一步操作；
• 集成自研管理平臺。

Topic遷移工具

三、未來的探索與規劃

近年來，消息領域的全面云原生化逐漸走向深入，比如 RocketMQ 5.0 版本的存算分離設計和 raft 模式，再比如 Kafka3.0 引入了分層設計的方式（tiered storage）和 raft 模式，以及近年來新崛起的 Pulsar 也開始采用云原生架構，在未來都可以針對具體業務需求引入進行功能迭代，發揮組件的最大價值。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的小红书消息中间件的运维实践与治理之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。