RocketMQ 千錘百煉--哈囉在分散式訊息治理和微服務治理中的實踐
作者|樑勇
背景
哈囉已進化為包括兩輪出行(哈囉單車、哈囉助力車、哈囉電動車、小哈換電)、四輪出行(哈囉順風車、全網叫車、哈囉打車)等的綜合化移動出行平臺,並向酒店、到店團購等眾多本地生活化生態探索。
隨著公司業務的不斷髮展,流量也在不斷增長。我們發現生產中的一些重大事故,往往是被突發的流量衝跨的,對流量的治理和防護,保障系統高可用就尤為重要。
本文就哈囉在訊息流量和微服務呼叫的治理中踩過的坑、積累的經驗進行分享。
作者介紹
樑勇 ( 老樑 ) ,《 RocketMQ 實戰與進階》專欄聯合作者、參與了《 RocketMQ 技術內幕》審稿工作。ArchSummit 全球架構師大會講師、QCon 案例研習社講師。
當前主要在後端中介軟體方向,在公眾號【瓜農老樑】已陸續發表百餘篇原始碼實戰類文章,涵蓋 RocketMQ 系列、Kafka 系列、GRPC 系列、Nacosl 系列、Sentinel 系列、Java NIO 系列。目前就職於哈囉出行,任職高階技術專家。
聊聊治理這件事
開始之前先聊聊治理這件事情,下面是老樑個人理解:
治理在幹一件什麼事?
- 讓我們的環境變得美好一些
需要知道哪些地方還不夠好?
- 以往經驗
- 使用者反饋
- 業內對比
還需要知道是不是一直都是好的?
- 監控跟蹤
- 告警通知
不好的時候如何再讓其變好?
- 治理措施
- 應急方案
目錄
- 打造分散式訊息治理平臺
- RocketMQ 實戰踩坑和解決
- 打造微服務高可用治理平臺
背景
裸奔的 RabbitMQ
公司之前使用 RabbitMQ ,下面在使用 RabbitMQ 時的痛點,其中很多事故由於 RabbitMQ 叢集限流引起的。
- 積壓過多是清理還是不清理?這是個問題,我再想想。
- 積壓過多觸發叢集流控?那是真的影響業務了。
- 想消費前兩天的資料?請您重發一遍吧。
- 要統計哪些服務接入了?您要多等等了,我得去撈IP看看。
- 有沒有使用風險比如大訊息?這個我猜猜。
裸奔的服務
曾經有這麼一個故障,多個業務共用一個數據庫。在一次晚高峰流量陡增,把資料庫打掛了。
- 資料庫單機升級到最高配依然無法解決
- 重啟後緩一緩,不一會就又被打掛了
- 如此迴圈著、煎熬著、默默等待著高峰過去
思考:無論訊息還是服務都需要完善的治理措施
打造分散式訊息治理平臺
設計指南
哪些是我們的關鍵指標,哪些是我們的次要指標,這是訊息治理的首要問題。
設計目標
旨在遮蔽底層各個中介軟體( RocketMQ / Kafka )的複雜性,通過唯一標識動態路由訊息。同時打造集資源管控、檢索、監控、告警、巡檢、容災、視覺化運維等一體化的訊息治理平臺,保障訊息中介軟體平穩健康執行。
訊息治理平臺設計需要考慮的點
- 提供簡單易用 API
- 有哪些關鍵點能衡量客戶端的使用沒有安全隱患
- 有哪些關鍵指標能衡量叢集健康不健康
- 有哪些常用的使用者/運維操作將其視覺化
- 有哪些措施應對這些不健康
儘可能簡單易用
設計指南
把複雜的問題搞簡單,那是能耐。
極簡統一 API
提供統一的 SDK 封裝了( Kafka / RocketMQ )兩種訊息中介軟體。
一次申請
主題消費組自動建立不適合生產環境,自動建立會導致失控,不利於整個生命週期管理和叢集穩定。需要對申請流程進行控制,但是應儘可能簡單。例如:一次申請各個環境均生效、生成關聯告警規則等。
客戶端治理
設計指南
監控客戶端使用是否規範,找到合適的措施治理
場景回放
場景一 瞬時流量與叢集的流控
假設現在叢集 Tps 有 1 萬,瞬時翻到 2 萬甚至更多,這種過度陡增的流量極有可能引發叢集流控。針對這類場景需監控客戶端的傳送速度,在滿足速度和陡增幅度閾值後將傳送變的平緩一些。
場景二 大訊息與叢集抖動
當客戶端傳送大訊息時,例如:傳送幾百KB甚至幾兆的訊息,可能造成 IO 時間過長與叢集抖動。針對這類場景治理需監控傳送訊息的大小,我們採取通過事後巡檢的方式識別出大訊息的服務,推動使用同學壓縮或重構,訊息控制在 10KB 以內。
場景三 過低客戶端版本
隨著功能的迭代 SDK 的版本也會升級,變更除了功能外還有可能引入風險。當使用過低的版本時一個是功能不能得到支援,另外一個是也可能存在安全隱患。為了解 SDK 使用情況,可以採取將 SDK 版本上報,通過巡檢的方式推動使用同學升級。
場景四 消費流量摘除和恢復
消費流量摘除和恢復通常有以下使用場景,第一個是釋出應用時需要先摘流量,另外一個是問題定位時希望先把流量摘除掉再去排查。為了支援這種場景,需要在客戶端監聽摘除/恢復事件,將消費暫停和恢復。
場景五 傳送/消費耗時檢測
傳送/消費一條訊息用了多久,通過監控耗時情況,巡檢摸排出效能過低的應用,針對性推動改造達到提升效能的目的。
場景六 提升排查定位效率
在排查問題時,往往需要檢索發了什麼訊息、存在哪裡、什麼時候消費的等訊息生命週期相關的內容。這部分可以通過 msgId 在訊息內部將生命週期串聯起來。另外是通過在訊息頭部埋入 rpcId / traceId 類似鏈路標識,在一次請求中將訊息串起來。
治理措施提煉
需要的監控資訊
- 傳送/消費速度
- 傳送/消費耗時
- 訊息大小
- 節點資訊
- 鏈路標識
- 版本資訊
常用治理措施
- 定期巡檢:有了埋點資訊可以通過巡檢將有風險的應用找出來。例如傳送/消費耗時大於 800 ms、訊息大小大於 10 KB、版本小於特定版本等。
- 傳送平滑:例如檢測到瞬時流量滿足 1 萬而且陡增了 2 倍以上,可以通過預熱的方式將瞬時流量變的平滑一些。
- 消費限流:當第三方介面需要限流時,可以對消費的流量進行限流,這部分可以結合高可用框架實現。
- 消費摘除:通過監聽摘除事件將消費客戶端關閉和恢復。
主題/消費組治理
設計指南
監控主題消費組資源使用情況
場景回放
場景一 消費積壓對業務的影響
有些業務場景對消費堆積很敏感,有些業務對積壓不敏感,只要後面追上來消費掉即可。例如單車開鎖是秒級的事情,而資訊彙總相關的批處理場景對積壓不敏感。通過採集消費積壓指標,對滿足閾值的應用採取實時告警的方式通知到應用負責的同學,讓他們實時掌握消費情況。
場景二 消費/傳送速度的影響
傳送/消費速度跌零告警?有些場景速度不能跌零,如果跌零意味著業務出現異常。通過採集速度指標,對滿足閾值的應用實時告警。
場景三 消費節點掉線
消費節點掉線需要通知給應用負責的同學,這類需要採集註冊節點資訊,當掉線時能實時觸發告警通知。
場景四 傳送/消費不均衡
傳送/消費的不均衡往往影響其效能。記得有一次諮詢時有同學將傳送訊息的key設定成常量,預設按照 key 進行 hash 選擇分割槽,所有的訊息進入了一個分割槽裡,這個效能是無論如何也上不來的。另外還要檢測各個分割槽的消費積壓情況,出現過度不均衡時觸發實時告警通知。
治理措施提煉
需要的監控資訊
- 傳送/消費速度
- 傳送分割槽詳情
- 消費各分割槽積壓
- 消費組積壓
- 註冊節點資訊
常用治理措施
- 實時告警:對消費積壓、傳送/消費速度、節點掉線、分割槽不均衡進行實時告警通知。
- 提升效能:對於有消費積壓不能滿足需求,可以通過增加拉取執行緒、消費執行緒、增加分割槽數量等措施加以提升。
- 自助排查:提供多維度檢索工具,例如通過時間範圍、msgId 檢索、鏈路系統等多維度檢索訊息生命週期。
叢集健康治理
設計指南
度量叢集健康的核心指標有哪些?
場景回放
場景一 叢集健康檢測
叢集健康檢測回答一個問題:這個叢集是不是好的。通過檢測叢集節點數量、叢集中每個節點心跳、叢集寫入Tps水位、叢集消費Tps水位都是在解決這個問題。
場景二 叢集的穩定性
叢集流控往往體現出叢集效能的不足,叢集抖動也會引發客戶端傳送超時。通過採集叢集中每個節點心跳耗時情況、叢集寫入Tps水位的變化率來掌握叢集是否穩定。
場景三 叢集的高可用
高可用主要針對極端場景中導致某個可用區不可用、或者叢集上某些主題和消費組異常需要有一些針對性的措施。例如:MQ 可以通過同城跨可用區主從交叉部署、動態將主題和消費組遷移到災備叢集、多活等方式進行解決。
治理措施提煉
需要的監控資訊
- 叢集節點數量採集
- 叢集節點心跳耗時
- 叢集寫入 Tps 的水位
- 叢集消費 Tps 的水位
- 叢集寫入 Tps 的變化率
常用治理措施
- 定期巡檢:對叢集 Tps 水位、硬體水位定期巡檢。
- 容災措施:同城跨可用區主從交叉部署、容災動態遷移到災備叢集、異地多活。
- 叢集調優:系統版本/引數、叢集引數調優。
- 叢集分類:按業務線分類、按核心/非核心服務分類。
最核心指標聚焦
如果說這些關鍵指標中哪一個最重要?我會選擇叢集中每個節點的心跳檢測,即:響應時間( RT ),下面看看影響 RT 可能哪些原因。
關於告警
- 監控指標大多是秒級探測
- 觸發閾值的告警推送到公司統一告警系統、實時通知
- 巡檢的風險通知推送到公司巡檢系統、每週彙總通知
訊息平臺圖示
架構圖
看板圖示
- 多維度:叢集維度、應用維度
- 全聚合:關鍵指標全聚合
RocketMQ 實戰中踩過的坑和解決方案
行動指南
我們總會遇到坑,遇到就把它填了。
1. RocketMQ 叢集 CPU 毛刺
問題描述
**
RocketMQ 從節點、主節點頻繁 CPU 飆高,很明顯的毛刺,很多次從節點直接掛掉了。
只有系統日誌有錯誤提示
```js
2020-03-16T17:56:07.505715+08:00 VECS0xxxx kernel:[] ? __alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505717+08:00 VECS0xxxx kernel: java: page allocation failure. order:0, mode:0x202020-03-16T17:56:07.505719+08:00 VECS0xxxx kernel: Pid: 12845, comm: java Not tainted 2.6.32-754.17.1.el6.x86_64 #12020-03-16T17:56:07.505721+08:00 VECS0xxxx kernel: Call Trace:2020-03-16T17:56:07.505724+08:00 VECS0xxxx kernel:[] ? __alloc_pages_nodemask+0x7e1/0x9602020-03-16T17:56:07.505726+08:00 VECS0xxxx kernel: [] ? dev_queue_xmit+0xd0/0x3602020-03-16T17:56:07.505729+08:00 VECS0xxxx kernel: [] ? ip_finish_output+0x192/0x3802020-03-16T17:56:07.505732+08:00 VECS0xxxx kernel: [] ?
各種除錯系統引數只能減緩但是不能根除,依然毛刺超過 50%
解決方案
將叢集所有系統升級從 centos 6 升級到 centos 7 ,核心版本也從從 2.6 升級到 3.10 ,CPU 毛刺消失。
2. RocketMQ 叢集線上延遲訊息失效
問題描述
RocketMQ 社群版預設本支援 18 個延遲級別,每個級別在設定的時間都被會消費者準確消費到。為此也專門測試過消費的間隔是不是準確,測試結果顯示很準確。然而,如此準確的特性居然出問題了,接到業務同學報告線上某個叢集延遲訊息消費不到,詭異!
解決方案
將" delayOffset.json "和" consumequeue / SCHEDULE_TOPIC_XXXX "移到其他目錄,相當於刪除;逐臺重啟 broker 節點。重啟結束後,經過驗證,延遲訊息功能正常傳送和消費。
打造微服務高可用治理平臺
設計指南
哪些是我們的核心服務,哪些是我們的非核心服務,這是服務治理的首要問題
設計目標
服務能應對突如其來的陡增流量,尤其保障核心服務的平穩執行。
應用分級和分組部署
應用分級
根據使用者和業務影響兩個緯度來進行評估設定的,將應用分成了四個等級。
- 業務影響:應用故障時影響的業務範圍
- 使用者影響:應用故障時影響的使用者數量
S1:核心產品,產生故障會引起外部使用者無法使用或造成較大資損,比如主營業務核心鏈路,如單車、助力車開關鎖、順風車的發單和接單核心鏈路,以及其核心鏈路強依賴的應用。
S2: 不直接影響交易,但關係到前臺業務重要配置的管理與維護或業務後臺處理的功能。
S3: 服務故障對使用者或核心產品邏輯影響非常小,且對主要業務沒影響,或量較小的新業務;面向內部使用者使用的重要工具,不直接影響業務,但相關管理功能對前臺業務影響也較小。
S4: 面向內部使用者使用,不直接影響業務,或後續需要推動下線的系統。
分組部署
S1 服務是公司的核心服務,是重點保障的物件,需保障其不被非核心服務流量意外衝擊。
- S1 服務分組部署,分為 Stable 和 Standalone 兩套環境
- 非核心服務呼叫 S1 服務流量路由到 Standalone 環境
- S1 服務呼叫非核心服務需配置熔斷策略
多種限流熔斷能力建設
我們建設的高可用平臺能力
部分限流效果圖
**
- 預熱圖示
- 排隊等待
- 預熱+排隊
高可用平臺圖示
**
- 中介軟體全部接入
- 動態配置實時生效
- 每個資源和 IP 節點詳細流量
總結
- 哪些是我們的關鍵指標,哪些是我們的次要指標,這是訊息治理的首要問題
- 哪些是我們的核心服務,哪些是我們的非核心服務,這是服務治理的首要問題
- 原始碼&實戰 是一種比較好的工作學習方法。