作者：娜米
本文整理於 2024 年雲棲大會阿里雲智慧集團產品專家張鳳婷帶來的主題演講《雲訊息佇列 Kafka 版全面升級：經濟、彈性、穩定》
雲原生訊息產品十年磨一劍
訊息產品的演進可以大致分為三個主要階段：
- 起步階段： 初期，市場上缺乏能夠支撐大規模業務場景的優秀訊息產品，無論是商業化還是開源產品。阿里巴巴的訊息產品誕生於淘寶核心交易鏈路，服務於當時世界上最大的交易系統之一，在場景適應性、效能、擴充套件性等方面都經受了嚴苛的考驗。因此，訊息佇列團隊推出了 RocketMQ 的開源和商業化產品，並迅速在技術領域佔據領先地位。
- 大資料階段： 隨著 MapReduce、Hadoop、Spark、Hbase 等開源大資料工具的釋出，大資料計算變得更容易和低成本。隨之，企業業務架構向資料驅動架構轉型。為了適應這一趨勢，訊息佇列團隊陸續釋出了 Kafka、RabbitMQ、MQTT 等多款產品，基於豐富的開源訊息生態，構建了一個完整的商業化訊息產品矩陣，以滿足多樣化的業務場景。
- 雲端計算階段： 雲端計算成為行業共識，雲基礎設施日益成熟。雲服務的核心價值在於成本效益，因此，訊息佇列團隊致力於讓客戶以更低的成本使用雲上的訊息產品。透過充分利用雲服務，如容器服務、飛天盤古等的產品能力，雲訊息佇列 ApsaraMQ （阿里雲訊息佇列產品品牌）全系列產品均實現了 Serverless 架構，以達到成本極致最佳化。
降本是持續的技術方向
為了持續最佳化成本，雲訊息佇列 Kafka 版（阿里雲訊息佇列的 Kafka 商業化產品）不僅是簡單地給予讓利，而是透過架構層面的深度最佳化，實現客戶使用成本的降低。
與 Apache Kafka 相比，雲訊息佇列 Kafka 版透過節省 66% 的資源，實現客戶使用成本比自建最多降低 82%， 這是如何實現的呢？
我們來看 Apache Kafka 的資料流，在傳統的三備份複製模式下，無論計算還是儲存，都需要三份複製來確保系統的高可用。然而，這種設計最初是為了在 IDC 環境中實現高可靠性和可用性的，在高 SLA 的雲環境中，就會導致資源冗餘。因此，雲訊息佇列 Kafka 版透過架構升級，實現了計算與儲存的完全分離，而不是簡單的二級儲存。
在計算層面，雲訊息佇列 Kafka 版透過存算分離，將計算與儲存剝離，實現了計算節點的無狀態和互為主備。在儲存層面，與 Apache Kafka 不同的是，雲訊息佇列 Kafka 版的儲存層採用了成熟產品化的飛天盤古儲存產品，支援百萬級客戶，並且充分利用了雲盤的三份複製功能。
因此，雲訊息佇列 Kafka 版在計算層面只需要使用三分之一的機器資源，在儲存層面也只需要三分之一的儲存空間，就能實現與 Apache Kafka 相似的功能。
訊息佇列架構演進
在雲訊息佇列 Kafka 版的產品演進過程中，我們不僅注重成本最佳化，而是致力於實現經濟性、穩定性和彈性的三大核心目標。
- 經濟性： 我們持續改進定價策略以適應市場趨勢。起初，市場上缺乏優秀的訊息產品，為了更好地提供高階功能，我們的定價策略需要覆蓋研發成本。隨著開源訊息生態的發展，我們調整定價模型，以降低使用成本，與自建運維成本相持平。目前，我們透過最佳化成本結構，將使用成本降至與自建機器成本相當的水平，無需額外的人力投入。透過減少預留資源和增加資源彈性，雲訊息佇列 Kafka 版實現了 Serverless 架構，客戶使用成本比自建平均降低 30%，為客戶提供了更具成本效益的訊息產品。
- 穩定性： 我們致力於增強系統的穩定性。服務水平協議（SLA）通常確保產品在正常執行時的穩定性。然而，對於雲訊息佇列 Kafka 版，我們的 SLA 不僅確保系統穩定執行，還特別關注在運維、擴縮容和彈性等操作中的穩定性。專業版支援多可用區故障無損切換；同時 Serverless 系列支援在兩倍彈性範圍內進行無感擴充套件，目前也支援定時彈性無限（最大到 50GB/s 的規格）彈性，解決秒殺場景的冷啟動彈性問題。後面規劃可以做到自適應彈性，跟隨流量增長，動態擴容，支援數倍的彈性。確保使用者體驗的流暢性和服務的可靠性。
- 彈性： 我們注重提升效率。Apache Kafka 作為一個有狀態的產品，在擴容和縮容過程中可能會耗費較長時間。尤其面對大規模業務，Apache Kafka Broker 有狀態的特點導致了擴容緩慢、縮容困難的問題。雲訊息佇列 Kafka 版從設計之初就追求在有狀態背景下，實現快速、順暢地擴容和縮容。目前，則更進一步追求，在保持系統穩定性的同時，實現更快速的彈性。透過存算分離、狀態下推、並行升級、預留資源池等技術，雲訊息佇列 Kafka 版實現了秒級彈性，而開源自建擴容要小時甚至天的時間。
綜上所述，雲訊息佇列 Kafka 版架構演進的核心目標，是平衡成本與效能，並確保彈性和可靠性。同樣，這也是整個訊息生態系統架構發展的趨勢。
隨著單機架構的淘汰，目前市場上主要採用以下三種架構：
- 本地儲存架構： 這是 Apache Kafka 的開源架構。
- 多級儲存架構： 儘管 Apache Kafka 也提出了該架構，但目前還不夠成熟。許多雲廠商也採用這種架構，因為它易於部署，投入較少的資源就能夠適配不同雲廠商的環境，但並沒有專為某個雲廠商進行深度最佳化。而且，這種架構還存在存算分離不徹底、熱盤爆盤、資料丟失以及 HA 瓶頸等問題。
- 存算分離架構： 這是目前的最優選擇，真正實現了計算層的完全無狀態，有助於提高彈性過程中的穩定性、效率和資料可靠性。
存算分離架構是 Serverless 架構的最優選擇
在雲訊息佇列 Kafka 版的架構演進的過程中，重點在於重新設計儲存層。我們的目標是確保計算層和儲存層的狀態剝離得足夠徹底，並在此基礎上解決成本、效能、穩定性和彈性效率之間的矛盾。
為什麼說存算分離架構是目前的最優選擇？以下是幾個關鍵考量點：
- 冷熱資料的運維問題： 在多級儲存系統中，冷熱資料管理至關重要。資源預留不足可能導致爆盤，影響寫入操作，但資源預留實際是與 Serverless 架構理念相悖的。同時，由於多級儲存涉及多種產品，增加了運維複雜性，因此，冷熱資料運維通常應由成熟產品而非個人負責。
- 熱資料災備切換問題： 在多級儲存系統中，需要考慮計算和熱盤繫結的問題。熱盤是架構中有狀態的部分，Broker 並不是獨立存在的，因此在進行 HA 切換時，如何保證不丟資料，保證 HA 的效率是一個關鍵問題。
- 熱盤機型切換問題： 儘管存在熱盤掛載的技術，但其尚未被大規模應用，成熟度還沒有得到保證。同時，支援該技術的機型數量很有限，相關成本也是一個考慮因素。
因此，簡單的多級儲存可能會掩蓋很多潛在問題，在實際落地中隱藏了巨大的風險。所以，多級儲存的進一步演進，是真正實現存算分離架構，確保資料不丟失、服務持續可用、快速實現 HA，並透過大規模驗證。
從以上關鍵點來比較三種架構：
- 本地儲存架構： Apache Kafka 最被詬病的運維痛點，包括彈性時間長和資源冗餘導致成本高。採用本地儲存架構資料不共享，需要在計算層進行備份和複製，成本較高。由於資料並未剝離，擴容時需要資料遷移，導致擴容速度慢至小時甚至天級別，嚴重影響業務，有時還需要在資料丟失和穩定性之間進行取捨。
- 多級儲存架構： 多級儲存本身是個很棒的架構，在資料儲存上有廣泛的應用，但由訊息產品直接實現該架構非最佳實踐，可能會存在熱盤規劃、資料丟失、穩定性、服務持續性、運維投入、HA 速度等很多問題。非常考驗程式碼的細節以及極端且廣泛場景的驗證。
- 存算分離架構： 從目前雲產品和技術發展的程序看，存算分離架構是從根本上解決這些問題的最佳實踐。
上面是效果比較的示意圖，在穩定性、彈性、資源利用率方面，存算分離架構均表現最佳。因此，我們採取冷熱資料共享，透過存算分離架構進行雲訊息佇列 Kafka 版產品重構和演進。
Kafka 不僅僅是 Apache Kafka
接下來將透過一些實際例子，與大家分享存算分離架構帶來的優勢。
秒級彈性 & 擴容穩定性打磨
在擴容方面，Apache Kafka 需要進行資料的 shuffle。例如，假設有一個由 broker 1、2、3 組成的叢集，當我們再加入一個 broker 4 時，不論是 leader 資料還是 follower 資料，都需要進行 shuffle。
相比之下，雲訊息佇列 Kafka 版的擴容過程則更為簡便，只需要新增一個計算的 broker，並進行邏輯對映，就可以開始讀寫操作，無需進行資料遷移。這種模式將資料遷移所需的線性增長時間轉變為定量的擴容時間，從而減少了時間成本並提高了效率。
以下是一個示例，供參考。基於一個資料寫入速率 100MB/s 並儲存資料 30 天的工作負載進行測試，使用雲訊息佇列 Kafka 版，無論是橫向擴容還是增加分割槽，時間上都有了百倍到千倍的減少。 對於需要持續執行的業務場景來說，這是顯著的優勢。
故障切換，資料不丟
隨著規模的增長，單點故障的機率也隨之上升。因此，在 HA 場景下，必須考慮到資料快速切換且不丟失的問題，這是 Kafka HA 的關鍵點。
以 Apache Kafka 為例，當一個機房斷網或不可用時，由於分割槽及其副本可能位於同一個可用區，這就可能直接導致不可用，例如下圖的分割槽 3；如果設定高可用模式，Follower 資料可能尚未完成同步，導致部分分割槽資料丟失，例如下圖的分割槽 1、2；在叢集減少機器資源的情況下，選主後會儘快補齊 Follower，進一步加劇叢集流量負擔，甚至可能導致全叢集的穩定性問題，例如下圖的分割槽 1、2、3、4。因此，雖然理論上 Apache Kafka 可以跨越多個可用區部署，但在實際故障需要主備切換時，仍可能會出現部分分割槽完全不可用、當機時間不可控的情況，還有資料丟失和腦裂的風險。
雲訊息佇列 Kafka 版跨多個可用區部署計算和儲存資源，當一個可用區不可用，不會對其他可用區產生任何影響。由於計算層面無狀態且相互獨立，儲存層是多可用區容災的，因此多可用區能夠正常提供服務。同時，得益於阿里雲飛天盤古儲存系統的強大支援，經過大規模商業化驗證，提供了 12個9 的資料可靠性和 5個9 的可用性。並且，透過最佳化選主演算法，有效避免了 HA 場景中最令人擔心的腦裂風險。
RT 效能量級提升
我們都知道，絕大多數時候，最佳化架構是遠遠不夠的。實現落地的細節、各種場景的磨練以及商業化規模的打磨，都會影響整個產品的平穩與效能。
雲訊息佇列 Kafka 版不僅最佳化了架構，在許多細節上也做了提升。接下來將重點介紹儲存層的五個最佳化策略：
- 利用強大的雲服務： 採用了飛天盤古儲存系統，其效能非常高，能達到百微秒級平均延遲、毫秒級長尾延遲，同時提供了 12個9 的資料可靠性和 5個9 的可用性。
- 多組提交最佳化： 採取了多種記憶體聚批策略，包括時間、空間和頻率等，最佳化多組提交。
- 多級快取： 記憶體資料中採用了多級快取機制，實現資料就近加速和熱資料分離，避免快取汙染，從而提升整體效能。
- 冷讀最佳化： 冷讀是影響 Apache Kafka 穩定性的關鍵點，雲訊息佇列 Kafka 版幾年前就實現了冷熱執行緒（協程）分離，近期又增強了資料預載入、預讀和自適應調整 IO 大小等能力。
- 硬體最佳化： 雲訊息佇列 Kafka 版還進行了一些硬體最佳化協調，去提升效能。
雲訊息佇列 Kafka 版透過以上儲存策略最佳化，無論是在攢批傳送的端到端延遲、傳送延遲、碎片化傳送、冷讀或者堆積的測試上，效能都得到顯著提升。 下圖是我們的實驗資料和結果。
總的來說，雲訊息佇列 Kafka 版並不僅僅是 Apache Kafka 的全託管產品，我們在整體架構和細節上不斷打磨，在效能和穩定性方面持續深度最佳化，以滿足客戶對高效能、高穩定性的需求。
雲訊息佇列 Kafka 版：追求極致，接近極致
雲訊息佇列 Kafka 版不僅相容開源協議，保留了開源產品的核心功能，更致力於為客戶提供更加穩定可靠、高效靈活、成本效益更高的訊息佇列服務。
- 雲訊息佇列 Kafka 版依託於阿里雲成熟、強大的基礎設施，如容器服務、飛天盤古儲存系統、雲伺服器等經過大規模驗證的產品，為整體效能和穩定性提供了堅實的基礎。
- 核心層面，雲訊息佇列 Kafka 版進行了徹底的重構，包括快速啟動、資料自平衡和就近加速等，以確保系統的穩定性和資料傳輸的可靠性。
- 效能方面，雲訊息佇列 Kafka 專注於提升資料處理速度，使使用者能夠更迅速地傳輸和處理資料。
- 雲訊息佇列 Kafka 版在客戶體驗和功能視覺化方面也進行了深度最佳化。提供完善的視覺化大盤、實時監控和專家診斷等，使客戶能夠更直觀地掌握系統的執行狀況。
阿里雲是 Confluent 中國大陸地區唯一的合作商
雲訊息佇列 Kafka 版不僅提供開源 Apache Kafka 全託管的版本，還提供 Confluent 版。
Confluent 是 Kafka 商業化的領先企業，它提供了基於 Kafka 的訊息平臺 Confluent Platform，使得使用者可以更輕鬆地構建、管理和監控實時資料流。
Confluent 可以理解為是一個搭積木的產品，Apache Kafka 只是核心。它的核心產品特性包括 Kafka Connector、KSQL 和 Schema Registry 等。Kafka Connector 允許使用者輕鬆地整合 Confluent 平臺與各種資料儲存系統和應用程式，而 Kafka Cycle Management 則提供了一套工具和服務，讓使用者能夠更輕鬆地管理和操作 Kafka 叢集。此外，Schema Registry 允許使用者註冊和管理 Avro 模式，而 KSQL 則提供了一種 SQL 介面，使得使用者可以使用 SQL 語句對實時資料進行處理和分析。
總之，Confluent 的商業化版本為客戶提供了一站式的訊息平臺解決方案，幫助他們更輕鬆地構建和管理實時資料流。無論是連線、管理、資料格式還是資料分析，Confluent 都能滿足需求，是構建實時資料架構的理想選擇。
目前，阿里雲是中國大陸地區唯一的一個合作商，已經在中國大陸地區核心區域，中國香港、新加坡、馬來西亞等區域釋出了雲訊息佇列 Confluent 版，並提供新使用者首月 1 折試用的優惠活動，歡迎大家體驗。
雲訊息佇列 Confluent 版官網：https://www.aliyun.com/product/aliware/alikafka/confluent
點選此處，觀看本場直播回放。