一、vivo 架構演進實踐

1. 業(yè)務背景

首先來介紹一下相關業(yè)務背景。

上圖展示了 vivo 互聯(lián)網大數(shù)據(jù)場景下全鏈路架構。以終端用戶為起點，經過統(tǒng)一的數(shù)據(jù)集成，數(shù)據(jù)進入統(tǒng)一數(shù)據(jù)接入層，再通過 ETL 的海量計算和實時的數(shù)據(jù)分揀，將數(shù)據(jù)存入實時數(shù)倉和離線數(shù)倉，最終賦能到下游的業(yè)務產品。這個架構是當前主流的架構體系。在此架構中分布式消息中間件（Kafka/Pulsar）致力于為用戶提供一套在大數(shù)據(jù)場景下高吞吐、低延時、高可靠、高擴展、全托管、安全的統(tǒng)一數(shù)據(jù)接入服務和實時數(shù)倉服務。

我們認為，考慮 AI 大模型的變與不變，核心在于數(shù)據(jù)，對數(shù)據(jù)穩(wěn)定性要求的日益提高也使得我們開始思考下一代消息中間件應該是什么樣子的。圖中展示了 vivo 的技術演進迭代路徑。vivo 消息中間件項目從 2019 年立項，2021 年完成功能建設，項目進入快速發(fā)展的階段，2022 年項目達到了成熟運營的水平。項目建設過程中，2021 年我們發(fā)現(xiàn) Kafka 在超大數(shù)據(jù)規(guī)模場景下存在一些架構上的缺陷，所以我們團隊開始對下一代分布式消息中間件 Palsar 進行調研，與之相關的項目在 2022 年正式立項。截至今年，經過一年的運營和引流，目前每天 Palsar 集群處理的消息量在 2 萬億左右。

統(tǒng)一數(shù)據(jù)接入層的上一層是統(tǒng)一數(shù)據(jù)采集層。vivo 在統(tǒng)一數(shù)據(jù)采集層會做一些高可用的保障。

（1）離線鏈路寫 HDFS 實現(xiàn)分鐘級主備切換

對于離線鏈路，做到了分鐘級的主備切換，這依賴于 manager 服務能實時檢測HDFS 集群的健康狀態(tài)并實時同步到 agent，當 HDFS 集群出現(xiàn)故障時，同時通知到上游的統(tǒng)一采集層以及下游的 ETL，在分鐘級的時間段內切換到備份集群上，實現(xiàn)在離線鏈路上的高可用保障。

（2）高優(yōu)業(yè)務雙鏈路容災快速切換

目前對于數(shù)據(jù)接入有實時鏈路和離線鏈路兩套數(shù)據(jù)接入架構，并會對實時鏈路和離線鏈路接入的數(shù)據(jù)做分鐘級對照校驗，從而實現(xiàn)實時和離線兩條鏈路保障高優(yōu)業(yè)務的容災切換。

2. 運營現(xiàn)狀

目前 vivo 內部 Kafka 集群日均處理消息數(shù)量達到了 20 萬億+，Palsar 集群日均處理消息數(shù)達到了萬億+，在這樣超大數(shù)據(jù)規(guī)模的場景下，我們還與業(yè)務團隊簽署了 SLA 四個 9 的高可用的保障協(xié)議，以確保用戶的高可用，同時實現(xiàn)降本增效。如圖所示，經過三年建設，我們的單機利用率提升了 210% 左右，Kafka 集群機器規(guī)模增長 52%，接入數(shù)據(jù)量增長 340%。

3. Kafka 部署架構

針對 Kafka 的部署架構，主要有兩種方案。方案一是使用大量物理機搭建一個超大規(guī)模的集群。方案二是以幾臺或幾十臺物理機為一個單位建構若干小集群。這兩種方各自有其優(yōu)缺點，方案一有點類似于在互聯(lián)網行業(yè)里的單體應用，而方案二更類似于微服務架構。實際兩種方案的選擇沒有絕對的好壞之分。

方案一有幾個優(yōu)點：一是它的資源利用率較高，因為它不需要對每一個小集群都預留一定的 buffer；二是當集群規(guī)模比較大以后，它應對數(shù)據(jù)業(yè)務方的業(yè)務流量突增能力比較強，而不至于在業(yè)務流量突增時，由于集群負載較高，進而反壓到客戶端，影響用戶；三是用戶體驗較好，對于業(yè)務團隊只需維護一套集群的連接信息，無需根據(jù)業(yè)務場景自己維護、辨別、使用不同的集群連接信息。但同時方案一也帶來了一些問題：一是其運維難度系數(shù)較高；二是一旦出現(xiàn)問題，故障影響面較廣；三是集群的資源隔離性較差。

方案二，這種小集群部署的優(yōu)點：一是因為每個集群規(guī)模較小，運維比較簡單，但如果總體集群的總數(shù)達到數(shù)千個，相應的運維投入也會隨之變高；二是當集群出現(xiàn)故障時，只會影響自己集群內部，故障影響范圍較小；三是集群跟集群之間嚴格做了物理隔離，資源隔離性非常好。其缺點，一是每一個集群都會需要一部分 buffer 來應對業(yè)務流量的突增，資源利用率較低；此外在應對用戶流量突增及用戶體驗等方面的能力都會較差一些。

綜合考慮上述兩個方案的優(yōu)缺點，在超大數(shù)據(jù)規(guī)模下，如果采用方案二，需要搭建和運維的 Kafka 集群數(shù)量可能達到上千個，單純靠人力運維將會是一個較大的工作量，所以 vivo 采用的是方案一的部署架構，并針對其缺點進行了改進。

（1）引入資源組，實現(xiàn)集群內節(jié)點邏輯隔離

首先針對大規(guī)模集群部署方案資源隔離性較差這一問題，通過在集群內部引入資源組實現(xiàn)集群內節(jié)點的邏輯隔離。資源組之間是邏輯隔離的，不會相互影響，從而實現(xiàn)了在同一個集群內部的機器邏輯隔離。

（2）基于項目維度實現(xiàn)智能動態(tài)限流

第二個問題是限流，限流本質是通過犧牲一部分客戶端的可用性來保障服務端的可用性。Kafka 集群的限流有幾種方式，第一種是基于客戶端的（如基于 client ID），還有一種是基于用戶端的或稱基于項目的限流。vivo 公司內部使用的是基于項目維度的限流。這種方式存在一些缺點，首先業(yè)務受損嚴重，一旦出現(xiàn)了限流的情況，用戶的流量就進不來，進而導致用戶端被反壓，數(shù)據(jù)發(fā)送失敗或消費延遲相關的問題；其次當限速閾值設置不合理時，會存在資源利用率較差和集群可用性風險，限速閾值限制較高時，集群的可用性得不到保障，限流閾值較低時，集群資源利用率較低；第三用戶會經常收到限流告警信息，用戶體驗較差；第四用戶收到限流告警后需要運維同學憑經驗綜合分析是否可以調整限速以便快速恢復業(yè)務，運維成本較高，因為限流閾值不支持自動進行動態(tài)調節(jié)，業(yè)務會頻繁與 Kafka 組件的管理團隊進行溝通去調節(jié)這個閾值。

圖中左下方的案例示意了簡單根據(jù)項目數(shù)量設定限流閾值時可能出現(xiàn)的一種情況。假設一臺單機的流量閾值是 100M/s，A、B 兩個項目均運行在這臺單機上，對應每一個項目分配到的限流閾值是 50M/s，當流量超過限流值 50M/s 后，紅色陰影區(qū)域內的流量都會被犧牲掉。但實際上多個項目之間存在流量的波動周期的差距，因而不能采取一刀切的方式根據(jù)項目數(shù)量平均分配限流閾值。

針對這種情況，一種優(yōu)化思路是對在波峰期的項目 A，尋找其同一個資源組內當前流量值較低的項目 B，從項目 B 把流量借過來，動態(tài)調高 A 項目的限流閾值，當 B 項目流量增長后，再把流量還回去。基于這樣的優(yōu)化思路，我們團隊基于統(tǒng)一的監(jiān)控平臺、統(tǒng)一的指標采集平臺，以及統(tǒng)一的告警檢測平臺實現(xiàn)了智能動態(tài)限流。

智能動態(tài)限流需要解決限流粒度、限流閾值、可用性以及資源利用率這四個維度的平衡。這里我們引入了公司內部提供的統(tǒng)一告警檢測平臺。在指標采集過程中可能需要做一些降噪處理，解決數(shù)據(jù)的突刺現(xiàn)象，基于告警檢測平臺統(tǒng)一檢測的算法可以屏蔽掉異常告警，獲得精準預警，然后基于此再去做動態(tài)的限流調整。這套智能動態(tài)限流方案使 vivo 公司內部因為限流導致業(yè)務受損的情況降低了 90%。

（3）流量均衡與資源均衡

Kafka 的架構設計上分區(qū)與 broke 節(jié)點強綁定，默認的分區(qū)分配算法不能很好的解決分區(qū)均衡性的問題，無法實現(xiàn)動態(tài)調整。如上圖所示，Kafka 默認的分區(qū)輪詢分散算法會產生兩種情況。第一種情況下，因為無法保證每一個 topic 的分區(qū)數(shù)量都能與 broker 成正比，會出現(xiàn)一些 broker 上分配的分區(qū)數(shù)比較多，一些 broker 上分配的分區(qū)數(shù)比較少的情況。另外一種情況是，即使我們保證了在不同的 broker 上分區(qū)數(shù)量是盡可能一致的，但是由于 Kafka 的分區(qū)是有狀態(tài)的，所以說它會存在一些分區(qū)流量比較大，而另一些分區(qū)的流量比較小。這兩種情況都會使 broker 之間產生很大的流量差異。

我們在做這種大規(guī)模的物理機集群部署時，都會考慮通過一臺物理機掛載多塊磁盤從而提高物理機的 IO 效率。但 Kafka 的底層架構設計上一個分區(qū)與 broker 的某一塊磁盤綁定，無法充分發(fā)揮多塊磁盤的 IO 效率。

如上圖所示，假設當前有兩個 topic，其中綠色 topic 的流量是 100MB/s，紅色 topic 的流量是 300MB/s。在 broker1 上掛載了 data1 到 data4 共 4 塊磁盤，但是當前 Topic 分區(qū) P1-L 的數(shù)據(jù)只能寫入到磁盤 data1，這帶來一個致命的缺陷，當磁盤 data1 出現(xiàn) IO 瓶頸時，即使 data2 或者 data3 是空閑的，也沒辦法將數(shù)據(jù)轉寫到 data2 或者 data3 的磁盤上面去。這樣就導致當某一塊盤上出現(xiàn)多個較大分區(qū)時，它的磁盤 IO 瓶頸就會成為這一臺機器的性能瓶頸，沒辦法很好地利用起多塊盤的 IO。

基于該缺陷，我們團隊也做了很多思考。首先，在當前分區(qū)均衡算法上注入一些與主機相關的負載因子，使其去做更好的分區(qū)計劃。在第一期，我們注入了磁盤容量、CPU、流量等負載因子，使算法能生成更好的分區(qū)分散計劃。在第二期的分區(qū)均衡算法優(yōu)化上，注入了均衡性相關的參數(shù)，如分區(qū)分散均衡、副本分散均衡等，使其能夠更好生成更加均衡的分區(qū)分散計劃。在跨機房方面我們也做了一些改進，實際情況中可能不需要所有的業(yè)務都實現(xiàn)跨機房容災，但是所有業(yè)務都必須實現(xiàn)跨交換機容災。每個公司的機房建設不太一樣，我們公司的機房建設中，交換機是單上聯(lián)的，所以在交換機這個層面可能存在單點故障的風險。因此在后面交換機風險改進方案里，我們也將交換機信息注入到分區(qū)均衡算法中，從而規(guī)避交換機的單點故障風險。未來我們也在思考跨機房實現(xiàn)分區(qū)分散，機房與機房之間的網絡延遲降低到可以接受的范圍之內可輕松實現(xiàn)。

其實 Kafka 核心架構帶來的問題遠不止上述提到的幾點，尤其是在超大數(shù)據(jù)規(guī)模場景下，問題表現(xiàn)得尤為明顯。第一是 Kafka 資源利用率比較低，因為 Kafka 無法根據(jù)未來的流量增長進行預測，所以也無法實現(xiàn)長期的均衡。第二是 Kafka 故障恢復慢，因其分區(qū)數(shù)據(jù)是和磁盤綁定的，當進行數(shù)據(jù)遷移時，遷移周期會比較長，尤其當一塊磁盤上有幾 T 數(shù)據(jù)或一臺 broker 上有幾十 T數(shù)據(jù)時，磁盤故障需要做踢盤或 broker 節(jié)點故障需要做下線時，需要遷移幾 T 或幾十 T 數(shù)據(jù)。數(shù)據(jù)遷移過程中還需要考慮不能影響實時業(yè)務數(shù)據(jù)的寫入，遷移周期一般都是周級。第三是 Kafka 故障率高，均衡時會做數(shù)據(jù)的拷貝、消費延遲時會讀磁盤數(shù)據(jù)導致磁盤 IO 受到影響，一旦出現(xiàn)這個問題，對實時數(shù)據(jù)的寫入也會存在影響，所以它的故障率會比較高。第四是無法快速響應業(yè)務增長，當集群擴容后需要先對分區(qū)做一次均衡，然后做流量歷史數(shù)據(jù)的遷移，全部遷移完后才可以將實時數(shù)據(jù)寫入到擴容機器上，整個擴容的周期較長。一般對于 Kafka 集群的擴容是以天或者以周為單位進行的。

基于以上所有的缺陷，我們發(fā)現(xiàn)核心問題在于 Kafka 數(shù)據(jù)存儲架構設計上，無法通過擴展能力的建設解決上述缺陷。Kafka 的架構設計沒辦法做到存算分離、分層存儲、分散存儲等。所以我們考慮要對整個分布式消息中間件做引擎的升級，解決方案有兩種，第一是基于 Kafka 的原有架構進行改造，第二是引入下一代的云原生分布式消息中間件 Pulsar。

二、Pulsar 核心架構升級

Pulsar 是基于云原生理念設計的分布式消息流組件，它在存儲層和計算層實現(xiàn)了存算分離，并且其同一分區(qū)的數(shù)據(jù)可以分散成多個 segment，每個 segment 可以落到不同的 bookie 存儲節(jié)點上，實現(xiàn)了在存儲節(jié)點上的分散，也可以實現(xiàn)在磁盤之間的分散。Pulsar 的核心架構具有以下幾個核心優(yōu)勢：

• 存儲與計算分離。
• 存儲、計算獨立擴展。
• 秒級擴縮容。
• 秒級的故障恢復。
• 屏蔽硬件故障。

Pulsar 支持在硬件上面的秒級恢復。如圖所示，左邊是 Kafka 的架構，當磁盤發(fā)生故障后，必須去副本所在的 broker 節(jié)點把數(shù)據(jù)先同步一份，之后才可以把實時流量數(shù)據(jù)寫到我們的 broker 磁盤上。但是數(shù)據(jù)同步的周期性較長，可能要一天或者更長的時間，在這段時間之內，如果分區(qū)的副本數(shù)設置為 2，分區(qū)都處于單副本運行的高風險狀態(tài)。而 Pulsar 可以實現(xiàn)秒級的恢復，因為它不需要去做歷史數(shù)據(jù)的同步，分區(qū)流量可以秒級的轉移到其他磁盤或其他的 broker 上。Pulsar 后臺有一個缺副本的發(fā)現(xiàn)機制，補齊歷史數(shù)據(jù)。在實時場景下，我們更關注對實時寫入的數(shù)據(jù)做冗余的高可用保障，反而對于歷史數(shù)據(jù)同步性的要求不高。

Pulsar 具備秒級擴縮容的能力，這主要基于它存儲與計算分離的架構。因其存儲計算分離，它的 broker 和 bookie 也是分離的。一個無狀態(tài)的服務實現(xiàn)秒級的擴縮容是很簡單的，基于 K8S 或者 docker 來講的話，只需要彈一個 Pod，然后去拉取一個鏡像，重啟后就可以完成秒級的彈性伸縮。Pulsar 在 broker 層是無狀態(tài)的設計，使其它天然具備了秒級擴縮容能力。在 bookie 層，可以將其看作存儲層，它也可以做到秒級的擴縮容，只要擴容 bookie 節(jié)點被 broker 感知到以后，可以實時地將 broker 的流量寫到 bookie 節(jié)點上進行持久化的存儲。

Pulsar 核心架構優(yōu)勢還體現(xiàn)在客戶端內存分配上。在 Kafka 的架構下，尤其是在指定 key 的場景下，如果 broker 節(jié)點出現(xiàn)宕機或者響應緩慢的情況，就會反壓客戶端，導致客戶端 buffer pool 被故障分區(qū)的數(shù)據(jù)打滿，進而導致雪崩的現(xiàn)象。因為一個分區(qū)不可用，導致整個 topic 的所有分區(qū)都不可用甚至當前 producer 涉及的所有 topic 的所有分區(qū)都不可用。左下方是我們公司內部一次故障時的流量監(jiān)控曲線，可以看到，Kafka 單個 broker 節(jié)點一場后，整個資源組里所有 topic 的流量都無法寫入，就是因為故障節(jié)點直接把客戶端內存占滿后，正常分區(qū)的數(shù)據(jù)沒辦法分配到內存，無法寫入到服務端。對于這個問題，Pulsar 做了架構上的改造。客戶端內存的隔離粒度做到了分區(qū)級，當右上圖 broker2 出了問題，即使分區(qū)的 deque 被打滿以后，也不會去占用整個客戶端內存，消息還是能通過其他可用分區(qū)發(fā)送出去。右下方圖展示了我們故障演練的情況，它可以秒級恢復到其他 broker 節(jié)點上。

Pulsar 和 Kafka 的性能對比可以參見下圖。

三、高可用保障及可觀測

高可用保障是我們的生命線，沒有高可用，其他一切工作都是沒有意義的。

高可用保障主要圍繞故障展開，包括事前預防故障的發(fā)生、事后快速恢復，以及故障解決后應該怎樣復盤并提出改進措施。我們在事前，會基于對技術架構的理解做故障演練和測試，在流程規(guī)范和平臺工具方面進行保障。事中最核心的是整個監(jiān)控告警體系，在此基礎上進行質量運營，及時發(fā)現(xiàn)、響應，最終支撐組件在超大數(shù)據(jù)規(guī)模下的高可用。

我們的監(jiān)控告警體系可以分為多個維度。在基礎設施層，實現(xiàn)了對機房、網絡、交換機的監(jiān)控；在主機層，實現(xiàn)了對 CPU、內存、磁盤流量相關的監(jiān)控；在服務層，尤其是在 Kafka 的服務層，會對 GC、warning 日志或 error 日志進行監(jiān)控告警；在用戶層，支持限流告警、延遲告警以及流量突增的告警。以上都是為了在故障發(fā)生前一步告警，以便及時介入人工干預，避免故障發(fā)生。所有告警指標的采集都由統(tǒng)一檢測平臺，經過降噪，統(tǒng)一發(fā)出異常告警，觸達我們的用戶、運維以及管理人員。在進行監(jiān)控告警體系建設時，比起頻繁告警，我們更重視告警的精準度，尤其是在有限的人力運維情況下，太多的告警會導致運維人員對告警的敏感度下降，忽視關鍵告警，最終導致故障的發(fā)生。

因為人具有主觀能動性，人為因素是導致故障的重要誘因之一，所以我們需要一套貫穿于整個事前事中以及事后的規(guī)范體系來規(guī)范人的行為。包括事前對代碼管理、方案和代碼的評審、發(fā)布和變更、變更灰度優(yōu)先級、值班等的規(guī)范，事中對故障處理的規(guī)范、預案執(zhí)行的規(guī)范、日常運維的規(guī)范，事后故障的管理規(guī)范，以及故障的復盤規(guī)范等，通過一套全生命周期的規(guī)范來盡可能規(guī)避人為因素導致的故障。

Pulsar 作為新一代云原生分布式消息中間件，架構設計非常優(yōu)秀，但是作為新興組件缺乏長期超大規(guī)模數(shù)據(jù)處理的驗證，在穩(wěn)定性上也存在較多問題。基于我們平臺的高可用體系，以及監(jiān)控告警體系的實踐，經過故障演練和自測，我們在近兩年間解決了 Pulsar 27 個嚴重影響穩(wěn)定性的問題，19 個重要問題，44 個一般問題。目前在達到 2 萬億日均處理消息量的情況下，我們做到了全年無故障。

可觀測對于用戶來講，可能關注的是 topic 的流量指標，尤其是 top 級別的流量指標，根據(jù)觀測結果決定是否需要對某一些 topic 做治理，或者判斷該 topic 消耗的成本是不是與它所帶來的收益正相關。此外我們還會關注消費延遲指標。我們的可觀測平臺，能夠實時定位到用戶某一臺 IP 節(jié)點上的機器出現(xiàn)消費延遲的情況，方便我們在數(shù)據(jù)消費延遲的時候能夠快速定位到問題。

我們的告警實現(xiàn)了從數(shù)據(jù)接入，到檢測配置，再到告警配置以及告警處置四個方面的閉環(huán)，相關的配置都可以通過平臺進行配置操作，對告警的處置、告警的回調、告警的詳情都可以通過可觀測的告警平臺進行查看。

最后對于運維管理人員而言，我們更關注的是當遇到故障后如何快速恢復，以及是否能通過一些日常巡檢來發(fā)現(xiàn)當前系統(tǒng)存在的異常。因此我們在運維管理方面，也實現(xiàn)了可觀測，包括對 topic 的流量監(jiān)控，對整個資源組的 GC 監(jiān)控，以及對延遲的監(jiān)控等。

四、vivo 架構未來規(guī)劃

最后談一下 Pulsar 未來規(guī)劃。Pulsar 作為下一代云原生的分布式消息中間件一定會成為未來的主流。因此我們對其分層存儲以及函數(shù)式計算、全鏈路監(jiān)控會重點規(guī)劃。另外如何應用 Pulsar SQL，以及 Pulsar function 使其更好地賦能業(yè)務也是我們未來需要去考慮的一些點。最后，關于 Pulsar 容器化的問題我們也有一定的思考，前文在介紹 Pulsar 部署架構的部分提到了大量小集群運維，采用純人力的運維不太現(xiàn)實，如果說未來能夠實現(xiàn)容器化，由容器化來幫助我們做集群管理，就能大量節(jié)省運維人力成本。