哈啰在分布式消息治理和微服務(wù)治理中的實(shí)踐

背景介紹

哈啰已進(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)用和通過(guò)消息隊(duì)列解耦的異步調(diào)用。他們都可以歸為流量調(diào)用范疇，本文為就哈啰在消息流量和微服務(wù)調(diào)用的治理中踩過(guò)的坑、積累的經(jīng)驗(yàn)一個(gè)分享。

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

治理在干一件什么事？

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

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

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

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

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

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

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

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

裸奔的RabbitMQ

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

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

裸奔的服務(wù)

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

• 數(shù)據(jù)庫(kù)單機(jī)升級(jí)到最高配依然無(wú)法解決

• 重啟后緩一緩，不一會(huì)就又被打掛了

• 如此循環(huán)著、煎熬著、默默等待著高峰過(guò)去

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

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

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

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

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

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

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

把復(fù)雜的問(wèn)題搞簡(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萬(wàn)，瞬時(shí)翻到2萬(wàn)甚至更多，這種過(guò)度陡增的流量極有可能引發(fā)集群流控。針對(duì)這類場(chǎng)景需監(jiān)控客戶端的發(fā)送速度，在滿足速度和陡增幅度閾值后將發(fā)送變的平緩一些。

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

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

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

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

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

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

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

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

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

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

治理措施提煉

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

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

常用治理措施

• 定期巡檢：有了埋點(diǎn)信息可以通過(guò)巡檢將有風(fēng)險(xiǎn)的應(yīng)用找出來(lái)。例如發(fā)送/消費(fèi)耗時(shí)大于800ms、消息大小大于10KB、版本小于特定版本等
• 發(fā)送平滑：例如檢測(cè)到瞬時(shí)流量滿足1萬(wàn)而且陡增了2倍以上，可以通過(guò)預(yù)熱的方式將瞬時(shí)流量變的平滑一些
• 消費(fèi)限流：當(dāng)?shù)谌浇涌谛枰蘖鲿r(shí)，可以對(duì)消費(fèi)的流量進(jìn)行限流，這部分可以結(jié)合高可用框架實(shí)現(xiàn)
• 消費(fèi)摘除：通過(guò)監(jiān)聽(tīng)摘除事件將消費(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ì)積壓不敏感，只要后面追上來(lái)消費(fèi)掉即可。例如單車開(kāi)鎖是秒級(jí)的事情，而信息匯總相關(guān)的批處理場(chǎng)景對(duì)積壓不敏感。通過(guò)采集消費(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)異常。通過(guò)采集速度指標(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è)性能是無(wú)論如何也上不來(lái)的。另外還要檢測(cè)各個(gè)分區(qū)的消費(fèi)積壓情況，出現(xiàn)過(guò)度不均衡時(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)積壓不能滿足需求，可以通過(guò)增加拉取線程、消費(fèi)線程、增加分區(qū)數(shù)量等措施加以提升
• 自助排查：提供多維度檢索工具，例如通過(guò)時(shí)間范圍、msgId檢索、鏈路系統(tǒng)等多維度檢索消息生命周期

集群健康治理

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

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

場(chǎng)景回放

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

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

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

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

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

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

治理措施提煉

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

• 集群節(jié)點(diǎn)數(shù)量采集
• 集群節(jié)點(diǎn)心跳耗時(shí)
• 集群寫(xiě)入Tps的水位
• 集群消費(fèi)Tps的水位
• 集群寫(xiě)入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ù)分類

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

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

架構(gòu)圖

看板圖示

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

行動(dòng)指南

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

RocketMQ集群CPU毛刺

問(wèn)題描述

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

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

2020-03-16T17:56:07.505715+08:00?VECS0xxxx?kernel:?<IRQ>??[<ffffffff81143c31>]???__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:?<IRQ>??[<ffffffff81143c31>]???__alloc_pages_nodemask+0x7e1/0x960
2020-03-16T17:56:07.505726+08:00?VECS0xxxx?kernel:?[<ffffffff8148e700>]???dev_queue_xmit+0xd0/0x360
2020-03-16T17:56:07.505729+08:00?VECS0xxxx?kernel:?[<ffffffff814cb3e2>]???ip_finish_output+0x192/0x380
2020-03-16T17:56:07.505732+08:00?VECS0xxxx?kernel:?[<ffffffff811862e2>]???

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

解決方案

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

備注

詳見(jiàn)RocketMQ社區(qū)帖子

RocketMQ集群線上延遲消息失效

問(wèn)題描述

RocketMQ社區(qū)版默認(rèn)本支持18個(gè)延遲級(jí)別，每個(gè)級(jí)別在設(shè)定的時(shí)間都被會(huì)消費(fèi)者準(zhǔn)確消費(fèi)到。為此也專門(mén)測(cè)試過(guò)消費(fèi)的間隔是不是準(zhǔn)確，測(cè)試結(jié)果顯示很準(zhǔn)確。然而，如此準(zhǔn)確的特性居然出問(wè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)過(guò)驗(yàn)證，延遲消息功能正常發(fā)送和消費(fèi)。

備注

詳見(jiàn)RocketMQ社區(qū)帖子?

詳細(xì)復(fù)盤(pán)過(guò)程

閱讀源碼有啥用？老梁的理解

• 遇到問(wèn)題不慌

• 解決問(wèn)題有思路

• 能夠鏈接到一些專業(yè)同學(xué)一起探討

• 為技術(shù)方案的設(shè)計(jì)提供素材

• 知行合一（源碼+實(shí)戰(zhàn)）

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

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

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

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

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

根據(jù)用戶和業(yè)務(wù)影響兩個(gè)緯度來(lái)進(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ì)引起外部用戶無(wú)法使用或造成較大資損，比如主營(yíng)業(yè)務(wù)核心鏈路，如單車、助力車開(kāi)關(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ù)沒(méi)影響，或量較小的新業(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è)的高可用平臺(tái)能力

部分限流效果圖

• 預(yù)熱圖示

• 排隊(duì)等待

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

高可用平臺(tái)圖示

• 中間件全部接入
• 動(dòng)態(tài)配置實(shí)時(shí)生效
• 每個(gè)資源和IP節(jié)點(diǎn)詳細(xì)流量

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