一、vivo 架構(gòu)演進實踐

1. 業(yè)務(wù)背景

首先來介紹一下相關(guān)業(yè)務(wù)背景。

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

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

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

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

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

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

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

2. 運營現(xiàn)狀

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

3. Kafka 部署架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如上圖所示，假設(shè)當前有兩個 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ù)轉(zhuǎn)寫到 data2 或者 data3 的磁盤上面去。這樣就導(dǎo)致當某一塊盤上出現(xiàn)多個較大分區(qū)時，它的磁盤 IO 瓶頸就會成為這一臺機器的性能瓶頸，沒辦法很好地利用起多塊盤的 IO。

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

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

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

二、Pulsar 核心架構(gòu)升級

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

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

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

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

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

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

三、高可用保障及可觀測

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

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

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

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

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

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

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

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

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

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