譯者 | 李睿

審校 | 重樓

當開發人員著手重建托管Apache Kafka服務的核心引擎時，需要滿足一些獨特的需求，這些需求是成功的云原生平臺的特征。這些系統必須是多租戶的，易于擴展以服務數千個客戶，并且主要由數據驅動的軟件而不是運行人員進行管理。它們還應在工程師可以繼續快速創新的環境中，為工作負載不可預測的客戶提供強大的隔離和安全性。

軟件服務提供商Confluent公司在去年展示了Kafka引擎的重新設計。其設計和實現的大部分內容適用于其他構建大規模分布式云計算系統的團隊，例如數據庫或存儲系統。Confluent公司首席工程師Prince Mahajan表示，希望與更廣泛的社區分享所學到的知識，可以使那些從事其他項目的人受益。

Kafka引擎重新設計的關鍵考慮因素

Confluent公司的目標很可能與一些企業基于云計算的系統目標相似：提高性能和彈性，為自己和客戶提高成本效益，并在多個公共云平臺之間提供一致的體驗。此外，還增加了與當前版本的Kafka協議保持100%兼容的要求。

該公司重新設計的 Kafka 引擎（稱為 Kora）是一個事件流平臺，在AWS、Google Cloud和Azure的70多個可用性區域運行數萬個集群。雖然企業可能不會立即以這種規模進行操作，但許多技術仍然適用。

以下是Confluent公司在新的Kora設計中實現的五個關鍵創新：

1.使用邏輯“單元”實現可擴展性和隔離

要構建高可用性和水平可擴展的系統，需要使用可擴展和可組合的構建塊構建的架構。具體地說，可擴展系統所做的工作應該隨著系統規模的增加而線性增長。最初的Kafka架構并不符合這個標準，因為負載的許多方面隨著系統規模呈非線性增長。

例如，隨著集群大小的增加，連接數量將呈二次方增長，因為所有客戶端通常都需要與所有代理進行通信。同樣，復制開銷也呈二次方增長，因為每個代理通常在所有其他代理上都有追隨者。最終的結果是，相對于帶來的額外計算/存儲容量，添加代理會導致開銷不成比例地增加。

第二個挑戰是確保租戶之間的隔離。特別是，行為不端的租戶可能會對集群中其他租戶的性能和可用性產生負面影響。即使進行有效的限制和節流，也可能總是存在一些有問題的負載模式。而且，即使客戶端運行良好，節點的存儲空間也可能會減少。如果在集群中隨機分布，這將影響所有租戶，甚至可能影響所有應用程序。

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

為了評估這個解決方案的有效性，Confluent公司設置了一個具有 6 個代理單元的實驗性 24 個代理集群。當運行基準測試時，集群負載(為測量Kafka集群上的負載而設計的自定義指標)在有單元時為53%，而在沒有單元時為73%。

2.平衡存儲類型以優化熱數據和冷數據

云計算的一個關鍵優點是，它提供了具有不同成本和性能特征的各種存儲類型。我們可以利用這些不同的存儲類型在架構中提供最佳的性價比權衡。

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

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

這種分層架構允許提高彈性——當只需要重新分配熱數據時，重新分配分區變得容易得多。使用EBS卷代替實例存儲還可以提高持久性，因為存儲卷的生命周期與關聯虛擬機的生命周期是分離的。

最重要的是，分層能夠顯著降低成本和提高性能。降低成本是因為對象存儲是存儲冷數據的更實惠和可靠的選擇。而且性能也得到了提高，因為一旦數據分層，就可以將熱數據放在高性能的存儲卷中，如果沒有分層，其成本將會非常昂貴。

3.使用抽象來統一多云體驗

對于任何計劃在多個云平臺上運行的服務，跨云提供統一的、一致的客戶體驗至關重要。由于多種原因，這很難實現。云計算服務是復雜的，即使它們符合標準，云服務和實例之間仍然存在差異。類似云服務的實例類型、實例可用性甚至計費模型都可能以細微但有影響的方式發生變化。例如，Azure塊存儲不允許獨立配置磁盤吞吐量/IOPS，因此需要配置更大的磁盤來擴展IOPS。相比之下，AWS和谷歌云允許用戶獨立地調整這些變量。

許多 SaaS 提供商都對這種復雜性不屑一顧，讓客戶擔心實現一致性能所需的配置細節。這顯然并不理想，所以對于Kora，Confluent公司開發了抽象差異的方法。

Confluent公司引入了三個抽象，使客戶能夠遠離實現細節，并專注于更高級別的應用程序屬性。這些抽象可以幫助顯著地簡化服務，并限制客戶需要自己回答的問題。

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

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

（3）最后，將集群上的負載抽象為一個稱為集群負載的統一指標。這可以幫助客戶決定是擴大還是縮小其集群。

有了這些抽象，客戶就不需要擔心底層的實現細節，服務提供商可以在新的硬件和軟件選項可用時不斷優化性能和成本。

4.自動化緩解循環以應對退化

故障處理對可靠性至關重要。即使在云中，故障也是不可避免的，無論是由于云服務中斷、軟件錯誤、磁盤損壞、錯誤配置還是其他原因。這些可能是完全故障，也可能是部分故障，但無論哪種情況，都必須迅速解決，以避免影響性能或對系統的訪問。

遺憾的是，如果企業正在大規模運行云平臺，則無法人工檢測和解決這些故障。這將占用運營人員太多的時間，并且可能意味著故障的解決速度不夠快，無法維持服務級別協議。

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

Confluent公司實施了幾個反饋循環來跟蹤代理的表現，并在需要時采取一些行動。當檢測到問題時，將用不同的代理運行狀況狀態對其進行標記，并使用各自的緩解策略對每種狀態進行處理。其中三個反饋循環解決本地磁盤問題、外部連接問題和代理降級問題：

（1）監控：一種從外部角度跟蹤每個代理表現的方法。Confluent公司經常探測以進行跟蹤。

（2）聚合：在某些情況下會聚合指標，以確保相對于其他代理的降級是顯而易見的。

（3）React：特定于 Kafka 的機制，用于將代理排除在復制協議之外，或將領導權從復制協議中移走。

事實上，Confluent公司的自動緩解措施每個月都會檢測并自動緩解全球三個主要云計算提供商的數千次部分降級。既可以節省寶貴的操作時間，同時確保對客戶的影響最小。

5.平衡有狀態服務的性能和效率

在任何有狀態服務中，平衡服務器之間的負載都是一個難題，并且直接影響客戶體驗的服務質量。負載分布不均勻會導致客戶受到負載最多的服務器提供的延遲和吞吐量的限制。有狀態服務通常有一組密鑰，需要平衡這些密鑰的分布，使總體負載均勻地分布在各個服務器上，以便客戶機以最低的成本從系統獲得最大的性能。

例如，Kafka運行有狀態的代理，并平衡分區及其副本分配給各種代理。這些分區上的負載可能以難以預測的方式上下波動，具體取決于客戶活動。這需要一組指標和啟發式方法來確定如何在代理上放置分區，以最大限度地提高效率和利用率。Confluent公司通過一個平衡服務來實現這一點，該服務跟蹤來自多個代理的一組指標，并在后臺持續工作以重新分配分區。

需要明智地重新平衡任務。過于激進的再平衡可能會破壞性能并增加成本，因為這些重新分配會產生額外的工作。過于緩慢的再平衡會讓系統在修復失衡之前顯著退化。Confluent公司不得不嘗試大量的啟發式方法，以收斂到適用于各種工作負載的適當反應級別。

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

精心設計的云原生服務的好處

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

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

云原生系統的構建和管理可能非常復雜，但它們已經支持大量的現代SaaS應用程序，這些應用程序為當今的大部分業務提供動力。希望企業的云計算基礎設施項目能夠繼續保持這一成功軌跡。

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