簡介：近年來，消息領域的全面雲原生化逐漸走向深入，比如 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實現中沒能將離線客戶端指標值及時清理造成客戶端端口持續增加導致系統告警。
結果：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+項，巡檢結果以表格形式呈現，如下圖表格。
5、集羣可視化：消息對賬監控
在設計告警時，總會有些沒有考慮到的告警項，這裏的解決方案是消息對賬系統，它可以有效監控消息延遲、丟失和集羣健康度。
消息對賬系統的優勢在於它提供端對端的監控，包羅多項監控的效果，並且它的自驅力可以替沒有考慮到的告警項兜底，故障的發現和定位也被獨立開。
6、集羣可運維：自動化平臺
可運維能力的建設是通過自動化來實現的，其根本目的是釋放人力。
下圖展示的是topic遷移工具，從RocketMQ和Kafka兩部分改造：
a. RocketMQ
- 修改 nameserver delete 邏輯，支持在 broker 間自動遷移 topic；
- 同時處理 consumer-group，retry/dlq topic；
- 依賴自研管理平臺；
b. Kafka
- 基於 reassign 改造，自定義 reassign 算法，減少 partition 搬遷的影響；
- stage 工作流化，每一步自動執行，人工確認下一步操作；
- 集成自研管理平臺。
三、未來的探索與規劃
近年來，消息領域的全面雲原生化逐漸走向深入，比如 RocketMQ 5.0 版本的存算分離設計和 raft 模式，再比如 Kafka3.0 引入了分層設計的方式（tiered storage）和 raft 模式，以及近年來新崛起的 Pulsar 也開始採用雲原生架構，在未來都可以針對具體業務需求引入進行功能迭代，發揮組件的最大價值。
本文爲阿里雲原創內容，未經允許不得轉載。