[[411727]]

背景

哈啰已進(jìn)化為包括兩輪出行(哈啰單車、哈啰助力車、哈啰電動(dòng)車、小哈換電)、四輪出行(哈啰順風(fēng)車、全網(wǎng)叫車、哈啰打車)等的綜合化移動(dòng)出行平臺(tái)，并向酒店、到店團(tuán)購(gòu)等眾多本地生活化生態(tài)探索。

隨著公司業(yè)務(wù)的不斷發(fā)展，流量也在不斷增長(zhǎng)。我們發(fā)現(xiàn)生產(chǎn)中的一些重大事故，往往是被突發(fā)的流量沖跨的，對(duì)流量的治理和防護(hù)，保障系統(tǒng)高可用就尤為重要。

本文就哈啰在消息流量和微服務(wù)調(diào)用的治理中踩過的坑、積累的經(jīng)驗(yàn)進(jìn)行分享。 

聊聊治理這件事

開始之前先聊聊治理這件事情，下面是老梁個(gè)人理解：

治理在干一件什么事?

• 讓我們的環(huán)境變得美好一些

需要知道哪些地方還不夠好?

• 以往經(jīng)驗(yàn)
• 用戶反饋
• 業(yè)內(nèi)對(duì)比

還需要知道是不是一直都是好的?

• 監(jiān)控跟蹤
• 告警通知

不好的時(shí)候如何再讓其變好?

• 治理措施
• 應(yīng)急方案

目錄

1. 打造分布式消息治理平臺(tái)
2. RocketMQ 實(shí)戰(zhàn)踩坑和解決
3. 打造微服務(wù)高可用治理平臺(tái)

背景

裸奔的 RabbitMQ

公司之前使用 RabbitMQ ，下面在使用 RabbitMQ 時(shí)的痛點(diǎn)，其中很多事故由于 RabbitMQ 集群限流引起的。

• 積壓過多是清理還是不清理?這是個(gè)問題，我再想想。
• 積壓過多觸發(fā)集群流控?那是真的影響業(yè)務(wù)了。
• 想消費(fèi)前兩天的數(shù)據(jù)?請(qǐng)您重發(fā)一遍吧。
• 要統(tǒng)計(jì)哪些服務(wù)接入了?您要多等等了，我得去撈IP看看。
• 有沒有使用風(fēng)險(xiǎn)比如大消息?這個(gè)我猜猜。

裸奔的服務(wù)

曾經(jīng)有這么一個(gè)故障，多個(gè)業(yè)務(wù)共用一個(gè)數(shù)據(jù)庫(kù)。在一次晚高峰流量陡增，把數(shù)據(jù)庫(kù)打掛了。

• 數(shù)據(jù)庫(kù)單機(jī)升級(jí)到最高配依然無法解決
• 重啟后緩一緩，不一會(huì)就又被打掛了
• 如此循環(huán)著、煎熬著、默默等待著高峰過去

思考：無論消息還是服務(wù)都需要完善的治理措施

打造分布式消息治理平臺(tái)

設(shè)計(jì)指南

哪些是我們的關(guān)鍵指標(biāo)，哪些是我們的次要指標(biāo)，這是消息治理的首要問題。

設(shè)計(jì)目標(biāo)

旨在屏蔽底層各個(gè)中間件( RocketMQ / Kafka )的復(fù)雜性，通過唯一標(biāo)識(shí)動(dòng)態(tài)路由消息。同時(shí)打造集資源管控、檢索、監(jiān)控、告警、巡檢、容災(zāi)、可視化運(yùn)維等一體化的消息治理平臺(tái)，保障消息中間件平穩(wěn)健康運(yùn)行。

消息治理平臺(tái)設(shè)計(jì)需要考慮的點(diǎn)

• 提供簡(jiǎn)單易用 API
• 有哪些關(guān)鍵點(diǎn)能衡量客戶端的使用沒有安全隱患
• 有哪些關(guān)鍵指標(biāo)能衡量集群健康不健康
• 有哪些常用的用戶/運(yùn)維操作將其可視化
• 有哪些措施應(yīng)對(duì)這些不健康

盡可能簡(jiǎn)單易用

設(shè)計(jì)指南

把復(fù)雜的問題搞簡(jiǎn)單，那是能耐。

極簡(jiǎn)統(tǒng)一 API

提供統(tǒng)一的 SDK 封裝了( Kafka / RocketMQ )兩種消息中間件。

一次申請(qǐng)

主題消費(fèi)組自動(dòng)創(chuàng)建不適合生產(chǎn)環(huán)境，自動(dòng)創(chuàng)建會(huì)導(dǎo)致失控，不利于整個(gè)生命周期管理和集群穩(wěn)定。需要對(duì)申請(qǐng)流程進(jìn)行控制，但是應(yīng)盡可能簡(jiǎn)單。例如：一次申請(qǐng)各個(gè)環(huán)境均生效、生成關(guān)聯(lián)告警規(guī)則等。

客戶端治理

設(shè)計(jì)指南

監(jiān)控客戶端使用是否規(guī)范，找到合適的措施治理

場(chǎng)景回放

• 場(chǎng)景一 瞬時(shí)流量與集群的流控

假設(shè)現(xiàn)在集群 Tps 有 1 萬，瞬時(shí)翻到 2 萬甚至更多，這種過度陡增的流量極有可能引發(fā)集群流控。針對(duì)這類場(chǎng)景需監(jiān)控客戶端的發(fā)送速度，在滿足速度和陡增幅度閾值后將發(fā)送變的平緩一些。

• 場(chǎng)景二 大消息與集群抖動(dòng)

當(dāng)客戶端發(fā)送大消息時(shí)，例如：發(fā)送幾百KB甚至幾兆的消息，可能造成 IO 時(shí)間過長(zhǎng)與集群抖動(dòng)。針對(duì)這類場(chǎng)景治理需監(jiān)控發(fā)送消息的大小，我們采取通過事后巡檢的方式識(shí)別出大消息的服務(wù)，推動(dòng)使用同學(xué)壓縮或重構(gòu)，消息控制在 10KB 以內(nèi)。

• 場(chǎng)景三 過低客戶端版本

隨著功能的迭代 SDK 的版本也會(huì)升級(jí)，變更除了功能外還有可能引入風(fēng)險(xiǎn)。當(dāng)使用過低的版本時(shí)一個(gè)是功能不能得到支持，另外一個(gè)是也可能存在安全隱患。為了解 SDK 使用情況，可以采取將 SDK 版本上報(bào)，通過巡檢的方式推動(dòng)使用同學(xué)升級(jí)。

• 場(chǎng)景四 消費(fèi)流量摘除和恢復(fù)

消費(fèi)流量摘除和恢復(fù)通常有以下使用場(chǎng)景，第一個(gè)是發(fā)布應(yīng)用時(shí)需要先摘流量，另外一個(gè)是問題定位時(shí)希望先把流量摘除掉再去排查。為了支持這種場(chǎng)景，需要在客戶端監(jiān)聽摘除/恢復(fù)事件，將消費(fèi)暫停和恢復(fù)。

• 場(chǎng)景五 發(fā)送/消費(fèi)耗時(shí)檢測(cè)

發(fā)送/消費(fèi)一條消息用了多久，通過監(jiān)控耗時(shí)情況，巡檢摸排出性能過低的應(yīng)用，針對(duì)性推動(dòng)改造達(dá)到提升性能的目的。

• 場(chǎng)景六 提升排查定位效率

在排查問題時(shí)，往往需要檢索發(fā)了什么消息、存在哪里、什么時(shí)候消費(fèi)的等消息生命周期相關(guān)的內(nèi)容。這部分可以通過 msgId 在消息內(nèi)部將生命周期串聯(lián)起來。另外是通過在消息頭部埋入 rpcId / traceId 類似鏈路標(biāo)識(shí)，在一次請(qǐng)求中將消息串起來。

治理措施提煉

需要的監(jiān)控信息

• 發(fā)送/消費(fèi)速度
• 發(fā)送/消費(fèi)耗時(shí)
• 消息大小
• 節(jié)點(diǎn)信息
• 鏈路標(biāo)識(shí)
• 版本信息

常用治理措施

• 定期巡檢：有了埋點(diǎn)信息可以通過巡檢將有風(fēng)險(xiǎn)的應(yīng)用找出來。例如發(fā)送/消費(fèi)耗時(shí)大于 800 ms、消息大小大于 10 KB、版本小于特定版本等。
• 發(fā)送平滑：例如檢測(cè)到瞬時(shí)流量滿足 1 萬而且陡增了 2 倍以上，可以通過預(yù)熱的方式將瞬時(shí)流量變的平滑一些。
• 消費(fèi)限流：當(dāng)?shù)谌浇涌谛枰蘖鲿r(shí)，可以對(duì)消費(fèi)的流量進(jìn)行限流，這部分可以結(jié)合高可用框架實(shí)現(xiàn)。
• 消費(fèi)摘除：通過監(jiān)聽摘除事件將消費(fèi)客戶端關(guān)閉和恢復(fù)。

主題/消費(fèi)組治理

設(shè)計(jì)指南

監(jiān)控主題消費(fèi)組資源使用情況

場(chǎng)景回放

• 場(chǎng)景一 消費(fèi)積壓對(duì)業(yè)務(wù)的影響

有些業(yè)務(wù)場(chǎng)景對(duì)消費(fèi)堆積很敏感，有些業(yè)務(wù)對(duì)積壓不敏感，只要后面追上來消費(fèi)掉即可。例如單車開鎖是秒級(jí)的事情，而信息匯總相關(guān)的批處理場(chǎng)景對(duì)積壓不敏感。通過采集消費(fèi)積壓指標(biāo)，對(duì)滿足閾值的應(yīng)用采取實(shí)時(shí)告警的方式通知到應(yīng)用負(fù)責(zé)的同學(xué)，讓他們實(shí)時(shí)掌握消費(fèi)情況。

• 場(chǎng)景二 消費(fèi)/發(fā)送速度的影響

發(fā)送/消費(fèi)速度跌零告警?有些場(chǎng)景速度不能跌零，如果跌零意味著業(yè)務(wù)出現(xiàn)異常。通過采集速度指標(biāo)，對(duì)滿足閾值的應(yīng)用實(shí)時(shí)告警。

• 場(chǎng)景三 消費(fèi)節(jié)點(diǎn)掉線

消費(fèi)節(jié)點(diǎn)掉線需要通知給應(yīng)用負(fù)責(zé)的同學(xué)，這類需要采集注冊(cè)節(jié)點(diǎn)信息，當(dāng)?shù)艟€時(shí)能實(shí)時(shí)觸發(fā)告警通知。

• 場(chǎng)景四 發(fā)送/消費(fèi)不均衡

發(fā)送/消費(fèi)的不均衡往往影響其性能。記得有一次咨詢時(shí)有同學(xué)將發(fā)送消息的key設(shè)置成常量，默認(rèn)按照 key 進(jìn)行 hash 選擇分區(qū)，所有的消息進(jìn)入了一個(gè)分區(qū)里，這個(gè)性能是無論如何也上不來的。另外還要檢測(cè)各個(gè)分區(qū)的消費(fèi)積壓情況，出現(xiàn)過度不均衡時(shí)觸發(fā)實(shí)時(shí)告警通知。

治理措施提煉

需要的監(jiān)控信息

• 發(fā)送/消費(fèi)速度
• 發(fā)送分區(qū)詳情
• 消費(fèi)各分區(qū)積壓
• 消費(fèi)組積壓
• 注冊(cè)節(jié)點(diǎn)信息

常用治理措施

• 實(shí)時(shí)告警：對(duì)消費(fèi)積壓、發(fā)送/消費(fèi)速度、節(jié)點(diǎn)掉線、分區(qū)不均衡進(jìn)行實(shí)時(shí)告警通知。
• 提升性能：對(duì)于有消費(fèi)積壓不能滿足需求，可以通過增加拉取線程、消費(fèi)線程、增加分區(qū)數(shù)量等措施加以提升。
• 自助排查：提供多維度檢索工具，例如通過時(shí)間范圍、msgId 檢索、鏈路系統(tǒng)等多維度檢索消息生命周期。

集群健康治理

設(shè)計(jì)指南

度量集群健康的核心指標(biāo)有哪些?

場(chǎng)景回放

• 場(chǎng)景一 集群健康檢測(cè)

集群健康檢測(cè)回答一個(gè)問題：這個(gè)集群是不是好的。通過檢測(cè)集群節(jié)點(diǎn)數(shù)量、集群中每個(gè)節(jié)點(diǎn)心跳、集群寫入Tps水位、集群消費(fèi)Tps水位都是在解決這個(gè)問題。

• 場(chǎng)景二 集群的穩(wěn)定性

集群流控往往體現(xiàn)出集群性能的不足，集群抖動(dòng)也會(huì)引發(fā)客戶端發(fā)送超時(shí)。通過采集集群中每個(gè)節(jié)點(diǎn)心跳耗時(shí)情況、集群寫入Tps水位的變化率來掌握集群是否穩(wěn)定。

• 場(chǎng)景三 集群的高可用

高可用主要針對(duì)極端場(chǎng)景中導(dǎo)致某個(gè)可用區(qū)不可用、或者集群上某些主題和消費(fèi)組異常需要有一些針對(duì)性的措施。例如：MQ 可以通過同城跨可用區(qū)主從交叉部署、動(dòng)態(tài)將主題和消費(fèi)組遷移到災(zāi)備集群、多活等方式進(jìn)行解決。

治理措施提煉

需要的監(jiān)控信息

• 集群節(jié)點(diǎn)數(shù)量采集
• 集群節(jié)點(diǎn)心跳耗時(shí)
• 集群寫入 Tps 的水位
• 集群消費(fèi) Tps 的水位
• 集群寫入 Tps 的變化率

常用治理措施

• 定期巡檢：對(duì)集群 Tps 水位、硬件水位定期巡檢。
• 容災(zāi)措施：同城跨可用區(qū)主從交叉部署、容災(zāi)動(dòng)態(tài)遷移到災(zāi)備集群、異地多活。
• 集群調(diào)優(yōu)：系統(tǒng)版本/參數(shù)、集群參數(shù)調(diào)優(yōu)。
• 集群分類：按業(yè)務(wù)線分類、按核心/非核心服務(wù)分類。

最核心指標(biāo)聚焦

如果說這些關(guān)鍵指標(biāo)中哪一個(gè)最重要?我會(huì)選擇集群中每個(gè)節(jié)點(diǎn)的心跳檢測(cè)，即：響應(yīng)時(shí)間( RT )，下面看看影響 RT 可能是哪些原因。

關(guān)于告警

• 監(jiān)控指標(biāo)大多是秒級(jí)探測(cè)
• 觸發(fā)閾值的告警推送到公司統(tǒng)一告警系統(tǒng)、實(shí)時(shí)通知
• 巡檢的風(fēng)險(xiǎn)通知推送到公司巡檢系統(tǒng)、每周匯總通知

消息平臺(tái)圖示

架構(gòu)圖

看板圖示

• 多維度：集群維度、應(yīng)用維度
• 全聚合：關(guān)鍵指標(biāo)全聚合

RocketMQ 實(shí)戰(zhàn)中踩過的坑和解決方案

行動(dòng)指南

我們總會(huì)遇到坑，遇到就把它填了。

1. RocketMQ 集群 CPU 毛刺

問題描述

RocketMQ 從節(jié)點(diǎn)、主節(jié)點(diǎn)頻繁 CPU 飆高，很明顯的毛刺，很多次從節(jié)點(diǎn)直接掛掉了。

只有系統(tǒng)日志有錯(cuò)誤提示

2020-03-16T17:56:07.505715+08:00 VECS0xxxx kernel:[] ? __alloc_pages_nodemask+0x7e1/0x960 
2020-03-16T17:56:07.505717+08:00 VECS0xxxx kernel: java: page allocation failure. order:0, mode:0x20 
2020-03-16T17:56:07.505719+08:00 VECS0xxxx kernel: Pid: 12845, comm: java Not tainted 2.6.32-754.17.1.el6.x86_64 #1 
2020-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/0x960 
2020-03-16T17:56:07.505726+08:00 VECS0xxxx kernel: [] ? dev_queue_xmit+0xd0/0x360 
2020-03-16T17:56:07.505729+08:00 VECS0xxxx kernel: [] ? ip_finish_output+0x192/0x380 
2020-03-16T17:56:07.505732+08:00 VECS0xxxx kernel: [] ? 

各種調(diào)試系統(tǒng)參數(shù)只能減緩但是不能根除，依然毛刺超過 50%

解決方案

將集群所有系統(tǒng)升級(jí)從 centos 6 升級(jí)到 centos 7 ，內(nèi)核版本也從從 2.6 升級(jí)到 3.10 ，CPU 毛刺消失。

2. RocketMQ 集群線上延遲消息失效

問題描述

RocketMQ 社區(qū)版默認(rèn)本支持 18 個(gè)延遲級(jí)別，每個(gè)級(jí)別在設(shè)定的時(shí)間都被會(huì)消費(fèi)者準(zhǔn)確消費(fèi)到。為此也專門測(cè)試過消費(fèi)的間隔是不是準(zhǔn)確，測(cè)試結(jié)果顯示很準(zhǔn)確。然而，如此準(zhǔn)確的特性居然出問題了，接到業(yè)務(wù)同學(xué)報(bào)告線上某個(gè)集群延遲消息消費(fèi)不到，詭異!

解決方案

將" delayOffset.json "和" consumequeue / SCHEDULE_TOPIC_XXXX "移到其他目錄，相當(dāng)于刪除;逐臺(tái)重啟 broker 節(jié)點(diǎn)。重啟結(jié)束后，經(jīng)過驗(yàn)證，延遲消息功能正常發(fā)送和消費(fèi)。

打造微服務(wù)高可用治理平臺(tái)

設(shè)計(jì)指南

哪些是我們的核心服務(wù)，哪些是我們的非核心服務(wù)，這是服務(wù)治理的首要問題

設(shè)計(jì)目標(biāo)

服務(wù)能應(yīng)對(duì)突如其來的陡增流量，尤其保障核心服務(wù)的平穩(wěn)運(yùn)行。

應(yīng)用分級(jí)和分組部署

應(yīng)用分級(jí)

根據(jù)用戶和業(yè)務(wù)影響兩個(gè)緯度來進(jìn)行評(píng)估設(shè)定的，將應(yīng)用分成了四個(gè)等級(jí)。

• 業(yè)務(wù)影響：應(yīng)用故障時(shí)影響的業(yè)務(wù)范圍
• 用戶影響：應(yīng)用故障時(shí)影響的用戶數(shù)量

S1：核心產(chǎn)品，產(chǎn)生故障會(huì)引起外部用戶無法使用或造成較大資損，比如主營(yíng)業(yè)務(wù)核心鏈路，如單車、助力車開關(guān)鎖、順風(fēng)車的發(fā)單和接單核心鏈路，以及其核心鏈路強(qiáng)依賴的應(yīng)用。

S2: 不直接影響交易，但關(guān)系到前臺(tái)業(yè)務(wù)重要配置的管理與維護(hù)或業(yè)務(wù)后臺(tái)處理的功能。

S3: 服務(wù)故障對(duì)用戶或核心產(chǎn)品邏輯影響非常小，且對(duì)主要業(yè)務(wù)沒影響，或量較小的新業(yè)務(wù);面向內(nèi)部用戶使用的重要工具，不直接影響業(yè)務(wù)，但相關(guān)管理功能對(duì)前臺(tái)業(yè)務(wù)影響也較小。

S4: 面向內(nèi)部用戶使用，不直接影響業(yè)務(wù)，或后續(xù)需要推動(dòng)下線的系統(tǒng)。

分組部署

S1 服務(wù)是公司的核心服務(wù)，是重點(diǎn)保障的對(duì)象，需保障其不被非核心服務(wù)流量意外沖擊。

• S1 服務(wù)分組部署，分為 Stable 和 Standalone 兩套環(huán)境
• 非核心服務(wù)調(diào)用 S1 服務(wù)流量路由到 Standalone 環(huán)境
• S1 服務(wù)調(diào)用非核心服務(wù)需配置熔斷策略

 

多種限流熔斷能力建設(shè)

我們建設(shè)的高可用平臺(tái)能力

部分限流效果圖

• 預(yù)熱圖示

 

• 排隊(duì)等待

 

• 預(yù)熱+排隊(duì)

• 高可用平臺(tái)圖示
• 中間件全部接入
• 動(dòng)態(tài)配置實(shí)時(shí)生效

每個(gè)資源和 IP 節(jié)點(diǎn)詳細(xì)流量

總結(jié)

• 哪些是我們的關(guān)鍵指標(biāo)，哪些是我們的次要指標(biāo)，這是消息治理的首要問題
• 哪些是我們的核心服務(wù)，哪些是我們的非核心服務(wù)，這是服務(wù)治理的首要問題
• 源碼&實(shí)戰(zhàn) 是一種比較好的工作學(xué)習(xí)方法。

作者介紹

梁勇 ( 老梁 ) ，《 RocketMQ 實(shí)戰(zhàn)與進(jìn)階》專欄聯(lián)合作者、參與了《 RocketMQ 技術(shù)內(nèi)幕》審稿工作。ArchSummit 全球架構(gòu)師大會(huì)講師、QCon 案例研習(xí)社講師。