在線業(yè)務(wù)側(cè)主要從RocketMQ集群部署架構(gòu)、平臺(tái)系統(tǒng)架構(gòu)、日常運(yùn)維操作平臺(tái)、監(jiān)控告警一體化實(shí)踐以及vivo如何通過建設(shè)AMQP消息網(wǎng)關(guān)的方式完成所有在線業(yè)務(wù)服務(wù)從RabbitMQ到RocketMQ的業(yè)務(wù)無感遷移，實(shí)現(xiàn)了在線業(yè)務(wù)消息中間件組件的統(tǒng)一。

大數(shù)據(jù)側(cè)主要從資源隔離、流量均衡、智能動(dòng)態(tài)限流、集群治理四個(gè)維度介紹Kafka在vivo的最佳實(shí)踐以及Kafka核心技術(shù)架構(gòu)在超大數(shù)據(jù)規(guī)模場(chǎng)景下的缺陷以及未來對(duì)Pulsar組件的長(zhǎng)線規(guī)劃和建設(shè)。

一、分布式消息中間件在vivo的運(yùn)營(yíng)現(xiàn)狀

1.1 技術(shù)選型

在技術(shù)選型上，我們從吞吐量、功能特性、生態(tài)集成、開源活躍等多個(gè)維度對(duì)比了當(dāng)前主流的分布式消息中間件，最終在線業(yè)務(wù)側(cè)我們選擇基于RocketMQ構(gòu)建消息平臺(tái)，依托RocketMQ豐富的功能特性滿足業(yè)務(wù)間削峰、解耦、異步化的需求。

大數(shù)據(jù)側(cè)我們選擇具備高并發(fā)、高可用、低延遲、高吞吐能力的分布式消息中間件Kafka。構(gòu)建超大數(shù)據(jù)規(guī)模處理能力的統(tǒng)一數(shù)據(jù)接入服務(wù)和實(shí)時(shí)數(shù)倉(cāng)服務(wù)。Kafka組件作為統(tǒng)一數(shù)據(jù)接入服務(wù)，是大數(shù)據(jù)全鏈路中的咽喉要道，是大數(shù)據(jù)生態(tài)體系建設(shè)中不可或缺的重要組件之一。

1.2 規(guī)?，F(xiàn)狀

運(yùn)營(yíng)指標(biāo)方面目前大數(shù)據(jù)業(yè)務(wù)側(cè)Kafka集群接入項(xiàng)目數(shù)百、接入規(guī)模方面Topic數(shù)量達(dá)到數(shù)萬、集群日均處理消息達(dá)數(shù)十萬億條、可用性保障99.99%、單機(jī)日均處理消息達(dá)數(shù)百億條。

在線業(yè)務(wù)側(cè)RocketMQ集群接入項(xiàng)目數(shù)百、接入規(guī)模方面接入數(shù)千服務(wù)、集群日均處理消息達(dá)數(shù)百億條、可用性保障100%，發(fā)送平均耗時(shí)<1ms。

二、大數(shù)據(jù)側(cè)消息中間件最佳實(shí)踐

2.1 Kafka簡(jiǎn)介

首先我們看下Kafka的官網(wǎng)定義及發(fā)展歷史，Kafka是由Apache軟件基金會(huì)開源的一個(gè)流處理平臺(tái)，是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)。具有高吞吐、低延遲、高并發(fā)、高可用、高可擴(kuò)等特性。

Kafka是由LinkedIn公司在2010年開源，2011年交由Apache軟件基金會(huì)進(jìn)行孵化，2012年成為Apache軟件基金會(huì)的頂級(jí)開源項(xiàng)目。

2.2 Kafka在超大數(shù)據(jù)規(guī)模場(chǎng)景下面臨的挑戰(zhàn)

在超大數(shù)據(jù)規(guī)模場(chǎng)景下我們會(huì)面臨以下幾個(gè)問題？

1. 如何規(guī)劃資源隔離保證核心業(yè)務(wù)、高優(yōu)業(yè)務(wù)、一般業(yè)務(wù)之間相互不受影響？
2. 如何保證集群內(nèi)部節(jié)點(diǎn)間流量均衡，降低單節(jié)點(diǎn)或部分節(jié)點(diǎn)流量差異太大帶來的資源浪費(fèi)？
3. 超大數(shù)據(jù)規(guī)模場(chǎng)景下如何進(jìn)行限流保障集群的穩(wěn)定性并盡可能降低對(duì)業(yè)務(wù)可用性的影響？
4. 集群長(zhǎng)期運(yùn)行，客戶端版本多樣，如何持續(xù)保障集群的高可用性？

下面我將從資源隔離、流量均衡、智能動(dòng)態(tài)限流、集群治理四個(gè)維度和大家一起交流Kafka在vivo的最佳實(shí)踐。

2.3 資源隔離

資源隔離的核心作用在于避免業(yè)務(wù)與業(yè)務(wù)之間的相互影響，但隔離粒度、資源利用率、運(yùn)維成本之間如何進(jìn)行權(quán)衡，是我們需要思考的重點(diǎn)。隔離粒度太粗會(huì)導(dǎo)致隔離效果不佳，隔離粒度太細(xì)會(huì)導(dǎo)致資源利用率較低、運(yùn)維成本增加。

那vivo在Kafka集群資源隔離上是如何平衡三者關(guān)系的呢？

首先我們根據(jù)業(yè)務(wù)屬性、業(yè)務(wù)線兩個(gè)維度進(jìn)行集群維度的隔離，例如我們?cè)诩簞澐稚戏譃榱松虡I(yè)化專用集群，監(jiān)控專用集群，日志專用集群等。在集群維度做了機(jī)器資源的物理隔離。

同時(shí)我們?cè)诩簝?nèi)部引入了資源組的概念。同一個(gè)集群內(nèi)部可以包含多個(gè)資源組。每個(gè)資源組可以為多個(gè)業(yè)務(wù)提供服務(wù)。資源組與資源組之間相互獨(dú)立。

上圖中右上圖是我們沒有引入資源組概念時(shí)集群內(nèi)部不同業(yè)務(wù)Topic分區(qū)的分散情況，大家可以看到業(yè)務(wù)A和業(yè)務(wù)B的Topic分區(qū)分散到集群內(nèi)的所有broker上，若業(yè)務(wù)A的流量突增可能會(huì)造成業(yè)務(wù)B受到影響，右下圖是我們引入資源組概念后不同業(yè)務(wù)Topic分區(qū)的分散情況，可以看到不同業(yè)務(wù)的topic分區(qū)只會(huì)分配到自己業(yè)務(wù)所屬的資源組內(nèi)，即使業(yè)務(wù)A的流量突增導(dǎo)致機(jī)器不可用也不會(huì)對(duì)業(yè)務(wù)B造成影響。

引入資源組概念后讓我們能在集群內(nèi)部實(shí)現(xiàn)機(jī)器資源的邏輯隔離。所以我們?cè)谫Y源隔離方面采用了物理隔離和邏輯隔離兩種方式相結(jié)合，實(shí)現(xiàn)了在超大數(shù)據(jù)規(guī)模場(chǎng)景下Kafka集群的資源隔離方案。

2.4 流量均衡

流量均衡的核心作用在于充分利用集群內(nèi)部資源，提升資源利用率。Kafka服務(wù)作為一個(gè)有狀態(tài)的服務(wù)，Kafka在技術(shù)架構(gòu)設(shè)計(jì)上Topic分區(qū)與節(jié)點(diǎn)綁定，不支持分區(qū)同一副本數(shù)據(jù)在磁盤和節(jié)點(diǎn)維度分散存儲(chǔ)。對(duì)分區(qū)的讀寫請(qǐng)求都由分區(qū)Leader所在節(jié)點(diǎn)進(jìn)行處理。所以Kafka集群流量均衡的本質(zhì)是Topic分區(qū)的分散均衡。

在流量均衡方面我們做兩期的建設(shè)，第一期我們?cè)诜謪^(qū)分散均衡算法上引入機(jī)器的實(shí)時(shí)出入流量、cpu負(fù)載、磁盤存儲(chǔ)等指標(biāo)作為負(fù)載因子生成分區(qū)遷移計(jì)劃。執(zhí)行分區(qū)遷移后達(dá)到流量均衡的目的。流量均衡一期功能上線后我們將資源組內(nèi)節(jié)點(diǎn)間流量差異從數(shù)百兆/s降低到數(shù)十兆/s。隨著集群數(shù)據(jù)規(guī)模的持續(xù)增加，我們發(fā)現(xiàn)數(shù)十兆/s的流量差異依然會(huì)造成資源浪費(fèi)。

所以在流量均衡二期功能建設(shè)上我們?cè)黾恿朔謪^(qū)分散均衡、Leader分散均衡、副本分散均衡、磁盤均衡等Kafka元數(shù)據(jù)指標(biāo)作為負(fù)載因子生成Kafka分區(qū)遷移計(jì)劃，并在分區(qū)遷移執(zhí)行上增加了多種遷移提交策略。流量均衡二期功能上線后我們將資源組內(nèi)節(jié)點(diǎn)間流量差異從數(shù)十兆/s降低到十兆以內(nèi)/s。

上圖是我們流量均衡一期功能上線前后資源組內(nèi)節(jié)點(diǎn)的流量監(jiān)控面板，可以看到一期功能上線前資源組內(nèi)節(jié)點(diǎn)間的流量偏差在數(shù)百兆/s。一期功能上線后資源組內(nèi)節(jié)點(diǎn)間流量偏差在數(shù)十兆/s以內(nèi)，資源組內(nèi)節(jié)點(diǎn)間流量偏差降低75%。極大提升了服務(wù)端的資源利用率。

上圖是我們流量均衡二期功能上線前后資源組內(nèi)節(jié)點(diǎn)的入出流量監(jiān)控面板，可以看到節(jié)點(diǎn)間入出流量偏差從數(shù)十兆/s降低到十兆以內(nèi)/s，資源組內(nèi)節(jié)點(diǎn)間流量偏差降低80%。效果也是非常明顯。

2.5 智能動(dòng)態(tài)限流

限流的本質(zhì)是限制客戶端的流量突增以確保服務(wù)端的可用性。避免客戶端的流量突增導(dǎo)致服務(wù)端整體不可用。限流的粒度，限流閾值的設(shè)定，資源利用率、服務(wù)端穩(wěn)定性之間應(yīng)該如何做權(quán)衡呢？是我們需要思考的重點(diǎn)。限流粒度太粗會(huì)導(dǎo)致限流效果不佳，當(dāng)大部分業(yè)務(wù)同時(shí)流量突增會(huì)對(duì)服務(wù)端的穩(wěn)定性帶來風(fēng)險(xiǎn)。限流粒度太細(xì)服務(wù)端應(yīng)對(duì)客服端流量突增能力不足，限流閾值設(shè)置太大會(huì)給服務(wù)端穩(wěn)定性帶來風(fēng)險(xiǎn)，限流閾值設(shè)置太小會(huì)導(dǎo)致服務(wù)端資源利用率較低。

限流方面，

1. 首先我們采用多平臺(tái)聯(lián)合診斷機(jī)制根據(jù)項(xiàng)目實(shí)際生產(chǎn)數(shù)據(jù)情況判別是否需要進(jìn)行流量調(diào)整，計(jì)算調(diào)整后的限流閾值。其中多平臺(tái)包含（JMX統(tǒng)一指標(biāo)采集平臺(tái)，統(tǒng)一監(jiān)控平臺(tái)、統(tǒng)一告警平臺(tái)、Kafka集群管理平臺(tái)等）。
2. 第二、智能分析Kafka集群服務(wù)資源負(fù)載情況，計(jì)算各資源剩余情況。確定是否可以進(jìn)行閾值調(diào)整并結(jié)合客戶端實(shí)際生產(chǎn)數(shù)據(jù)情況計(jì)算閾值調(diào)整到多少合適。
3. 第三、自動(dòng)實(shí)時(shí)調(diào)整限流閾值。

通過以上三步實(shí)現(xiàn)智能動(dòng)態(tài)限流方案。解決了限流粒度、限流閾值設(shè)定、資源利用率、Kafka集群可用性四者之間的平衡關(guān)系。

實(shí)現(xiàn)智能動(dòng)態(tài)限流后給我們帶來以下幾點(diǎn)明顯的收益。

1. 大大提升Kafka集群服務(wù)端應(yīng)對(duì)客戶端流量突增的能力。
2. 利用項(xiàng)目錯(cuò)峰的方式進(jìn)一步提升Kafka集群的資源利用率。
3. 智能化自動(dòng)調(diào)整項(xiàng)目限流閾值無需人工介入，大大降低Kafka集群在超大數(shù)據(jù)規(guī)模場(chǎng)景下的運(yùn)維成本。
4. 動(dòng)態(tài)根據(jù)服務(wù)端負(fù)載情況調(diào)整項(xiàng)目限流閾值，盡可能減小限流對(duì)業(yè)務(wù)可用性的影響。

2.6 集群治理

Kafka集群元數(shù)據(jù)統(tǒng)一由ZooKeeper集群管理，元數(shù)據(jù)信息永久有效永不過期，元數(shù)據(jù)的下發(fā)由Kafka Controller節(jié)點(diǎn)統(tǒng)一下發(fā)，隨著業(yè)務(wù)的不斷發(fā)展，數(shù)據(jù)規(guī)模的不斷增加，集群內(nèi)部Topic的數(shù)量達(dá)到萬級(jí)，分區(qū)數(shù)量達(dá)到數(shù)十萬級(jí)。元數(shù)據(jù)治理能有效避免元數(shù)規(guī)模給Kafka集群穩(wěn)定性帶來的影響。隨著接入的服務(wù)、Kafka用戶越來越多，正確的使用Kafka 客戶端也能大大提升Kafka服務(wù)端的穩(wěn)定性和資源利用率。Kafka分區(qū)與磁盤目錄綁定，創(chuàng)建Topic、Topic分區(qū)擴(kuò)容時(shí)根據(jù)Topic流量合理設(shè)置Topic分區(qū)數(shù)能有效避免單機(jī)或單盤性能瓶頸成為集群整體的性能瓶頸。

vivo在Kafka集群治理方面實(shí)現(xiàn)了節(jié)點(diǎn)流量偏差治理、Topic元數(shù)據(jù)治理、Topic分區(qū)數(shù)據(jù)傾斜治理、Topic超大分區(qū)治理、Topic消費(fèi)延遲治理等方案為Kafka集群的高可用性保駕護(hù)航。

2.7 實(shí)踐經(jīng)驗(yàn)沉淀

vivo Kafka消息中間件團(tuán)隊(duì)在三年時(shí)間內(nèi)，根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景和生產(chǎn)數(shù)據(jù)規(guī)模沉淀了較多的實(shí)踐經(jīng)驗(yàn)。例如在高可用/高可擴(kuò)方面實(shí)現(xiàn)了機(jī)架感知、彈性伸縮、數(shù)據(jù)壓縮等能力建設(shè)，在監(jiān)控告警方面提供了用戶限流告警、Topic流量突增告警、消費(fèi)延遲告警、Leader實(shí)時(shí)監(jiān)控告警，多平臺(tái)聯(lián)合故障感知告警等能力建設(shè)。我們?yōu)镵afka集群做了很多的擴(kuò)展能力建設(shè)，那解決了Kafka集群在超大數(shù)據(jù)規(guī)模場(chǎng)景下的所有問題了嗎？答案是否定的。

接下來我們一起看看Kafka集群在超大數(shù)據(jù)規(guī)模場(chǎng)景下面臨的新挑戰(zhàn)。

2.8 Kafka在超大數(shù)據(jù)規(guī)模場(chǎng)景下由技術(shù)架構(gòu)帶來的缺陷

由Kafka架構(gòu)設(shè)計(jì)所帶來的一些痛點(diǎn)無法通過擴(kuò)展能力解決，并且Kafka架構(gòu)設(shè)計(jì)上分區(qū)同一副本數(shù)據(jù)與磁盤強(qiáng)綁定不支持分散存儲(chǔ)、不支持存儲(chǔ)與運(yùn)算分離、不支持冷熱數(shù)據(jù)分層存儲(chǔ)等設(shè)計(jì)缺陷在超大數(shù)據(jù)規(guī)模場(chǎng)景下顯得尤為明顯。所以在超大數(shù)據(jù)規(guī)模場(chǎng)景下Kafka集群面臨了以下幾個(gè)痛點(diǎn)。

1. 資源利用率低。
2. 無法快速響應(yīng)業(yè)務(wù)增長(zhǎng)。
3. 故障恢復(fù)時(shí)間長(zhǎng)。
4. 歷史數(shù)據(jù)消費(fèi)故障率高（主要體現(xiàn)在磁盤io性能上）。

2.9 大數(shù)據(jù)側(cè)分布式消息中間件未來規(guī)劃

基于以上Kafka在架構(gòu)設(shè)計(jì)上的缺陷，vivo Kafka團(tuán)隊(duì)于2021年開始對(duì)另一款開源分布式消息中間件Pulsar進(jìn)行調(diào)研。

2.9.1 Pulsar簡(jiǎn)介

我們看下Pulsar的官網(wǎng)定義及發(fā)展史：Pulsar 是 Apache軟件基金會(huì)的頂級(jí)開源項(xiàng)目，是集消息、存儲(chǔ)、輕量化函數(shù)式計(jì)算為一體的下一代云原生分布式消息流組件，采用了計(jì)算與存儲(chǔ)分離的架構(gòu)設(shè)計(jì)，支持多租戶、持久化存儲(chǔ)、多機(jī)房跨區(qū)域數(shù)據(jù)復(fù)制，具有高并發(fā)、高吞吐、低延時(shí)、高可擴(kuò)，高可用等特性。

Pulsar 誕生于2012 雅虎公司內(nèi)部，2016年開源交由Apache軟件基金會(huì)進(jìn)行孵化，2018年成為Apache軟件基金會(huì)頂級(jí)開源項(xiàng)目。

2.9.2 Pulsar核心優(yōu)勢(shì)

基于Pulsar支持存算分離，分區(qū)數(shù)據(jù)分散存儲(chǔ)、冷熱數(shù)據(jù)分層存儲(chǔ)、Broker無狀態(tài)等架構(gòu)設(shè)計(jì)，讓Pulsar在超大數(shù)據(jù)規(guī)模場(chǎng)景下具備了資源利用率較高、快速響應(yīng)業(yè)務(wù)增長(zhǎng)、秒級(jí)故障恢復(fù)、實(shí)時(shí)流量均衡、支持海量數(shù)據(jù)存儲(chǔ)等明顯優(yōu)勢(shì)。

2.9.3 Pulsar未來規(guī)劃

我們對(duì)Pulsar組件的規(guī)劃分為四個(gè)階段，包含項(xiàng)目啟動(dòng)、穩(wěn)定性建設(shè)、能力進(jìn)階、穩(wěn)定運(yùn)營(yíng)。

目前我們處在Pulsar組件穩(wěn)定性建設(shè)階段。

2022年我們的目標(biāo)是打造支持日均萬億級(jí)消息處理能力的Pulsar集群，完成分層存儲(chǔ)，監(jiān)控告警一體化、KoP功能平臺(tái)化等擴(kuò)展能力建設(shè)。

計(jì)劃2023年打造具備日均十萬億級(jí)消息處理能力的Pulsar集群，達(dá)到行業(yè)一流水準(zhǔn)。并完成Pulsar broker容器化部署、Pulsar生態(tài)體系建設(shè)、Pulsar Sql和Pulsar Function的應(yīng)用調(diào)研等擴(kuò)展能力建設(shè)。

將在2024年實(shí)現(xiàn)日均數(shù)十萬億級(jí)消息處理能力的Pulsar集群，達(dá)到行業(yè)超一流的水準(zhǔn)。

三、在線業(yè)務(wù)側(cè)消息中間件最佳實(shí)踐

3.1 RocketMQ簡(jiǎn)介

RocketMQ是阿里巴巴于2012年開源的低延時(shí)、高并發(fā)、高可用、高可靠的分布式消息中間件，具有海量消息堆積、高吞吐、可靠重試等特性。

RocketMQ于2012年開源，2016年進(jìn)入Apache孵化，于2017年成為Apache頂級(jí)項(xiàng)目。

3.2 RocketMQ在vivo內(nèi)部使用現(xiàn)狀

vivo中間件團(tuán)隊(duì)在2021年引入RocketMQ并且完成了高可用和平臺(tái)化建設(shè)。

當(dāng)前分別在多個(gè)機(jī)房部署了多個(gè)集群供業(yè)務(wù)使用，每日消息量數(shù)百億。

集群分布在多個(gè)機(jī)房，每日消息量級(jí)也不低，高可用運(yùn)維保障是有難度的。

3.3 vivo基于RocketMQ的高可用保障實(shí)踐經(jīng)驗(yàn)

3.3.1 集群部署架構(gòu)介紹

為了更好的保障集群的高可用，我們采用了雙機(jī)房熱備的方式進(jìn)行集群搭建。

我們會(huì)在兩個(gè)機(jī)房進(jìn)行Broker的部署，業(yè)務(wù)Topic會(huì)默認(rèn)分布在兩個(gè)機(jī)房，以此來保障在一個(gè)機(jī)房?jī)?nèi)的Broker節(jié)點(diǎn)異常時(shí)業(yè)務(wù)可以保持正常生產(chǎn)消費(fèi)能力。

業(yè)務(wù)默認(rèn)是會(huì)優(yōu)先使用本機(jī)房的節(jié)點(diǎn)進(jìn)行生產(chǎn)消費(fèi)，只有在異常時(shí)才會(huì)自動(dòng)快速完成跨機(jī)房的流量切換。

同時(shí)我們構(gòu)建了一個(gè)BrokerController模塊用于實(shí)現(xiàn)Broker節(jié)點(diǎn)的主從切換，以此保障集群容量的快速恢復(fù)。

雙機(jī)房熱備模式有哪些優(yōu)勢(shì)呢？

• 第一，消息無需跨機(jī)房復(fù)制，降低對(duì)機(jī)房專線的依賴；
• 第二，可以降低業(yè)務(wù)發(fā)送消息的延時(shí)，也可以提升業(yè)務(wù)的處理性能；

雙機(jī)房熱備模式的劣勢(shì)是每個(gè)機(jī)房的節(jié)點(diǎn)都需要冗余一定的buffer來支撐其它機(jī)房的節(jié)點(diǎn)異常時(shí)自動(dòng)轉(zhuǎn)移過來的業(yè)務(wù)流量。

3.3.2 平臺(tái)系統(tǒng)架構(gòu)介紹

集群雙機(jī)房熱備部署模式是消息平臺(tái)的高可用基石，在此之外我們還建設(shè)了多個(gè)平臺(tái)模塊來保障平臺(tái)的高可靠。

如上圖所示，

• mq-rebalance模塊用于支撐集群流量的自動(dòng)負(fù)載均衡；
• mq-monitor模塊進(jìn)行監(jiān)控指標(biāo)的采集并且與vivo內(nèi)部的監(jiān)控系統(tǒng)打通；
• mq-recover模塊主要用于業(yè)務(wù)流量的降級(jí)和恢復(fù)處理；
• mq-live模塊用于集群的探活。

另外我們還基于社區(qū)的connector組件建設(shè)了RabbitMQ-connector，實(shí)現(xiàn)了全球消息路由能力。

后續(xù)我們計(jì)劃建設(shè)基于gRPC協(xié)議建設(shè)通用的消息網(wǎng)關(guān)實(shí)現(xiàn)與集群的交互，以此屏蔽不同的消息中間件選型。

3.3.3 運(yùn)維能力平臺(tái)化提升運(yùn)維效率

主要有三點(diǎn)實(shí)踐：

第一，RocketMQ集群配置平臺(tái)化管理。RocketMQ集群含有較多的配置項(xiàng)，默認(rèn)是通過節(jié)點(diǎn)文件管理的，在大規(guī)模集群運(yùn)維過程中會(huì)存在維護(hù)困難的問題。

通過平臺(tái)化管理可以確保集群內(nèi)配置統(tǒng)一，節(jié)點(diǎn)在啟動(dòng)時(shí)從平臺(tái)中讀取到所有的配置，避免在集群部署時(shí)需要登錄到機(jī)器進(jìn)行配置維護(hù)，并且我們支持了集群配置的動(dòng)態(tài)生效。

第二，運(yùn)維操作平臺(tái)化，例如Broker節(jié)點(diǎn)的流量摘除與掛載、Topic一鍵擴(kuò)縮容等直接通過平臺(tái)支撐，實(shí)現(xiàn)便捷運(yùn)維。

第三，集群維護(hù)平臺(tái)化，我們將集群與Broker節(jié)點(diǎn)的關(guān)系維護(hù)在平臺(tái)中，并且在首次部署時(shí)分配Broker節(jié)點(diǎn)所在集群，這樣在平臺(tái)上就有清晰的集群信息，便于我們維護(hù)管理多套集群。

3.3.4 平臺(tái)監(jiān)控告警能力建設(shè)

• 一方面，我們?yōu)槊總€(gè)集群都建設(shè)了如上圖所示的監(jiān)控大盤。
  在監(jiān)控大盤中有每個(gè)集群的生產(chǎn)消費(fèi)流量、業(yè)務(wù)生產(chǎn)消費(fèi)統(tǒng)計(jì)、發(fā)送耗時(shí)等信息，支撐我們快速觀察集群的運(yùn)行狀態(tài)，方便日常巡檢。
  消息中間件作為在線業(yè)務(wù)請(qǐng)求處理鏈路中的關(guān)鍵環(huán)節(jié)，高可用尤為關(guān)鍵。監(jiān)控大盤中的發(fā)送耗時(shí)信息是我們認(rèn)為觀察集群是否穩(wěn)定運(yùn)行的最關(guān)鍵的指標(biāo)。
• 另一方面，我們對(duì)集群構(gòu)建了豐富的監(jiān)控告警能力。
  如上圖所示，我們分別對(duì)主機(jī)維度、集群維度、Topic/Group維度、客戶端維度都做了監(jiān)控指標(biāo)埋點(diǎn)上報(bào)。
  通過豐富的監(jiān)控告警，我們可以及時(shí)發(fā)現(xiàn)問題并快速介入處理問題，詳細(xì)的監(jiān)控告警也可以幫助我們快速確認(rèn)問題根源。

3.4 業(yè)務(wù)從RabbitMQ無感遷移到RocketMQ實(shí)戰(zhàn)經(jīng)驗(yàn)

3.4.1 使用RocketMQ替換RabbitMQ根因分析

分別從可用性保障、性能、容量、功能特性對(duì)比RabbitMQ和RocketMQ。

• 可用性保障方面，RabbitMQ集群無負(fù)載均衡能力，隊(duì)列流量實(shí)際由集群內(nèi)某個(gè)節(jié)點(diǎn)承載，存在瓶頸。其次RabbitMQ存在腦裂問題，從我們的運(yùn)維經(jīng)驗(yàn)看如果出現(xiàn)網(wǎng)絡(luò)故障集群通常無法自動(dòng)恢復(fù)，并且可能丟失少量數(shù)據(jù)。
• 性能方面，RabbitMQ集群整體性能較低，并且不支持水平擴(kuò)展。
• 容量方面，從我們的運(yùn)維經(jīng)驗(yàn)看，當(dāng)消息堆積到千萬后，RabbitMQ性能就會(huì)有所下降。在大量消息堆積開始消費(fèi)后，因?yàn)镽abbitMQ的背壓流控機(jī)制，最終可能會(huì)因?yàn)榧贺?fù)載過大導(dǎo)致發(fā)送限流深圳發(fā)送阻塞。
• 功能特性方面，RabbitMQ不支持消費(fèi)異常延時(shí)重投遞功能，也不支持消息軌跡、事務(wù)消息、順序消息等特性。

而RocketMQ在可用性保障、性能、容量、功能特性方面相對(duì)于RabbitMQ都是更優(yōu)的。

• 可用性保障方面，RocketMQ采用多主多從的松耦合架構(gòu)部署，主從間通過同步雙寫保障消息的可靠性和一致性。
• 性能方面，Topic可以分布在多個(gè)Broker中，實(shí)現(xiàn)水平擴(kuò)容，并且RocketMQ支持從從節(jié)點(diǎn)拉取消息，讀寫分離的設(shè)計(jì)很好的支持了業(yè)務(wù)讀取冷數(shù)據(jù)的訴求。
• 容量方面，RocketMQ使用磁盤存儲(chǔ)，磁盤容量就是消息的存儲(chǔ)容量，利用從從節(jié)點(diǎn)拉取冷數(shù)據(jù)特性，海量消息堆積對(duì)消息寫入性能基本無影響。
• 功能特性方面，RocketMQ支持了消息軌跡、事務(wù)消息、順序消息等特性。

綜合分析，RocketMQ可以更好的支撐互聯(lián)網(wǎng)業(yè)務(wù)的訴求。

3.4.2 AMQP消息網(wǎng)關(guān)架構(gòu)支撐實(shí)現(xiàn)無感遷移

由于當(dāng)前RabbitMQ已經(jīng)有數(shù)千個(gè)服務(wù)接入，為了讓業(yè)務(wù)不修改代碼即可遷移到RocketMQ，我們建設(shè)了一個(gè)AMQP消息網(wǎng)關(guān)來實(shí)現(xiàn)MQ協(xié)議的解析和流量轉(zhuǎn)發(fā)。

如上圖所示，MQ-Proxy模塊用于解析AMQP協(xié)議，代理客戶端的生產(chǎn)消費(fèi)請(qǐng)求。

RabbitMQ的元數(shù)據(jù)信息存在在集群中，并且與RocketMQ元數(shù)據(jù)概念存在差異，為此我們建設(shè)了MQ-Meta模塊用于維護(hù)Exchange/Queue極其綁定關(guān)系等元數(shù)據(jù)信息，并且Proxy模塊可以動(dòng)態(tài)感知元數(shù)據(jù)變更。

另外，為了更好的支撐業(yè)務(wù)訴求，我們對(duì)AMQP協(xié)議進(jìn)行了擴(kuò)展，支持了局部有序和批量消費(fèi)能力。

3.4.3 RabbitMQ和RocketMQ元數(shù)據(jù)概念映射

為了更好的整合RabbitMQ和RocketMQ，我們對(duì)它們的元數(shù)據(jù)進(jìn)行了一一對(duì)應(yīng)。

其中將RabbitMQ的Exchange映射為RocketMQ的Topic，Queue映射為Group，RoutingKey映射為消息頭的一個(gè)參數(shù)，VirtualHost映射為Namespace。

為什么將RoutingKey映射為消息頭的一個(gè)參數(shù)而不是Tag呢？這是因?yàn)镽abbitMQ的RoutingKey是有模糊匹配過濾能力的，而RocketMQ的Tag是不支持模糊匹配的。

另外我們還通過擴(kuò)展使得RocketMQ也支持了RoutingKey過濾。

在經(jīng)過多輪優(yōu)化后，在1KB消息體場(chǎng)景下，一臺(tái)8C16G的機(jī)器在單發(fā)送下可支撐超過九萬的TPS，單推送可以支撐超過六萬TPS，性能上很好的滿足了當(dāng)前業(yè)務(wù)的訴求。

3.5 在線業(yè)務(wù)消息中間件的未來規(guī)劃

主要有兩部分：

一方面，我們希望可以調(diào)研升級(jí)到RocketMQ5.0版本架構(gòu)，RocketMQ5.0的存算分離架構(gòu)可以更好的解決我們當(dāng)前遇到的存儲(chǔ)瓶頸問題，Pop消費(fèi)可以幫助我們實(shí)現(xiàn)更好的消費(fèi)負(fù)載均衡。

我們還希望可以基于gRPC協(xié)議建設(shè)統(tǒng)一的消息網(wǎng)關(guān)能力。

另一方面，我們希望可以探索消息中間件容器化部署，提供消息中間件的快速?gòu)椥詳U(kuò)縮容能力，更好的支持業(yè)務(wù)需求。

四、總結(jié)

回顧vivo消息中間件演進(jìn)歷史，我們完成了在線業(yè)務(wù)消息中間件從RabbitMQ遷移到RocketMQ，大數(shù)據(jù)消息中間件正在從kafka演進(jìn)為使用pulsar支撐。

我們理解消息中間件將繼續(xù)朝著云原生演進(jìn)，滿足業(yè)務(wù)快速增長(zhǎng)的訴求，充分利用云的優(yōu)勢(shì)為業(yè)務(wù)提供極致的體驗(yàn)。