近日，AutoMQ 團隊發布了基于云的開源云原生 Kafka——AutoMQ for Kafka，所有的代碼采用 Apache 2.0 開源許可。AutoMQ 充分挖掘了云原生的技術紅利和成本優勢，再結合 Serverless 彈性技術，實現了 Apache Kafka 十倍的降本增效。本文從技術架構的角度，來揭秘 AutoMQ 為 Kafka 量身打造的云原生十倍降本方案。

今天，我們看到云計算帶來了兩個趨勢，一個是“上云的趨勢”，另一個是“下云的趨勢”，相信大家都關注到了最近 X（原 Twitter） 全力“下云”，成本降低了 60%。“上云”亦或是“下云”，到底誰在節約成本，誰在增加成本，這其中的差異可能三言兩語很難講清楚，但就 AutoMQ 核心團隊在阿里云多年的工作經歷來看，頭部云廠商一直是以“讓算力普惠、釋放技術紅利”為使命的，那到底為什么“上云”會給企業一種更貴的感受呢？

AutoMQ 團隊認為這其中最主要的差異在于云原生（Cloud Native）和云托管（Cloud Hosted）的差異。以云托管的姿勢上云，最終會發現云上成本比自建機房還高，將傳統的軟件架構 Rehost 到云上，其本質是將 IDC 架構平移上云，是無法發揮出云基礎設施的規模化優勢，也享受不到成本紅利。只有以云原生的姿勢上云，充分利用云的彈性能力，服務化的產品和自動化的 API，才能做出云上最優的成本解決方案。

云原生的能力

在引出 AutoMQ 為 Kafka 打造的云原生架構之前，我們先來看一下云的基礎設施已經進化到什么程度了，有哪些能力和優勢是跟成本息息相關的，而且是傳統的 IDC 架構無法充分利用起來的。

服務化的產品

云計算技術迭代的路線可以總結為：云先用軟件定義硬件，再把軟件變成了服務。所以，我們今天看到網絡環境變成了 VPC，存儲介質變成了云盤，物理主機變成了虛擬的云主機 ECS。

這些云提供的基礎產品在今天已經蛻變成了服務，服務一定是具備生產可用的 SLA，比如阿里云單個 ECS 實例的可用性達 99.975%，這意味著一個單節點的微服務也可以是生產可用的，這在 IDC 環境是無法想象的事情。再例如云盤 EBS，相對于物理存儲介質，EBS 天然具備 3 副本，提供 5 個 9 ～ 9 個 9 的數據可靠性，同時具備可用區內和區域內的容災能力。

所以，我們今天做云原生架構，第一個共識就是需要意識到，基于云的架構設計已經從依賴軟硬件，變為依賴云服務了，真正的云原生架構一定要充分發揮出云產品的服務化能力。

彈性

彈性可以說是云最大的優勢，云積累了大規模的算力，給了單個租戶無限計算資源的視圖，云原生的架構完全可以假設，在云上一切資源都是無限的，都是唾手可得的。

對于 IDC 環境，因為機器資源至少月級的交付時間，傳統的軟件架構并不會面向彈性能力進行設計，一般都會假設保有一定的機器資源來提供軟件服務。這也意味著，當傳統的軟件 Rehost 到云上后，也是以預留資源的形式使用云資源，一方面存在資源的極大浪費，另一方面也無法享受到云的彈性能力。

不難發現，彈性能力的來源并不是資源交付時間變快了，完全是因為云廠商通過預留大量資源實現了租戶級無限的彈性的能力，所以說“世上本沒有真正的彈性，都是云廠商在負重前行”。正因為這樣，云廠商各個地域都有大量的閑置資源，云廠商為了盡可能將閑置的資源轉換為營收，推出了 Spot 計算實例，Spot 類型的實例相較于正價的 ECS 實例，至多有 90% 的成本節約。如何充分發揮出 Spot 實例的成本優勢，也是云原生架構需要重點考慮的地方。

API 定義一切

云計算所有的能力都是通過 API 來進行描述的，比如用 API 創建一臺 ECS，用 API 重新掛載一塊云盤，用 API 去調整云服務的 Quota 和 Limitation。

正因為此，云原生的軟件有機會利用 API 去編排資源，去實現 Auto Scaling，實現容災的切換。通過利用云的 API 完成軟件核心的能力建設，甚至容災能力的建設，這也是傳統的軟件架構無法辦到的事情。

云服務依賴選型

云廠商提供了數百種的全托管云服務，但這些云服務成熟度完全不一樣，不少小的云服務研發團隊僅僅有個位數的人力投入。所以，我們在進行云原生架構設計時，需要謹慎進行云服務依賴選型，我們總結了兩個原則：

選擇云廠商投入最大、規模最大的云服務，這類服務成熟度往往是最高的，不能單純看云廠商承諾的 SLA。

選擇標準化的云服務以避免廠商鎖定，我們設計的云原生架構必須是所有云的原生架構，而不能單純是某朵云的原生架構。

在這兩個原則的約束下的云服務，也是云廠商真正釋放云原生能力的出口，它們往往有以下幾個特征：

真正的按量計費，以最小的資源粒度按使用量進行計費，比如 Lambda 按調用次數計費，沒有任何保有成本。將實例規格包裝成按時間進行計費不是真正的按量計費。

無限的容量，給單個租戶的視圖一定是無限的容量，無限的存儲和計算資源，業務再也不需要進行容量評估了。

低成本，真正地通過技術而不是通過虧損，通過規模去優化成本，比如對象存儲 S3 是業界最便宜的存儲產品之一。

選擇性地依賴云服務，可以讓我們的云原生架構更加靈活，充分享受到云的紅利，多云原生的靈活度，更高的穩定性保障。

AutoMQ 云原生架構

AutoMQ 將消息和流存儲最流行的兩款開源軟件 Kafka 和 RocketMQ 基于云重新設計，將這兩款面向 IDC 進行架構的軟件帶向云原生領域。Kafka 和 RocketMQ 的核心分別是流存儲和消息存儲，對于存儲類型的軟件，要完全把云的能力用起來并不是一件容易的事情。

AutoMQ 在進行 Kafka 和 RocketMQ 重新設計之初，就定義了幾個設計目標：

盡可能發揮出云的彈性能力，將彈性作為核心能力去設計，根據負載變化系統能進行彈性伸縮。

盡可能使用 Spot 實例，Spot 實例有隨時被中斷的風險，能否實現存儲軟件的“無狀態”是能否利用 Spot 實例的關鍵。

盡可能將數據全放在對象存儲上，S3 極具成本優勢，存儲系統降本的關鍵一定在于能否將 S3 的能力發揮到極致。

盡可能利用 EBS 的低延時和高性價比，解決業務對數據寫入的低延時需求，通過 EBS 和 S3 組合出高可用能力即可提供低成本、高可用和高可靠的存儲服務。

結合云已經有的能力，以及我們對流存儲和消息存儲軟件的理解，我們設計了一套真正的云原生架構，同時滿足了以上幾個設計目標。

該架構主要包含三個核心設計思想。

一、存算分離至服務

存算分離擁有狀態卸載、彈性等好處，這已經是行業共識，但如何實現存算分離沒有統一的方案，我們今天認為存算分離的核心是將存儲分離至服務而不是軟件。如果，我們為了存算分離將存算一體架構的存儲部分，分離出一套分布式存儲軟件，這會帶來額外的部署、運維以及治理的復雜度。

RocketMQ 早期的架構是完全零依賴，正因為架構極簡，讓它在生產系統的實際可用性非常高，今天存算分離的優勢已經被眾多開發者所喜愛，但是任何一個軟件的可用性是由軟件本身和后臺運維的工程師組成，如果這個軟件還依賴其他軟件，那么它就類似一個串聯電路，任何一個環節出問題，就會影響最終用戶，尤其是依賴一個無人運維的存儲系統，更是會讓整個系統的復雜度和可用性失控。而云廠商的對象存儲、塊存儲等大規模使用的系統背后有全世界最優秀的工程師在運維，理論上這樣的系統一定是可用性最高的。

另外一點就是存儲能否做到完全卸載，有些觀點認為多級存儲也是存算分離，實際上業界大部分多級存儲方案都有很重的一級存儲，一級存儲包含了大量的存儲狀態。如果無法做到存儲的完全分離，也就無法將存算分離的彈性優勢發揮到極致。

我們對存算分離理念的實踐都體現在 S3 Stream 這一基于 S3 的流存儲庫之上，S3 Stream 組合 EBS 和 S3 的能力，實現了低成本、高可用、高可靠以及無限容量的流存儲能力，更多的技術細節詳見我們的文檔（https://docs.automq.com/）。

二、共享存儲優于 Shared Nothing 架構

Shared Storage 和 Shared Nothing 架構各有優劣，但今天在云上，存儲已經變得彈性，容量近乎于“無限”，我們認為共享存儲是一個更優的架構。

通過將存儲單元進行共享，狀態可以快速轉移，分區遷移、節點擴縮容將變得非常簡單。共享存儲也是云原生架構能否充分利用 Spot 實例的關鍵。

三、可靠性與可用性實現

回到 Kafka 和 RocketMQ 的核心能力上，這兩款軟件都自帶多副本機制，目前分布式架構不管是 Raft 共識算法還是其他變種的副本機制，都是通過副本的冗余，一方面實現數據的高可靠，另一方面多余的副本可以快速提供故障轉移的能力，從而實現高可用。

但在云上，云存儲 EBS 已經自帶 3 副本了，如果上層應用繼續采用復制的方案，將帶來 9 副本的數據冗余，以及多倍的存儲和網絡成本。所以，在 Kafka 和 RocketMQ 層面沒有必要自己實現 3 副本。另外，EBS 是第二大存儲系統，僅次于第一大存儲系統 S3，云廠商對 EBS 進行深入的軟硬一體優化，把 EBS 客戶端卸載到神龍 CIPU（智能網卡）通過硬件來做，EBS 客戶端跟 EBS 服務器的通訊針對數據中心內低延時低丟包率的特點實現自定義的傳輸協議而不是用 TCP，這些軟硬一體優化帶來的效果遠遠好于自己搭建的 3 副本高可靠系統。還有，在云上使用 EBS 來存儲不消耗網絡帶寬，自建的 3 副本復制會大量消耗網絡帶寬。

鑒于此，AutoMQ 提出了服務的可靠性與可用性實現方案，依賴 EBS 的可靠性，可以采用單個寫入計算節點，把數據先寫入到存儲在 EBS 裸設備的 WAL 中，若當前寫入計算節點故障了，其他計算節點接管這個 EBS，從 WAL 中恢復數據。通過基于 EBS 的 Detach/Attach API 以及 NVMe 相關的 API 實現一次只有一個計算節點可以寫入 EBS，確保 EBS 數據寫入的一致性。

架構優勢

AutoMQ 云原生架構為 Apache Kafka 帶來了單副本高可用，秒級分區遷移，持續數據重平衡，分鐘級平滑擴縮容等技術架構優勢（更多細節參看官方文檔）。

十倍降本增效解讀

AutoMQ 團隊將云原生架構的技術優勢，兌現為成本優勢和運維效率，為 Apache Kafka 帶來的十倍的降本增效。

運維效率提升

Kafka 運維有兩個痛點，給運維人員帶來了極大的運維成本：

分區遷移，Kafka 遷移分區需要進行數據復制，一方面額外的復制流量對生產環境會產生穩定性影響，另一方面復制耗時一般比較長，導致遷移分區的操作需要長時間進行觀察，以確保系統達到終態。

擴容，當 Kafka 集群流量不足時，運維人員需要對集群進行擴容，但擴容后的節點無法承擔任何流量，需要從其他節點移動分區過來，也就是說擴容需要移動大量的分區，才能達到流量的重平衡。擴容操作需要提前擴容，如果在業務高峰時進行擴容是無法緩解生產壓力，反而會進一步將生產集群推向高風險狀態。

AutoMQ 的云原生架構得益于將存儲狀態卸載到共享存儲上，移動一個 TB 級的分區能將時間從 3 小時縮減為 1.5 秒，擴容后流量重平衡時間從 43 小時縮減為 1 分鐘，成功地將 Kafka 高風險的常規運維動作，變成了可自動化，基本無感的低風險運維操作，大幅度降低了運維人員的工作負擔。

計算和存儲降本

成本方面，我們提供了一個 80 MB/s ～ 1 GB/s 的彈性工作負載用于壓測真實的云賬單，在該負載下，AutoMQ 提供的云原生 Kafka 版本每月僅需 5632 元，相比于自建 Apache Kafka 承擔該負載需要 62,431 元，AutoMQ 的云原生架構成功降本 11.09 倍。AutoMQ 獲取成本優勢的核心主要有幾點：

充分利用對象存儲和 EBS 的低成本特性，將存儲成本降低了 90%。

通過無狀態的架構設計，內置 Auto Balancing 組件，實現自動擴縮容能力，再充分利用 Spot 實例，能做到計算成本降低 11.09 倍。

近期，我們發布了完整的成本分析報告，詳情見 AutoMQ 的官方文檔。

總結

AutoMQ 團隊通過對 Apache Kafka 進行全新的云原生架構設計，成功做到了 10 倍的降本增效，充分驗證了真正的云原生架構是能充分發揮云的規模化優勢的，能做到超出預期的、十倍的降本效果，能大幅度降低運維復雜度，真正做到共享云的一切優勢。

云計算，開辟了一個新的時代，以云原生的姿勢上云，是不會有下云的憂慮，我們堅信，所有的基礎軟件，都值得基于云重新設計，以發揮出云全部的優勢。