作者：vivo 網際網路儲存技術團隊-Luo Mingbo、中介軟體團隊- Liu Runyun
本文根據“2022 vivo開發者大會"現場演講內容整理而成。
本文主要介紹超大資料規模場景下分散式訊息中介軟體在vivo的應用實踐。
線上業務側主要從RocketMQ叢集部署架構、平臺系統架構、日常運維操作平臺、監控告警一體化實踐以及vivo如何透過建設AMQP訊息閘道器的方式完成所有線上業務服務從RabbitMQ到RocketMQ的業務無感遷移，實現了線上業務訊息中介軟體元件的統一。
大資料側主要從資源隔離、流量均衡、智慧動態限流、叢集治理四個維度介紹Kafka在vivo的最佳實踐以及Kafka核心技術架構在超大資料規模場景下的缺陷以及未來對Pulsar元件的長線規劃和建設。
一、分散式訊息中介軟體在vivo的運營現狀
1.1 技術選型
在技術選型上，我們從吞吐量、功能特性、生態整合、開源活躍等多個維度對比了當前主流的分散式訊息中介軟體，最終線上業務側我們選擇基於RocketMQ構建訊息平臺，依託RocketMQ豐富的功能特性滿足業務間削峰、解耦、非同步化的需求。
大資料側我們選擇具備高併發、高可用、低延遲、高吞吐能力的分散式訊息中介軟體Kafka。構建超大資料規模處理能力的統一資料接入服務和實時數倉服務。Kafka元件作為統一資料接入服務，是大資料全鏈路中的咽喉要道，是大資料生態體系建設中不可或缺的重要元件之一。
1.2 規模現狀
運營指標方面目前大資料業務側Kafka叢集接入專案數百、接入規模方面Topic數量達到數萬、叢集日均處理訊息達數十萬億條、可用性保障99.99%、單機日均處理訊息達數百億條。
線上業務側RocketMQ叢集接入專案數百、接入規模方面接入數千服務、叢集日均處理訊息達數百億條、可用性保障100%，傳送平均耗時<1ms。
二、大資料側訊息中介軟體最佳實踐
2.1 Kafka簡介
首先我們看下Kafka的官網定義及發展歷史，Kafka是由Apache軟體基金會開源的一個流處理平臺，是一種高吞吐量的分散式釋出訂閱訊息系統。具有高吞吐、低延遲、高併發、高可用、高可擴等特性。
Kafka是由LinkedIn公司在2010年開源，2011年交由Apache軟體基金會進行孵化，2012年成為Apache軟體基金會的頂級開源專案。
2.2 Kafka在超大資料規模場景下面臨的挑戰
在超大資料規模場景下我們會面臨以下幾個問題？
- 如何規劃資源隔離保證核心業務、高優業務、一般業務之間相互不受影響？
- 如何保證叢集內部節點間流量均衡，降低單節點或部分節點流量差異太大帶來的資源浪費？
- 超大資料規模場景下如何進行限流保障叢集的穩定性並儘可能降低對業務可用性的影響？
- 叢集長期執行，客戶端版本多樣，如何持續保障叢集的高可用性？
下面我將從資源隔離、流量均衡、智慧動態限流、叢集治理四個維度和大家一起交流Kafka在vivo的最佳實踐。
2.3 資源隔離
資源隔離的核心作用在於避免業務與業務之間的相互影響，但隔離粒度、資源利用率、運維成本之間如何進行權衡，是我們需要思考的重點。隔離粒度太粗會導致隔離效果不佳，隔離粒度太細會導致資源利用率較低、運維成本增加。
那vivo在Kafka叢集資源隔離上是如何平衡三者關係的呢？
首先我們根據業務屬性、業務線兩個維度進行叢集維度的隔離，例如我們在叢集劃分上分為了商業化專用叢集，監控專用叢集，日誌專用叢集等。在叢集維度做了機器資源的物理隔離。
同時我們在叢集內部引入了資源組的概念。同一個叢集內部可以包含多個資源組。每個資源組可以為多個業務提供服務。資源組與資源組之間相互獨立。
上圖中右上圖是我們沒有引入資源組概念時叢集內部不同業務Topic分割槽的分散情況，大家可以看到業務A和業務B的Topic分割槽分散到叢集內的所有broker上，若業務A的流量突增可能會造成業務B受到影響，右下圖是我們引入資源組概念後不同業務Topic分割槽的分散情況，可以看到不同業務的topic分割槽只會分配到自己業務所屬的資源組內，即使業務A的流量突增導致機器不可用也不會對業務B造成影響。
引入資源組概念後讓我們能在叢集內部實現機器資源的邏輯隔離。所以我們在資源隔離方面採用了物理隔離和邏輯隔離兩種方式相結合，實現了在超大資料規模場景下Kafka叢集的資源隔離方案。
2.4 流量均衡
流量均衡的核心作用在於充分利用叢集內部資源，提升資源利用率。Kafka服務作為一個有狀態的服務，Kafka在技術架構設計上Topic分割槽與節點繫結，不支援分割槽同一副本資料在磁碟和節點維度分散儲存。對分割槽的讀寫請求都由分割槽Leader所在節點進行處理。所以Kafka叢集流量均衡的本質是Topic分割槽的分散均衡。
在流量均衡方面我們做兩期的建設，第一期我們在分割槽分散均衡演算法上引入機器的實時出入流量、cpu負載、磁碟儲存等指標作為負載因子生成分割槽遷移計劃。執行分割槽遷移後達到流量均衡的目的。流量均衡一期功能上線後我們將資源組內節點間流量差異從數百兆/s降低到數十兆/s。隨著叢集資料規模的持續增加，我們發現數十兆/s的流量差異依然會造成資源浪費。
所以在流量均衡二期功能建設上我們增加了分割槽分散均衡、Leader分散均衡、副本分散均衡、磁碟均衡等Kafka後設資料指標作為負載因子生成Kafka分割槽遷移計劃，並在分割槽遷移執行上增加了多種遷移提交策略。流量均衡二期功能上線後我們將資源組內節點間流量差異從數十兆/s降低到十兆以內/s。
上圖是我們流量均衡一期功能上線前後資源組內節點的流量監控皮膚，可以看到一期功能上線前資源組內節點間的流量偏差在數百兆/s。一期功能上線後資源組內節點間流量偏差在數十兆/s以內，資源組內節點間流量偏差降低75%。極大提升了服務端的資源利用率。
上圖是我們流量均衡二期功能上線前後資源組內節點的入出流量監控皮膚，可以看到節點間入出流量偏差從數十兆/s降低到十兆以內/s，資源組內節點間流量偏差降低80%。效果也是非常明顯。
2.5 智慧動態限流
限流的本質是限制客戶端的流量突增以確保服務端的可用性。避免客戶端的流量突增導致服務端整體不可用。限流的粒度，限流閾值的設定，資源利用率、服務端穩定性之間應該如何做權衡呢？是我們需要思考的重點。限流粒度太粗會導致限流效果不佳，當大部分業務同時流量突增會對服務端的穩定性帶來風險。限流粒度太細服務端應對客服端流量突增能力不足，限流閾值設定太大會給服務端穩定性帶來風險，限流閾值設定太小會導致服務端資源利用率較低。
限流方面，
- 首先我們採用多平臺聯合診斷機制根據專案實際生產資料情況判別是否需要進行流量調整，計算調整後的限流閾值。其中多平臺包含（JMX統一指標採集平臺，統一監控平臺、統一告警平臺、Kafka叢集管理平臺等）。
- 第二、智慧分析Kafka叢集服務資源負載情況，計算各資源剩餘情況。確定是否可以進行閾值調整並結合客戶端實際生產資料情況計算閾值調整到多少合適。
- 第三、自動實時調整限流閾值。
透過以上三步實現智慧動態限流方案。解決了限流粒度、限流閾值設定、資源利用率、Kafka叢集可用性四者之間的平衡關係。
實現智慧動態限流後給我們帶來以下幾點明顯的收益。
- 大大提升Kafka叢集服務端應對客戶端流量突增的能力。
- 利用專案錯峰的方式進一步提升Kafka叢集的資源利用率。
- 智慧化自動調整專案限流閾值無需人工介入，大大降低Kafka叢集在超大資料規模場景下的運維成本。
- 動態根據服務端負載情況調整專案限流閾值，儘可能減小限流對業務可用性的影響。
2.6 叢集治理
Kafka叢集後設資料統一由ZooKeeper叢集管理，後設資料資訊永久有效永不過期，後設資料的下發由Kafka Controller節點統一下發，隨著業務的不斷髮展，資料規模的不斷增加，叢集內部Topic的數量達到萬級，分割槽數量達到數十萬級。後設資料治理能有效避免元數規模給Kafka叢集穩定性帶來的影響。隨著接入的服務、Kafka使用者越來越多，正確的使用Kafka 客戶端也能大大提升Kafka服務端的穩定性和資源利用率。Kafka分割槽與磁碟目錄繫結，建立Topic、Topic分割槽擴容時根據Topic流量合理設定Topic分割槽數能有效避免單機或單盤效能瓶頸成為叢集整體的效能瓶頸。
vivo在Kafka叢集治理方面實現了節點流量偏差治理、Topic後設資料治理、Topic分割槽資料傾斜治理、Topic超大分割槽治理、Topic消費延遲治理等方案為Kafka叢集的高可用性保駕護航。
2.7 實踐經驗沉澱
vivo Kafka訊息中介軟體團隊在三年時間內，根據實際的業務場景和生產資料規模沉澱了較多的實踐經驗。例如在高可用/高可擴方面實現了機架感知、彈性伸縮、資料壓縮等能力建設，在監控告警方面提供了使用者限流告警、Topic流量突增告警、消費延遲告警、Leader實時監控告警，多平臺聯合故障感知告警等能力建設。我們為Kafka叢集做了很多的擴充套件能力建設，那解決了Kafka叢集在超大資料規模場景下的所有問題了嗎？答案是否定的。
接下來我們一起看看Kafka叢集在超大資料規模場景下面臨的新挑戰。
2.8 Kafka在超大資料規模場景下由技術架構帶來的缺陷
由Kafka架構設計所帶來的一些痛點無法透過擴充套件能力解決，並且Kafka架構設計上分割槽同一副本資料與磁碟強繫結不支援分散儲存、不支援儲存與運算分離、不支援冷熱資料分層儲存等設計缺陷在超大資料規模場景下顯得尤為明顯。所以在超大資料規模場景下Kafka叢集面臨了以下幾個痛點。
- 資源利用率低。
- 無法快速響應業務增長。
- 故障恢復時間長。
- 歷史資料消費故障率高（主要體現在磁碟io效能上）。
2.9 大資料側分散式訊息中介軟體未來規劃
基於以上Kafka在架構設計上的缺陷，vivo Kafka團隊於2021年開始對另一款開源分散式訊息中介軟體Pulsar進行調研。
2.9.1 Pulsar簡介
我們看下Pulsar的官網定義及發展史：Pulsar 是 Apache軟體基金會的頂級開源專案，是集訊息、儲存、輕量化函式式計算為一體的下一代雲原生分散式訊息流元件，採用了計算與儲存分離的架構設計，支援多租戶、持久化儲存、多機房跨區域資料複製，具有高併發、高吞吐、低延時、高可擴，高可用等特性。
Pulsar 誕生於2012 雅虎公司內部，2016年開源交由Apache軟體基金會進行孵化，2018年成為Apache軟體基金會頂級開源專案。
2.9.2 Pulsar核心優勢
基於Pulsar支援存算分離，分割槽資料分散儲存、冷熱資料分層儲存、Broker無狀態等架構設計，讓Pulsar在超大資料規模場景下具備了資源利用率較高、快速響應業務增長、秒級故障恢復、實時流量均衡、支援海量資料儲存等明顯優勢。
2.9.3 Pulsar未來規劃
我們對Pulsar元件的規劃分為四個階段，包含專案啟動、穩定性建設、能力進階、穩定運營。
目前我們處在Pulsar元件穩定性建設階段。
2022年我們的目標是打造支援日均萬億級訊息處理能力的Pulsar叢集，完成分層儲存，監控告警一體化、KoP功能平臺化等擴充套件能力建設。
計劃2023年打造具備日均十萬億級訊息處理能力的Pulsar叢集，達到行業一流水準。並完成Pulsar broker容器化部署、Pulsar生態體系建設、Pulsar Sql和Pulsar Function的應用調研等擴充套件能力建設。
將在2024年實現日均數十萬億級訊息處理能力的Pulsar叢集，達到行業超一流的水準。
三、線上業務側訊息中介軟體最佳實踐
3.1 RocketMQ簡介
RocketMQ是阿里巴巴於2012年開源的低延時、高併發、高可用、高可靠的分散式訊息中介軟體，具有海量訊息堆積、高吞吐、可靠重試等特性。
RocketMQ於2012年開源，2016年進入Apache孵化，於2017年成為Apache頂級專案。
3.2 RocketMQ在vivo內部使用現狀
vivo中介軟體團隊在2021年引入RocketMQ並且完成了高可用和平臺化建設。
當前分別在多個機房部署了多個叢集供業務使用，每日訊息量數百億。
叢集分佈在多個機房，每日訊息量級也不低，高可用運維保障是有難度的。
3.3 vivo基於RocketMQ的高可用保障實踐經驗
3.3.1 叢集部署架構介紹
為了更好的保障叢集的高可用，我們採用了雙機房熱備的方式進行叢集搭建。
我們會在兩個機房進行Broker的部署，業務Topic會預設分佈在兩個機房，以此來保障在一個機房內的Broker節點異常時業務可以保持正常生產消費能力。
業務預設是會優先使用本機房的節點進行生產消費，只有在異常時才會自動快速完成跨機房的流量切換。
同時我們構建了一個BrokerController模組用於實現Broker節點的主從切換，以此保障叢集容量的快速恢復。
雙機房熱備模式有哪些優勢呢？
- 第一，訊息無需跨機房複製，降低對機房專線的依賴；
- 第二，可以降低業務傳送訊息的延時，也可以提升業務的處理效能；
雙機房熱備模式的劣勢是每個機房的節點都需要冗餘一定的buffer來支撐其它機房的節點異常時自動轉移過來的業務流量。
3.3.2 平臺系統架構介紹
叢集雙機房熱備部署模式是訊息平臺的高可用基石，在此之外我們還建設了多個平臺模組來保障平臺的高可靠。
如上圖所示，
- mq-rebalance模組用於支撐叢集流量的自動負載均衡；
- mq-monitor模組進行監控指標的採集並且與vivo內部的監控系統打通；
- mq-recover模組主要用於業務流量的降級和恢復處理；
- mq-live模組用於叢集的探活。
另外我們還基於社群的connector元件建設了RabbitMQ-connector，實現了全球訊息路由能力。
後續我們計劃建設基於gRPC協議建設通用的訊息閘道器實現與叢集的互動，以此遮蔽不同的訊息中介軟體選型。
3.3.3 運維能力平臺化提升運維效率
主要有三點實踐：
第一，RocketMQ叢集配置平臺化管理。RocketMQ叢集含有較多的配置項，預設是透過節點檔案管理的，在大規模叢集運維過程中會存在維護困難的問題。
透過平臺化管理可以確保叢集內配置統一，節點在啟動時從平臺中讀取到所有的配置，避免在叢集部署時需要登入到機器進行配置維護，並且我們支援了叢集配置的動態生效。
第二，運維操作平臺化，例如Broker節點的流量摘除與掛載、Topic一鍵擴縮容等直接透過平臺支撐，實現便捷運維。
第三，叢集維護平臺化，我們將叢集與Broker節點的關係維護在平臺中，並且在首次部署時分配Broker節點所在叢集，這樣在平臺上就有清晰的叢集資訊，便於我們維護管理多套叢集。
3.3.4 平臺監控告警能力建設
- 一方面，我們為每個叢集都建設了如上圖所示的監控大盤。
在監控大盤中有每個叢集的生產消費流量、業務生產消費統計、傳送耗時等資訊，支撐我們快速觀察叢集的執行狀態，方便日常巡檢。
訊息中介軟體作為線上業務請求處理鏈路中的關鍵環節，高可用尤為關鍵。監控大盤中的傳送耗時資訊是我們認為觀察叢集是否穩定執行的最關鍵的指標。
- 另一方面，我們對叢集構建了豐富的監控告警能力。
如上圖所示，我們分別對主機維度、叢集維度、Topic/Group維度、客戶端維度都做了監控指標埋點上報。
透過豐富的監控告警，我們可以及時發現問題並快速介入處理問題，詳細的監控告警也可以幫助我們快速確認問題根源。
3.4 業務從RabbitMQ無感遷移到RocketMQ實戰經驗
3.4.1 使用RocketMQ替換RabbitMQ根因分析
分別從可用性保障、效能、容量、功能特性對比RabbitMQ和RocketMQ。
- 可用性保障方面，RabbitMQ叢集無負載均衡能力，佇列流量實際由叢集內某個節點承載，存在瓶頸。其次RabbitMQ存在腦裂問題，從我們的運維經驗看如果出現網路故障叢集通常無法自動恢復，並且可能丟失少量資料。
- 效能方面，RabbitMQ叢集整體效能較低，並且不支援水平擴充套件。
- 容量方面，從我們的運維經驗看，當訊息堆積到千萬後，RabbitMQ效能就會有所下降。在大量訊息堆積開始消費後，因為RabbitMQ的背壓流控機制，最終可能會因為叢集負載過大導致傳送限流甚至傳送阻塞。
- 功能特性方面，RabbitMQ不支援消費異常延時重投遞功能，也不支援訊息軌跡、事務訊息、順序訊息等特性。
而RocketMQ在可用性保障、效能、容量、功能特性方面相對於RabbitMQ都是更優的。
- 可用性保障方面，RocketMQ採用多主多從的松耦合架構部署，主從間透過同步雙寫保障訊息的可靠性和一致性。
- 效能方面，Topic可以分佈在多個Broker中，實現水平擴容，並且RocketMQ支援從從節點拉取訊息，讀寫分離的設計很好的支援了業務讀取冷資料的訴求。
- 容量方面，RocketMQ使用磁碟儲存，磁碟容量就是訊息的儲存容量，利用從從節點拉取冷資料特性，海量訊息堆積對訊息寫入效能基本無影響。
- 功能特性方面，RocketMQ支援了訊息軌跡、事務訊息、順序訊息等特性。
綜合分析，RocketMQ可以更好的支撐網際網路業務的訴求。
3.4.2 AMQP訊息閘道器架構支撐實現無感遷移
由於當前RabbitMQ已經有數千個服務接入，為了讓業務不修改程式碼即可遷移到RocketMQ，我們建設了一個AMQP訊息閘道器來實現MQ協議的解析和流量轉發。
如上圖所示，MQ-Proxy模組用於解析AMQP協議，代理客戶端的生產消費請求。
RabbitMQ的後設資料資訊存在在叢集中，並且與RocketMQ後設資料概念存在差異，為此我們建設了MQ-Meta模組用於維護Exchange/Queue極其繫結關係等後設資料資訊，並且Proxy模組可以動態感知後設資料變更。
另外，為了更好的支撐業務訴求，我們對AMQP協議進行了擴充套件，支援了區域性有序和批次消費能力。
3.4.3 RabbitMQ和RocketMQ後設資料概念對映
為了更好的整合RabbitMQ和RocketMQ，我們對它們的後設資料進行了一一對應。
其中將RabbitMQ的Exchange對映為RocketMQ的Topic，Queue對映為Group，RoutingKey對映為訊息頭的一個引數，VirtualHost對映為Namespace。
為什麼將RoutingKey對映為訊息頭的一個引數而不是Tag呢？這是因為RabbitMQ的RoutingKey是有模糊匹配過濾能力的，而RocketMQ的Tag是不支援模糊匹配的。
另外我們還透過擴充套件使得RocketMQ也支援了RoutingKey過濾。
在經過多輪最佳化後，在1KB訊息體場景下，一臺8C16G的機器在單傳送下可支撐超過九萬的TPS，單推送可以支撐超過六萬TPS，效能上很好的滿足了當前業務的訴求。
3.5 線上業務訊息中介軟體的未來規劃
主要有兩部分：
一方面，我們希望可以調研升級到RocketMQ5.0版本架構，RocketMQ5.0的存算分離架構可以更好的解決我們當前遇到的儲存瓶頸問題，Pop消費可以幫助我們實現更好的消費負載均衡。
我們還希望可以基於gRPC協議建設統一的訊息閘道器能力。
另一方面，我們希望可以探索訊息中介軟體容器化部署，提供訊息中介軟體的快速彈性擴縮容能力，更好的支援業務需求。
四、總結
回顧vivo訊息中介軟體演進歷史，我們完成了線上業務訊息中介軟體從RabbitMQ遷移到RocketMQ，大資料訊息中介軟體正在從kafka演進為使用pulsar支撐。
我們理解訊息中介軟體將繼續朝著雲原生演進，滿足業務快速增長的訴求，充分利用雲的優勢為業務提供極致的體驗。