譯者 | 李睿

審校 | 重樓

當(dāng)開發(fā)人員著手重建托管Apache Kafka服務(wù)的核心引擎時(shí)，需要滿足一些獨(dú)特的需求，這些需求是成功的云原生平臺(tái)的特征。這些系統(tǒng)必須是多租戶的，易于擴(kuò)展以服務(wù)數(shù)千個(gè)客戶，并且主要由數(shù)據(jù)驅(qū)動(dòng)的軟件而不是運(yùn)行人員進(jìn)行管理。它們還應(yīng)在工程師可以繼續(xù)快速創(chuàng)新的環(huán)境中，為工作負(fù)載不可預(yù)測(cè)的客戶提供強(qiáng)大的隔離和安全性。

軟件服務(wù)提供商Confluent公司在去年展示了Kafka引擎的重新設(shè)計(jì)。其設(shè)計(jì)和實(shí)現(xiàn)的大部分內(nèi)容適用于其他構(gòu)建大規(guī)模分布式云計(jì)算系統(tǒng)的團(tuán)隊(duì)，例如數(shù)據(jù)庫或存儲(chǔ)系統(tǒng)。Confluent公司首席工程師Prince Mahajan表示，希望與更廣泛的社區(qū)分享所學(xué)到的知識(shí)，可以使那些從事其他項(xiàng)目的人受益。

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

Confluent公司的目標(biāo)很可能與一些企業(yè)基于云計(jì)算的系統(tǒng)目標(biāo)相似：提高性能和彈性，為自己和客戶提高成本效益，并在多個(gè)公共云平臺(tái)之間提供一致的體驗(yàn)。此外，還增加了與當(dāng)前版本的Kafka協(xié)議保持100%兼容的要求。

該公司重新設(shè)計(jì)的 Kafka 引擎（稱為 Kora）是一個(gè)事件流平臺(tái)，在AWS、Google Cloud和Azure的70多個(gè)可用性區(qū)域運(yùn)行數(shù)萬個(gè)集群。雖然企業(yè)可能不會(huì)立即以這種規(guī)模進(jìn)行操作，但許多技術(shù)仍然適用。

以下是Confluent公司在新的Kora設(shè)計(jì)中實(shí)現(xiàn)的五個(gè)關(guān)鍵創(chuàng)新：

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

要構(gòu)建高可用性和水平可擴(kuò)展的系統(tǒng)，需要使用可擴(kuò)展和可組合的構(gòu)建塊構(gòu)建的架構(gòu)。具體地說，可擴(kuò)展系統(tǒng)所做的工作應(yīng)該隨著系統(tǒng)規(guī)模的增加而線性增長。最初的Kafka架構(gòu)并不符合這個(gè)標(biāo)準(zhǔn)，因?yàn)樨?fù)載的許多方面隨著系統(tǒng)規(guī)模呈非線性增長。

例如，隨著集群大小的增加，連接數(shù)量將呈二次方增長，因?yàn)樗锌蛻舳送ǔ６夹枰c所有代理進(jìn)行通信。同樣，復(fù)制開銷也呈二次方增長，因?yàn)槊總€(gè)代理通常在所有其他代理上都有追隨者。最終的結(jié)果是，相對(duì)于帶來的額外計(jì)算/存儲(chǔ)容量，添加代理會(huì)導(dǎo)致開銷不成比例地增加。

第二個(gè)挑戰(zhàn)是確保租戶之間的隔離。特別是，行為不端的租戶可能會(huì)對(duì)集群中其他租戶的性能和可用性產(chǎn)生負(fù)面影響。即使進(jìn)行有效的限制和節(jié)流，也可能總是存在一些有問題的負(fù)載模式。而且，即使客戶端運(yùn)行良好，節(jié)點(diǎn)的存儲(chǔ)空間也可能會(huì)減少。如果在集群中隨機(jī)分布，這將影響所有租戶，甚至可能影響所有應(yīng)用程序。

Confluent公司使用一種稱為單元的邏輯構(gòu)建塊解決了這些挑戰(zhàn)。將集群劃分為一組單元，這些單元交叉切入可用性區(qū)域。租戶被隔離到單個(gè)計(jì)算單元，這意味著該租戶擁有的每個(gè)分區(qū)的副本被分配給該計(jì)算單元中的代理，復(fù)制與該單元內(nèi)的代理隔離。在單元級(jí)別上，向單元添加代理會(huì)帶來與以前相同的問題，但是現(xiàn)在可以選擇在集群中創(chuàng)建新的計(jì)算單元，而不會(huì)增加開銷。此外，這提供了一種處理嘈雜租戶的方法，可以將租戶的分區(qū)移到隔離區(qū)。

為了評(píng)估這個(gè)解決方案的有效性，Confluent公司設(shè)置了一個(gè)具有 6 個(gè)代理單元的實(shí)驗(yàn)性 24 個(gè)代理集群。當(dāng)運(yùn)行基準(zhǔn)測(cè)試時(shí)，集群負(fù)載(為測(cè)量Kafka集群上的負(fù)載而設(shè)計(jì)的自定義指標(biāo))在有單元時(shí)為53%，而在沒有單元時(shí)為73%。

2.平衡存儲(chǔ)類型以優(yōu)化熱數(shù)據(jù)和冷數(shù)據(jù)

云計(jì)算的一個(gè)關(guān)鍵優(yōu)點(diǎn)是，它提供了具有不同成本和性能特征的各種存儲(chǔ)類型。我們可以利用這些不同的存儲(chǔ)類型在架構(gòu)中提供最佳的性價(jià)比權(quán)衡。

塊存儲(chǔ)提供了控制各種性能維度的持久性和靈活性，例如IOPS(每秒輸入/輸出操作)和延遲。然而，隨著規(guī)模的增加，低延遲磁盤的成本會(huì)越來越高，這使得它們不適合存儲(chǔ)冷數(shù)據(jù)。相比之下，Amazon S3、Microsoft Azure Blob storage和Google GCS等對(duì)象存儲(chǔ)服務(wù)成本低，可擴(kuò)展性強(qiáng)，但延遲比塊存儲(chǔ)高。如果需要寫入大量小文件，它們也會(huì)很快變得昂貴。

通過對(duì)架構(gòu)進(jìn)行分層以優(yōu)化這些不同存儲(chǔ)類型的使用，在降低成本的同時(shí)提高了性能和可靠性。這源于將存儲(chǔ)與計(jì)算分離的方式，主要有兩種方式：對(duì)冷數(shù)據(jù)使用對(duì)象存儲(chǔ)，對(duì)更頻繁訪問的數(shù)據(jù)使用塊存儲(chǔ)而不是實(shí)例存儲(chǔ)。

這種分層架構(gòu)允許提高彈性——當(dāng)只需要重新分配熱數(shù)據(jù)時(shí)，重新分配分區(qū)變得容易得多。使用EBS卷代替實(shí)例存儲(chǔ)還可以提高持久性，因?yàn)榇鎯?chǔ)卷的生命周期與關(guān)聯(lián)虛擬機(jī)的生命周期是分離的。

最重要的是，分層能夠顯著降低成本和提高性能。降低成本是因?yàn)閷?duì)象存儲(chǔ)是存儲(chǔ)冷數(shù)據(jù)的更實(shí)惠和可靠的選擇。而且性能也得到了提高，因?yàn)橐坏?shù)據(jù)分層，就可以將熱數(shù)據(jù)放在高性能的存儲(chǔ)卷中，如果沒有分層，其成本將會(huì)非常昂貴。

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

對(duì)于任何計(jì)劃在多個(gè)云平臺(tái)上運(yùn)行的服務(wù)，跨云提供統(tǒng)一的、一致的客戶體驗(yàn)至關(guān)重要。由于多種原因，這很難實(shí)現(xiàn)。云計(jì)算服務(wù)是復(fù)雜的，即使它們符合標(biāo)準(zhǔn)，云服務(wù)和實(shí)例之間仍然存在差異。類似云服務(wù)的實(shí)例類型、實(shí)例可用性甚至計(jì)費(fèi)模型都可能以細(xì)微但有影響的方式發(fā)生變化。例如，Azure塊存儲(chǔ)不允許獨(dú)立配置磁盤吞吐量/IOPS，因此需要配置更大的磁盤來擴(kuò)展IOPS。相比之下，AWS和谷歌云允許用戶獨(dú)立地調(diào)整這些變量。

許多 SaaS 提供商都對(duì)這種復(fù)雜性不屑一顧，讓客戶擔(dān)心實(shí)現(xiàn)一致性能所需的配置細(xì)節(jié)。這顯然并不理想，所以對(duì)于Kora，Confluent公司開發(fā)了抽象差異的方法。

Confluent公司引入了三個(gè)抽象，使客戶能夠遠(yuǎn)離實(shí)現(xiàn)細(xì)節(jié)，并專注于更高級(jí)別的應(yīng)用程序?qū)傩?。這些抽象可以幫助顯著地簡化服務(wù)，并限制客戶需要自己回答的問題。

（1）邏輯Kafka集群是訪問控制和安全的單元。這是客戶管理的同一個(gè)實(shí)體，無論是在多租戶環(huán)境中還是在專用環(huán)境中。

（2）Confluent Kafka Unit (CKU)是Confluent公司客戶的容量單位(也是成本單位)。CKU 表示為客戶可見指標(biāo)，例如入口和出口吞吐量，以及請(qǐng)求速率、連接等一些指標(biāo)上限。

（3）最后，將集群上的負(fù)載抽象為一個(gè)稱為集群負(fù)載的統(tǒng)一指標(biāo)。這可以幫助客戶決定是擴(kuò)大還是縮小其集群。

有了這些抽象，客戶就不需要擔(dān)心底層的實(shí)現(xiàn)細(xì)節(jié)，服務(wù)提供商可以在新的硬件和軟件選項(xiàng)可用時(shí)不斷優(yōu)化性能和成本。

4.自動(dòng)化緩解循環(huán)以應(yīng)對(duì)退化

故障處理對(duì)可靠性至關(guān)重要。即使在云中，故障也是不可避免的，無論是由于云服務(wù)中斷、軟件錯(cuò)誤、磁盤損壞、錯(cuò)誤配置還是其他原因。這些可能是完全故障，也可能是部分故障，但無論哪種情況，都必須迅速解決，以避免影響性能或?qū)ο到y(tǒng)的訪問。

遺憾的是，如果企業(yè)正在大規(guī)模運(yùn)行云平臺(tái)，則無法人工檢測(cè)和解決這些故障。這將占用運(yùn)營人員太多的時(shí)間，并且可能意味著故障的解決速度不夠快，無法維持服務(wù)級(jí)別協(xié)議。

為了解決這個(gè)問題，Confluent公司構(gòu)建了一個(gè)解決方案來處理所有這些基礎(chǔ)設(shè)施退化的情況。具體來說，構(gòu)建了一個(gè)由退化檢測(cè)器組件組成的反饋循環(huán)，該組件從集群收集指標(biāo)，并使用它們來決定是否有任何組件出現(xiàn)故障，以及是否需要采取任何措施。這使Confluent公司在不需要任何人工操作的情況下，每周能夠解決數(shù)百個(gè)退化問題。

Confluent公司實(shí)施了幾個(gè)反饋循環(huán)來跟蹤代理的表現(xiàn)，并在需要時(shí)采取一些行動(dòng)。當(dāng)檢測(cè)到問題時(shí)，將用不同的代理運(yùn)行狀況狀態(tài)對(duì)其進(jìn)行標(biāo)記，并使用各自的緩解策略對(duì)每種狀態(tài)進(jìn)行處理。其中三個(gè)反饋循環(huán)解決本地磁盤問題、外部連接問題和代理降級(jí)問題：

（1）監(jiān)控：一種從外部角度跟蹤每個(gè)代理表現(xiàn)的方法。Confluent公司經(jīng)常探測(cè)以進(jìn)行跟蹤。

（2）聚合：在某些情況下會(huì)聚合指標(biāo)，以確保相對(duì)于其他代理的降級(jí)是顯而易見的。

（3）React：特定于 Kafka 的機(jī)制，用于將代理排除在復(fù)制協(xié)議之外，或?qū)㈩I(lǐng)導(dǎo)權(quán)從復(fù)制協(xié)議中移走。

事實(shí)上，Confluent公司的自動(dòng)緩解措施每個(gè)月都會(huì)檢測(cè)并自動(dòng)緩解全球三個(gè)主要云計(jì)算提供商的數(shù)千次部分降級(jí)。既可以節(jié)省寶貴的操作時(shí)間，同時(shí)確保對(duì)客戶的影響最小。

5.平衡有狀態(tài)服務(wù)的性能和效率

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

例如，Kafka運(yùn)行有狀態(tài)的代理，并平衡分區(qū)及其副本分配給各種代理。這些分區(qū)上的負(fù)載可能以難以預(yù)測(cè)的方式上下波動(dòng)，具體取決于客戶活動(dòng)。這需要一組指標(biāo)和啟發(fā)式方法來確定如何在代理上放置分區(qū)，以最大限度地提高效率和利用率。Confluent公司通過一個(gè)平衡服務(wù)來實(shí)現(xiàn)這一點(diǎn)，該服務(wù)跟蹤來自多個(gè)代理的一組指標(biāo)，并在后臺(tái)持續(xù)工作以重新分配分區(qū)。

需要明智地重新平衡任務(wù)。過于激進(jìn)的再平衡可能會(huì)破壞性能并增加成本，因?yàn)檫@些重新分配會(huì)產(chǎn)生額外的工作。過于緩慢的再平衡會(huì)讓系統(tǒng)在修復(fù)失衡之前顯著退化。Confluent公司不得不嘗試大量的啟發(fā)式方法，以收斂到適用于各種工作負(fù)載的適當(dāng)反應(yīng)級(jí)別。

有效平衡的影響可能是巨大的。Confluent公司的一位客戶發(fā)現(xiàn)，在為他們啟用重新平衡后，他們的負(fù)載減少了大約 25%。同樣，另一個(gè)客戶發(fā)現(xiàn)，由于重新平衡，延遲大幅減少。

精心設(shè)計(jì)的云原生服務(wù)的好處

如果企業(yè)正在使用新代碼或使用現(xiàn)有的開源軟件(如Kafka)構(gòu)建云原生基礎(chǔ)設(shè)施，希望本文介紹的技術(shù)將幫助他們實(shí)現(xiàn)性能、可用性和成本效益方面的預(yù)期結(jié)果。

為了測(cè)試Kora的性能，Confluent公司在相同的硬件上進(jìn)行了一個(gè)小規(guī)模的實(shí)驗(yàn)，將Kora和完整云平臺(tái)與開源Kafka進(jìn)行比較。發(fā)現(xiàn)Kora提供了更大的彈性，擴(kuò)展速度快了30倍；與Confluent公司管理的客戶或其他云計(jì)算服務(wù)的故障率相比，可用性提高10倍以上，并且比自我管理Kafka的延遲要低得多。雖然Kafka仍然是運(yùn)行開源數(shù)據(jù)流系統(tǒng)的最佳選擇，但對(duì)于那些尋求云原生體驗(yàn)的人來說，Kora是一個(gè)很好的選擇。

云原生系統(tǒng)的構(gòu)建和管理可能非常復(fù)雜，但它們已經(jīng)支持大量的現(xiàn)代SaaS應(yīng)用程序，這些應(yīng)用程序?yàn)楫?dāng)今的大部分業(yè)務(wù)提供動(dòng)力。希望企業(yè)的云計(jì)算基礎(chǔ)設(shè)施項(xiàng)目能夠繼續(xù)保持這一成功軌跡。

原文標(biāo)題：5 tips for building highly scalable cloud-native apps，作者：Prince Mahajan