RocketMQ 千錘百煉--哈啰在分布式消息治理和微服務(wù)

 # 作者｜梁勇 ? # 背景 ? 哈啰已進(jìn)化為包括兩輪出行（哈啰單車(chē)、哈啰助力車(chē)、哈啰電動(dòng)車(chē)、小哈換電）、四輪出行（哈啰順風(fēng)車(chē)、全網(wǎng)叫車(chē)、哈啰打車(chē)）等的綜合化移動(dòng)出行平臺，并向酒店、到店團購等眾多本地生活化生態(tài)探索。 ? 隨著(zhù)公司業(yè)務(wù)的不斷發(fā)展，流量也在不斷增長(cháng)。我們發(fā)現生產(chǎn)中的一些重大事故，往往是被突發(fā)的流量沖跨的，對流量的治理和防護，保障系統高可用就尤為重要。 ? 本文就哈啰在消息流量和微服務(wù)調用的治理中踩過(guò)的坑、積累的經(jīng)驗進(jìn)行分享。 ? # 作者介紹 ? 梁勇 ( 老梁 ) ，《 RocketMQ 實(shí)戰與進(jìn)階》專(zhuān)欄聯(lián)合作者、參與了《 RocketMQ 技術(shù)內幕》審稿工作。ArchSummit 全球架構師大會(huì )講師、QCon 案例研習社講師。 當前主要在后端中間件方向，在公眾號【瓜農老梁】已陸續發(fā)表百余篇源碼實(shí)戰類(lèi)文章，涵蓋 RocketMQ 系列、Kafka 系列、GRPC 系列、Nacosl 系列、Sentinel 系列、Java NIO 系列。目前就職于哈啰出行，任職高級技術(shù)專(zhuān)家。 ? # 聊聊治理這件事 ? 開(kāi)始之前先聊聊治理這件事情，下面是老梁個(gè)人理解： ? ### **治理在干一件什么事？** **?** - 讓我們的環(huán)境變得美好一些 ### ? ### **需要知道哪些地方還不夠好？** ? - 以往經(jīng)驗 - 用戶(hù)反饋 - 業(yè)內對比 ### ? ### **還需要知道是不是一直都是好的？** ? - 監控跟蹤 - 告警通知 ### ? ### **不好的時(shí)候如何再讓其變好？** ? - 治理措施 - 應急方案 ### ? ### **目錄** ? 1. 打造分布式消息治理平臺 1. RocketMQ 實(shí)戰踩坑和解決 1. 打造微服務(wù)高可用治理平臺 ### **背景** ? #### 裸奔的 RabbitMQ ? 公司之前使用 RabbitMQ ，下面在使用 RabbitMQ 時(shí)的痛點(diǎn)，其中很多事故由于 RabbitMQ 集群限流引起的。 ? - 積壓過(guò)多是清理還是不清理？這是個(gè)問(wèn)題，我再想想。 - 積壓過(guò)多觸發(fā)集群流控？那是真的影響業(yè)務(wù)了。 - 想消費前兩天的<a href='http://wap.friendlycc.com.cn/database/mysql/' target='_blank'><u>數據</u></a>？請您重發(fā)一遍吧。 - 要統計哪些服務(wù)接入了？您要多等等了，我得去撈IP看看。 - 有沒(méi)有使用風(fēng)險比如大消息？這個(gè)我猜猜。 #### 裸奔的服務(wù) 曾經(jīng)有這么一個(gè)故障，多個(gè)業(yè)務(wù)共用一個(gè)<a href='http://wap.friendlycc.com.cn/database/mysql/' target='_blank'><u>數據庫</u></a>。在一次晚高峰流量陡增，把數據庫打掛了。 - 數據庫單機升級到最高配依然無(wú)法解決 - 重啟后緩一緩，不一會(huì )就又被打掛了 - 如此循環(huán)著(zhù)、煎熬著(zhù)、默默等待著(zhù)高峰過(guò)去 **思考：無(wú)論消息還是服務(wù)都需要完善的治理措施** ? # 打造分布式消息治理平臺 ? #### 設計指南 ? 哪些是我們的關(guān)鍵指標，哪些是我們的次要指標，這是消息治理的首要問(wèn)題。 #### 設計目標 ? 旨在屏蔽底層各個(gè)中間件（ RocketMQ / Kafka ）的復雜性，通過(guò)唯一標識動(dòng)態(tài)路由消息。同時(shí)打造集資源管控、檢索、監控、告警、巡檢、容災、可視化運維等一體化的消息治理平臺，保障消息中間件平穩健康運行。 ? #### 消息治理平臺設計需要考慮的點(diǎn) ? - 提供簡(jiǎn)單易用 API - 有哪些關(guān)鍵點(diǎn)能衡量客戶(hù)端的使用沒(méi)有<a href='http://wap.friendlycc.com.cn/website/' target='_blank'><u><a href='http://wap.friendlycc.com.cn/firewall/' target='_blank'><u>安全</u></a>隱患</u></a> - 有哪些關(guān)鍵指標能衡量集群健康不健康 - 有哪些常用的用戶(hù)/運維操作將其可視化 - 有哪些措施應對這些不健康 # ? ## 盡可能簡(jiǎn)單易用 ? #### 設計指南 ? 把復雜的問(wèn)題搞簡(jiǎn)單，那是能耐。 #### 極簡(jiǎn)統一 API ? 提供統一的 SDK 封裝了（ Kafka / RocketMQ ）兩種消息中間件。 ?  #### 一次申請 ? 主題消費組自動(dòng)創(chuàng )建不適合生產(chǎn)環(huán)境，自動(dòng)創(chuàng )建會(huì )導致失控，不利于整個(gè)生命周期管理和集群穩定。需要對申請流程進(jìn)行控制，但是應盡可能簡(jiǎn)單。例如：一次申請各個(gè)環(huán)境均生效、生成關(guān)聯(lián)告警規則等。 ?  ## 客戶(hù)端治理 #### 設計指南 監控客戶(hù)端使用是否規范，找到合適的措施治理 #### 場(chǎng)景回放 場(chǎng)景一 瞬時(shí)流量與集群的流控 假設現在集群 Tps 有 1 萬(wàn)，瞬時(shí)翻到 2 萬(wàn)甚至更多，這種過(guò)度陡增的流量極有可能引發(fā)集群流控。針對這類(lèi)場(chǎng)景需監控客戶(hù)端的發(fā)送速度，在滿(mǎn)足速度和陡增幅度閾值后將發(fā)送變的平緩一些。 場(chǎng)景二 大消息與集群抖動(dòng) 當客戶(hù)端發(fā)送大消息時(shí)，例如：發(fā)送幾百KB甚至幾兆的消息，可能造成 IO 時(shí)間過(guò)長(cháng)與集群抖動(dòng)。針對這類(lèi)場(chǎng)景治理需監控發(fā)送消息的大小，我們采取通過(guò)事后巡檢的方式識別出大消息的服務(wù)，推動(dòng)使用同學(xué)壓縮或重構，消息控制在 10KB 以?xún)取? 場(chǎng)景三 過(guò)低客戶(hù)端版本 隨著(zhù)功能的迭代 SDK 的版本也會(huì )升級，變更除了功能外還有可能引入風(fēng)險。當使用過(guò)低的版本時(shí)一個(gè)是功能不能得到支持，另外一個(gè)是也可能存在安全隱患。為了解 SDK 使用情況，可以采取將 SDK 版本上報，通過(guò)巡檢的方式推動(dòng)使用同學(xué)升級。 場(chǎng)景四 消費流量摘除和恢復 消費流量摘除和恢復通常有以下使用場(chǎng)景，第一個(gè)是發(fā)布應用時(shí)需要先摘流量，另外一個(gè)是問(wèn)題定位時(shí)希望先把流量摘除掉再去排查。為了支持這種場(chǎng)景，需要在客戶(hù)端監聽(tīng)摘除/恢復事件，將消費暫停和恢復。 場(chǎng)景五 發(fā)送/消費耗時(shí)檢測 發(fā)送/消費一條消息用了多久，通過(guò)監控耗時(shí)情況，巡檢摸排出性能過(guò)低的應用，針對性推動(dòng)改造達到提升性能的目的。 場(chǎng)景六 提升排查定位效率 在排查問(wèn)題時(shí)，往往需要檢索發(fā)了什么消息、存在哪里、什么時(shí)候消費的等消息生命周期相關(guān)的內容。這部分可以通過(guò) msgId 在消息內部將生命周期串聯(lián)起來(lái)。另外是通過(guò)在消息頭部埋入 rpcId / traceId 類(lèi)似鏈路標識，在一次請求中將消息串起來(lái)。 ### **治理措施提煉** 需要的監控信息 - 發(fā)送/消費速度 - 發(fā)送/消費耗時(shí) - 消息大小 - 節點(diǎn)信息 - 鏈路標識 - 版本信息 常用治理措施 - 定期巡檢：有了埋點(diǎn)信息可以通過(guò)巡檢將有風(fēng)險的應用找出來(lái)。例如發(fā)送/消費耗時(shí)大于 800 ms、消息大小大于 10 KB、版本小于特定版本等。 - 發(fā)送平滑：例如檢測到瞬時(shí)流量滿(mǎn)足 1 萬(wàn)而且陡增了 2 倍以上，可以通過(guò)預熱的方式將瞬時(shí)流量變的平滑一些。 - 消費限流：當第三方接口需要限流時(shí)，可以對消費的流量進(jìn)行限流，這部分可以結合高可用框架實(shí)現。 - 消費摘除：通過(guò)監聽(tīng)摘除事件將消費客戶(hù)端關(guān)閉和恢復。 ## 主題/消費組治理 ? #### 設計指南 ? 監控主題消費組資源使用情況 ? #### 場(chǎng)景回放 ? 場(chǎng)景一 消費積壓對業(yè)務(wù)的影響 ? 有些業(yè)務(wù)場(chǎng)景對消費堆積很敏感，有些業(yè)務(wù)對積壓不敏感，只要后面追上來(lái)消費掉即可。例如單車(chē)開(kāi)鎖是秒級的事情，而信息匯總相關(guān)的批處理場(chǎng)景對積壓不敏感。通過(guò)采集消費積壓指標，對滿(mǎn)足閾值的應用采取實(shí)時(shí)告警的方式通知到應用負責的同學(xué)，讓他們實(shí)時(shí)掌握消費情況。 ? 場(chǎng)景二 消費/發(fā)送速度的影響 ? 發(fā)送/消費速度跌零告警？有些場(chǎng)景速度不能跌零，如果跌零意味著(zhù)業(yè)務(wù)出現異常。通過(guò)采集速度指標，對滿(mǎn)足閾值的應用實(shí)時(shí)告警。 ? 場(chǎng)景三 消費節點(diǎn)掉線(xiàn) ? 消費節點(diǎn)掉線(xiàn)需要通知給應用負責的同學(xué)，這類(lèi)需要采集注冊節點(diǎn)信息，當掉線(xiàn)時(shí)能實(shí)時(shí)觸發(fā)告警通知。 ? 場(chǎng)景四 發(fā)送/消費不均衡 ? 發(fā)送/消費的不均衡往往影響其性能。記得有一次咨詢(xún)時(shí)有同學(xué)將發(fā)送消息的key設置成常量，默認按照 key 進(jìn)行 hash 選擇分區，所有的消息進(jìn)入了一個(gè)分區里，這個(gè)性能是無(wú)論如何也上不來(lái)的。另外還要檢測各個(gè)分區的消費積壓情況，出現過(guò)度不均衡時(shí)觸發(fā)實(shí)時(shí)告警通知。 ? ### **治理措施提煉** ? 需要的監控信息 ? - 發(fā)送/消費速度 - 發(fā)送分區詳情 - 消費各分區積壓 - 消費組積壓 - 注冊節點(diǎn)信息 常用治理措施 ? - 實(shí)時(shí)告警：對消費積壓、發(fā)送/消費速度、節點(diǎn)掉線(xiàn)、分區不均衡進(jìn)行實(shí)時(shí)告警通知。 - 提升性能：對于有消費積壓不能滿(mǎn)足需求，可以通過(guò)增加拉取線(xiàn)程、消費線(xiàn)程、增加分區數量等措施加以提升。 - 自助排查：提供多維度檢索工具，例如通過(guò)時(shí)間范圍、msgId 檢索、鏈路系統等多維度檢索消息生命周期。 ? ## 集群健康治理 ? #### 設計指南 ? 度量集群健康的核心指標有哪些？ ? #### 場(chǎng)景回放 場(chǎng)景一 集群健康檢測 ? 集群健康檢測回答一個(gè)問(wèn)題：這個(gè)集群是不是好的。通過(guò)檢測集群節點(diǎn)數量、集群中每個(gè)節點(diǎn)心跳、集群寫(xiě)入Tps水位、集群消費Tps水位都是在解決這個(gè)問(wèn)題。 ? 場(chǎng)景二 集群的穩定性 ? 集群流控往往體現出集群性能的不足，集群抖動(dòng)也會(huì )引發(fā)客戶(hù)端發(fā)送超時(shí)。通過(guò)采集集群中每個(gè)節點(diǎn)心跳耗時(shí)情況、集群寫(xiě)入Tps水位的變化率來(lái)掌握集群是否穩定。 ? 場(chǎng)景三 集群的高可用 ? 高可用主要針對極端場(chǎng)景中導致某個(gè)可用區不可用、或者集群上某些主題和消費組異常需要有一些針對性的措施。例如：MQ 可以通過(guò)同城跨可用區主從交叉部署、動(dòng)態(tài)將主題和消費組遷移到災備集群、多活等方式進(jìn)行解決。 ? ### **治理措施提煉** ? 需要的監控信息 ? - 集群節點(diǎn)數量采集 - 集群節點(diǎn)心跳耗時(shí) - 集群寫(xiě)入 Tps 的水位 - 集群消費 Tps 的水位 - 集群寫(xiě)入 Tps 的變化率 常用治理措施 ? - 定期巡檢：對集群 Tps 水位、硬件水位定期巡檢。 - 容災措施：同城跨可用區主從交叉部署、容災動(dòng)態(tài)遷移到災備集群、異地多活。 - 集群調優(yōu)：系統版本/參數、集群參數調優(yōu)。 - 集群分類(lèi)：按業(yè)務(wù)線(xiàn)分類(lèi)、按核心/非核心服務(wù)分類(lèi)。 ### **最核心指標聚焦** ? 如果說(shuō)這些關(guān)鍵指標中哪一個(gè)最重要？我會(huì )選擇集群中每個(gè)節點(diǎn)的心跳檢測，即：響應時(shí)間（ RT ），下面看看影響 RT 可能哪些原因。  ### 關(guān)于告警 ? - 監控指標大多是秒級探測 - 觸發(fā)閾值的告警推送到公司統一告警系統、實(shí)時(shí)通知 - 巡檢的風(fēng)險通知推送到公司巡檢系統、每周匯總通知 ### 消息平臺圖示 ? ### **架構圖** ?  ### **看板圖示** ? - 多維度：集群維度、應用維度 - 全聚合：關(guān)鍵指標全聚合   # RocketMQ 實(shí)戰中踩過(guò)的坑和解決方案 ? ### 行動(dòng)指南 ? 我們總會(huì )遇到坑，遇到就把它填了。 ? ### 1. RocketMQ 集群 CPU 毛刺 ? #### 問(wèn)題描述 ** RocketMQ 從節點(diǎn)、主節點(diǎn)頻繁 CPU 飆高，很明顯的毛刺，很多次從節點(diǎn)直接掛掉了。  只有系統日志有錯誤提示 ``` ```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: [] ? ``` ``` 各種調試系統參數只能減緩但是不能根除，依然毛刺超過(guò) 50%  #### 解決方案 **?** 將集群所有系統升級從 centos 6 升級到 centos 7 ，內核版本也從從 2.6 升級到 3.10 ，CPU 毛刺消失。 ? ### 2. RocketMQ 集群線(xiàn)上延遲消息失效 ? ### 問(wèn)題描述 RocketMQ 社區版默認本支持 18 個(gè)延遲級別，每個(gè)級別在設定的時(shí)間都被會(huì )消費者準確消費到。為此也專(zhuān)門(mén)測試過(guò)消費的間隔是不是準確，測試結果顯示很準確。然而，如此準確的特性居然出問(wèn)題了，接到業(yè)務(wù)同學(xué)報告線(xiàn)上某個(gè)集群延遲消息消費不到，詭異！ ? ### 解決方案 **?** 將" delayOffset.json "和" consumequeue / SCHEDULE_TOPIC_XXXX "移到其他目錄，相當于刪除；逐臺重啟 broker 節點(diǎn)。重啟結束后，經(jīng)過(guò)驗證，延遲消息功能正常發(fā)送和消費。 ? # 打造微服務(wù)高可用治理平臺 ? ### 設計指南 哪些是我們的核心服務(wù)，哪些是我們的非核心服務(wù)，這是服務(wù)治理的首要問(wèn)題 ? ### 設計目標 **?** 服務(wù)能應對突如其來(lái)的陡增流量，尤其保障核心服務(wù)的平穩運行。 ? ### 應用分級和分組部署 ? ### **應用分級** ? 根據用戶(hù)和業(yè)務(wù)影響兩個(gè)緯度來(lái)進(jìn)行評估設定的，將應用分成了四個(gè)等級。 ? - 業(yè)務(wù)影響：應用故障時(shí)影響的業(yè)務(wù)范圍 - 用戶(hù)影響：應用故障時(shí)影響的用戶(hù)數量 S1：核心產(chǎn)品，產(chǎn)生故障會(huì )引起外部用戶(hù)無(wú)法使用或造成較大資損，比如主營(yíng)業(yè)務(wù)核心鏈路，如單車(chē)、助力車(chē)開(kāi)關(guān)鎖、順風(fēng)車(chē)的發(fā)單和接單核心鏈路，以及其核心鏈路強依賴(lài)的應用。 ? S2: 不直接影響交易，但關(guān)系到前臺業(yè)務(wù)重要配置的管理與維護或業(yè)務(wù)后臺處理的功能。 ? S3: 服務(wù)故障對用戶(hù)或核心產(chǎn)品邏輯影響非常小，且對主要業(yè)務(wù)沒(méi)影響，或量較小的新業(yè)務(wù)；面向內部用戶(hù)使用的重要工具，不直接影響業(yè)務(wù)，但相關(guān)管理功能對前臺業(yè)務(wù)影響也較小。 ? S4: 面向內部用戶(hù)使用，不直接影響業(yè)務(wù)，或后續需要推動(dòng)下線(xiàn)的系統。 ? ### **分組部署** **?** S1 服務(wù)是公司的核心服務(wù)，是重點(diǎn)保障的對象，需保障其不被非核心服務(wù)流量意外沖擊。 ? - S1 服務(wù)分組部署，分為 Stable 和 Standalone 兩套環(huán)境 - 非核心服務(wù)調用 S1 服務(wù)流量路由到 Standalone 環(huán)境 - S1 服務(wù)調用非核心服務(wù)需配置熔斷策略  ### 多種限流熔斷能力建設 ? ### **我們建設的高可用平臺能力**  ### **部分限流效果圖** ** - 預熱圖示  - 排隊等待  - 預熱+排隊  ### **高可用平臺圖示** ** - 中間件全部接入 - 動(dòng)態(tài)配置實(shí)時(shí)生效 - 每個(gè)資源和 IP 節點(diǎn)詳細流量  ### 總結 ? - 哪些是我們的關(guān)鍵指標，哪些是我們的次要指標，這是消息治理的首要問(wèn)題 - 哪些是我們的核心服務(wù)，哪些是我們的非核心服務(wù)，這是服務(wù)治理的首要問(wèn)題 - 源碼&實(shí)戰 是一種比較好的工作學(xué)習方法。