作者丨Prince Mahajan

編譯丨諾亞

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

如何通過(guò)云原生設(shè)計(jì)提升Apache Kafka引擎的性能、可用性和成本效率？本文作者圍繞這一中心議題，介紹了一項(xiàng)名為Kora的事件流處理平臺(tái)的重新設(shè)計(jì)過(guò)程及關(guān)鍵技術(shù)創(chuàng)新。文章首先指出成功云原生平臺(tái)的必備特性，包括多租戶(hù)支持、易于擴(kuò)展、數(shù)據(jù)驅(qū)動(dòng)管理、跨客戶(hù)安全隔離以及支持快速創(chuàng)新。Kora的設(shè)計(jì)旨在滿(mǎn)足這些需求，同時(shí)保持與現(xiàn)有Kafka協(xié)議的兼容性，并在多云環(huán)境下提供一致體驗(yàn)。

當(dāng)我們著手重建托管Apache Kafka服務(wù)核心的引擎時(shí)，我們知道必須滿(mǎn)足成功云原生平臺(tái)的幾個(gè)獨(dú)特要求。這些系統(tǒng)需要從底層開(kāi)始就是多租戶(hù)的，能夠輕松擴(kuò)展以服務(wù)于成千上萬(wàn)的客戶(hù)，并且主要由數(shù)據(jù)驅(qū)動(dòng)的軟件而非人工操作員來(lái)管理。它們還應(yīng)確保在工程師可以持續(xù)快速創(chuàng)新的環(huán)境中，跨客戶(hù)具有強(qiáng)大的隔離性和安全性，即使工作負(fù)載不可預(yù)測(cè)。

去年，我們展示了Kafka引擎的重新設(shè)計(jì)。我們?cè)O(shè)計(jì)和實(shí)施的大部分內(nèi)容也將適用于其他構(gòu)建大規(guī)模分布式云系統(tǒng)的團(tuán)隊(duì)，如數(shù)據(jù)庫(kù)或存儲(chǔ)系統(tǒng)。我們希望與更廣泛的社區(qū)分享我們的經(jīng)驗(yàn)，希望這些經(jīng)驗(yàn)?zāi)軐?duì)從事其他項(xiàng)目的人有所幫助。

1.Kafka引擎重新設(shè)計(jì)的關(guān)鍵考慮因素

我們的高層級(jí)目標(biāo)可能與你自己基于云的系統(tǒng)的目標(biāo)相似：提高性能和彈性，增加對(duì)我們自己和客戶(hù)的成本效率，并在多個(gè)公有云上提供一致的體驗(yàn)。我們還有一個(gè)額外的要求，即與當(dāng)前版本的Kafka協(xié)議保持100%兼容。

我們重新設(shè)計(jì)的Kafka引擎名為Kora，是一個(gè)事件流處理平臺(tái)，在AWS、Google Cloud和Azure的70多個(gè)區(qū)域運(yùn)行著數(shù)萬(wàn)個(gè)集群。你可能不會(huì)立即達(dá)到這樣的規(guī)模，但下面描述的許多技術(shù)仍然適用。

以下是我們?cè)谛碌腒ora設(shè)計(jì)中實(shí)施的五個(gè)關(guān)鍵創(chuàng)新。如果你想深入了解其中任何一個(gè)，我們?cè)谶@個(gè)主題上發(fā)表了一篇白皮書(shū)，該白皮書(shū)在2023年的國(guó)際超大數(shù)據(jù)庫(kù)會(huì)議(VLDB)上獲得了最佳行業(yè)論文獎(jiǎng)。

2.使用邏輯“單元”實(shí)現(xiàn)可擴(kuò)展性和隔離性

要構(gòu)建高可用性和水平可擴(kuò)展的系統(tǒng)，你需要一個(gè)使用可擴(kuò)展和可組合構(gòu)建塊構(gòu)建的架構(gòu)。具體來(lái)說(shuō)，一個(gè)可擴(kuò)展系統(tǒng)所做的工作應(yīng)隨著系統(tǒng)規(guī)模的增加而線性增長(zhǎng)。原始的Kafka架構(gòu)沒(méi)有滿(mǎn)足這個(gè)標(biāo)準(zhǔn)，因?yàn)樵S多負(fù)載方面的增長(zhǎng)與系統(tǒng)規(guī)模的增加是非線性的。

例如，隨著集群規(guī)模的增加，連接數(shù)呈二次方增長(zhǎng)，因?yàn)樗锌蛻?hù)端通常都需要與所有代理通信。類(lèi)似地，由于每個(gè)代理通常在所有其他代理上都有跟隨者，復(fù)制開(kāi)銷(xiāo)也呈二次方增長(zhǎng)。最終結(jié)果是，添加代理會(huì)導(dǎo)致開(kāi)銷(xiāo)的不成比例增加，相對(duì)于它們帶來(lái)的額外計(jì)算/存儲(chǔ)能力。

第二個(gè)挑戰(zhàn)是確保租戶(hù)之間的隔離。特別是，一個(gè)表現(xiàn)不佳的租戶(hù)可能會(huì)對(duì)集群中每個(gè)其他租戶(hù)的性能和可用性產(chǎn)生負(fù)面影響。即使有有效的限制和節(jié)流，可能總會(huì)有一些負(fù)載模式是有問(wèn)題的。即使客戶(hù)端表現(xiàn)良好，節(jié)點(diǎn)的存儲(chǔ)也可能會(huì)被降級(jí)。在集群中的隨機(jī)分布，這將影響所有租戶(hù)和潛在的所有應(yīng)用程序。

我們使用一種稱(chēng)為單元的邏輯構(gòu)建塊解決了這些挑戰(zhàn)。我們將集群劃分為一組跨越可用性區(qū)域的單元。租戶(hù)被隔離到單個(gè)單元中，這意味著該租戶(hù)擁有的每個(gè)分區(qū)的副本都被分配到該單元中的代理上。這也意味著復(fù)制被限制在該單元內(nèi)的代理之間。向單元中添加代理在單元級(jí)別上帶來(lái)了與以前相同的問(wèn)題，但現(xiàn)在我們有了一個(gè)選項(xiàng)，即在不增加開(kāi)銷(xiāo)的情況下在集群中創(chuàng)建新的單元。此外，這為我們提供了一種處理嘈雜租戶(hù)的方法。我們可以將租戶(hù)的分區(qū)移動(dòng)到隔離單元中。

為了衡量這個(gè)解決方案的有效性，我們?cè)O(shè)置了一個(gè)包含24個(gè)代理和六個(gè)代理單元的實(shí)驗(yàn)性集群（有關(guān)完整配置的詳細(xì)信息，請(qǐng)參見(jiàn)我們的白皮書(shū)）。當(dāng)我們運(yùn)行基準(zhǔn)測(cè)試時(shí)，集群負(fù)載——我們?yōu)楹饬縆afka集群負(fù)載而設(shè)計(jì)的一個(gè)自定義指標(biāo)——在使用單元時(shí)為53%，而不使用單元時(shí)為73%。

3.通過(guò)分層架構(gòu)優(yōu)化不同存儲(chǔ)類(lèi)型使用

通過(guò)將架構(gòu)分層以?xún)?yōu)化不同存儲(chǔ)類(lèi)型的使用，我們?cè)谔岣咝阅芎涂煽啃缘耐瑫r(shí)降低了成本。這源于我們分離計(jì)算和存儲(chǔ)的方式，主要是兩方面：使用對(duì)象存儲(chǔ)保存冷數(shù)據(jù)，以及使用塊存儲(chǔ)代替實(shí)例存儲(chǔ)保存更頻繁訪問(wèn)的數(shù)據(jù)。

這種分層架構(gòu)使我們能夠增強(qiáng)彈性——當(dāng)只需要重新分配熱數(shù)據(jù)時(shí)，分區(qū)的重新分配變得容易得多。使用EBS卷而不是實(shí)例存儲(chǔ)也提高了持久性，因?yàn)榇鎯?chǔ)卷的生命周期與相關(guān)虛擬機(jī)的生命周期解耦。

最重要的是，分層允許我們顯著改善成本和性能。成本降低是因?yàn)閷?duì)象存儲(chǔ)是存儲(chǔ)冷數(shù)據(jù)更經(jīng)濟(jì)實(shí)惠和可靠的選擇。而性能提高是因?yàn)橐坏?shù)據(jù)被分層，我們可以將熱數(shù)據(jù)置于高性能存儲(chǔ)卷中，如果沒(méi)有分層，這將是成本高昂的。

4.使用抽象統(tǒng)一多云體驗(yàn)

對(duì)于計(jì)劃在多個(gè)云上運(yùn)營(yíng)的任何服務(wù)來(lái)說(shuō)，提供統(tǒng)一且一致的跨云客戶(hù)體驗(yàn)至關(guān)重要，但這在幾個(gè)方面都是具有挑戰(zhàn)性的。云服務(wù)復(fù)雜，即使它們遵循標(biāo)準(zhǔn)，不同云和實(shí)例之間仍存在差異。實(shí)例類(lèi)型、實(shí)例可用性和甚至對(duì)于類(lèi)似云服務(wù)的計(jì)費(fèi)模式都可能以微妙但重要的方式有所不同。例如，Azure塊存儲(chǔ)不允許獨(dú)立配置磁盤(pán)吞吐量/IOPS，因此需要配置大容量磁盤(pán)來(lái)擴(kuò)展IOPS。相比之下，AWS和GCP允許你獨(dú)立調(diào)整這些變量。

許多SaaS提供商回避這種復(fù)雜性，讓客戶(hù)自己擔(dān)心實(shí)現(xiàn)一致性能所需的配置細(xì)節(jié)。顯然，這并不理想，因此在Kora中，我們開(kāi)發(fā)了抽象化的方法來(lái)消除這些差異。

我們引入了三種抽象，使客戶(hù)能夠遠(yuǎn)離實(shí)現(xiàn)細(xì)節(jié)，專(zhuān)注于更高層次的應(yīng)用程序?qū)傩?。這些抽象可以幫助大幅簡(jiǎn)化服務(wù)并限制客戶(hù)需要自行回答的問(wèn)題。

5.自動(dòng)化緩解循環(huán)對(duì)抗性能退化

故障處理對(duì)于可靠性至關(guān)重要。即便是在云端，由于云提供商中斷、軟件錯(cuò)誤、磁盤(pán)損壞、配置錯(cuò)誤或其他原因，故障也是不可避免的。這些可能是完全或部分故障，但無(wú)論哪種情況，都必須迅速解決，以免影響性能或系統(tǒng)訪問(wèn)。

不幸的是，如果你正在大規(guī)模運(yùn)營(yíng)云平臺(tái)，手動(dòng)檢測(cè)和處理這些故障是不可能的。它會(huì)占用過(guò)多的操作員時(shí)間，并且意味著可能無(wú)法快速解決問(wèn)題以維持服務(wù)水平協(xié)議。

為了解決這個(gè)問(wèn)題，我們構(gòu)建了一個(gè)解決方案來(lái)處理所有此類(lèi)基礎(chǔ)設(shè)施退化的案例。具體來(lái)說(shuō)，我們構(gòu)建了一個(gè)反饋循環(huán)，包括一個(gè)退化檢測(cè)組件，該組件從集群收集指標(biāo)并使用它們來(lái)決定是否有任何組件發(fā)生故障以及是否需要采取行動(dòng)。這使我們能夠在不需任何手動(dòng)操作員介入的情況下，每周自動(dòng)處理數(shù)百次退化。

實(shí)現(xiàn)多種反饋循環(huán)跟蹤代理性能并在必要時(shí)采取行動(dòng)。當(dāng)發(fā)現(xiàn)問(wèn)題時(shí)，會(huì)標(biāo)記為特定的代理健康狀態(tài)，并針對(duì)每個(gè)狀態(tài)采用相應(yīng)的緩解策略。這三個(gè)反饋循環(huán)分別解決了本地磁盤(pán)問(wèn)題、外部連接問(wèn)題和代理退化問(wèn)題。

• 監(jiān)控：一種從外部角度跟蹤每個(gè)代理性能的方法。我們經(jīng)常進(jìn)行探測(cè)以跟蹤。
• 聚合：在某些情況下，我們聚合指標(biāo)以確保相對(duì)于其他代理，退化是可察覺(jué)的
• React：特定于 Kafka 的機(jī)制，用于將代理排除在復(fù)制協(xié)議之外或?qū)㈩I(lǐng)導(dǎo)權(quán)從復(fù)制協(xié)議中移走。

確實(shí)，我們的自動(dòng)化緩解每月在所有三大云提供商中檢測(cè)并自動(dòng)緩解數(shù)千次部分退化，節(jié)省了寶貴的操作員時(shí)間，同時(shí)確保對(duì)客戶(hù)的影響最小。

6.平衡有狀態(tài)服務(wù)以實(shí)現(xiàn)性能和效率

在任何有狀態(tài)服務(wù)中跨服務(wù)器平衡負(fù)載是一個(gè)難題，直接影響到客戶(hù)體驗(yàn)的服務(wù)質(zhì)量。負(fù)載分布不均會(huì)導(dǎo)致客戶(hù)受到最繁忙服務(wù)器提供的延遲和吞吐量限制。有狀態(tài)服務(wù)通常有一組鍵，你需要平衡這些鍵的分布，以便總體負(fù)載均勻分布在服務(wù)器上，從而客戶(hù)能夠從系統(tǒng)中獲得最大性能和最低成本。

例如，Kafka運(yùn)行的狀態(tài)性代理負(fù)責(zé)平衡分區(qū)及其副本到各個(gè)代理的分配。根據(jù)客戶(hù)活動(dòng)，這些分區(qū)上的負(fù)載可能會(huì)以難以預(yù)測(cè)的方式激增或下降。這需要一套指標(biāo)和啟發(fā)式方法來(lái)確定如何放置分區(qū)以最大化效率和利用率。我們通過(guò)一個(gè)平衡服務(wù)來(lái)實(shí)現(xiàn)這一點(diǎn)，該服務(wù)跟蹤來(lái)自多個(gè)代理的一套指標(biāo)，并持續(xù)在后臺(tái)工作以重新分配分區(qū)。

重新平衡分配需要謹(jǐn)慎進(jìn)行。過(guò)于積極的重新平衡會(huì)因這些重新分配產(chǎn)生的額外工作而破壞性能并增加成本。而過(guò)慢的重新平衡則會(huì)讓系統(tǒng)在修復(fù)不平衡之前明顯退化。我們必須實(shí)驗(yàn)了很多啟發(fā)式方法，以收斂到一個(gè)適合各種工作負(fù)載的適當(dāng)反應(yīng)水平。

有效平衡的影響可能是巨大的。我們的一位客戶(hù)在為他們啟用重新平衡后，負(fù)載大約減少了25%。類(lèi)似地，另一位客戶(hù)由于重新平衡，延遲大幅減少。

7.精心設(shè)計(jì)的云原生服務(wù)的優(yōu)勢(shì)

如果你正在為你的組織構(gòu)建云原生基礎(chǔ)設(shè)施，無(wú)論是使用新代碼還是使用像Kafka這樣的現(xiàn)有開(kāi)源軟件，我們希望本文中描述的技術(shù)能幫助你實(shí)現(xiàn)性能、可用性和成本效率的目標(biāo)。

為了測(cè)試Kora的性能，我們?cè)谙嗤挠布线M(jìn)行了小規(guī)模實(shí)驗(yàn)，比較了Kora和我們的全云平臺(tái)與開(kāi)源Kafka。我們發(fā)現(xiàn)Kora提供了更大的彈性，擴(kuò)展速度提高了30倍；相比我們自管理客戶(hù)或其他云服務(wù)的故障率，可用性提高了10倍以上；并且延遲明顯低于自管理的Kafka。雖然Kafka仍然是運(yùn)行開(kāi)源數(shù)據(jù)流系統(tǒng)的最佳選擇，但對(duì)于尋求云原生體驗(yàn)的人來(lái)說(shuō)，Kora是一個(gè)很好的選擇。

參考鏈接：https://www.infoworld.com/article/3715426/5-tips-for-building-highly-scalable-cloud-native-apps.html