上云還是下云：章文嵩博士解讀真正的云原生Kafka十倍降本方案！

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

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

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

云原生的能力

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

服務化的產(chǎn)品

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

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

所以，我們今天做云原生架構(gòu)，第一個共識就是需要意識到，基于云的架構(gòu)設計已經(jīng)從依賴軟硬件，變?yōu)橐蕾囋品樟?，真正的云原生架?gòu)一定要充分發(fā)揮出云產(chǎn)品的服務化能力。

彈性

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

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

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

API 定義一切

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

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

云服務依賴選型

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

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

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

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

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

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

低成本，真正地通過技術(shù)而不是通過虧損，通過規(guī)模去優(yōu)化成本，比如對象存儲 S3 是業(yè)界最便宜的存儲產(chǎn)品之一。

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

AutoMQ 云原生架構(gòu)

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

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

盡可能發(fā)揮出云的彈性能力，將彈性作為核心能力去設計，根據(jù)負載變化系統(tǒng)能進行彈性伸縮。

盡可能使用 Spot 實例，Spot 實例有隨時被中斷的風險，能否實現(xiàn)存儲軟件的“無狀態(tài)”是能否利用 Spot 實例的關(guān)鍵。

盡可能將數(shù)據(jù)全放在對象存儲上，S3 極具成本優(yōu)勢，存儲系統(tǒng)降本的關(guān)鍵一定在于能否將 S3 的能力發(fā)揮到極致。

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

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

該架構(gòu)主要包含三個核心設計思想。

一、存算分離至服務

存算分離擁有狀態(tài)卸載、彈性等好處，這已經(jīng)是行業(yè)共識，但如何實現(xiàn)存算分離沒有統(tǒng)一的方案，我們今天認為存算分離的核心是將存儲分離至服務而不是軟件。如果，我們?yōu)榱舜嫠惴蛛x將存算一體架構(gòu)的存儲部分，分離出一套分布式存儲軟件，這會帶來額外的部署、運維以及治理的復雜度。

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

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

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

二、共享存儲優(yōu)于 Shared Nothing 架構(gòu)

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

通過將存儲單元進行共享，狀態(tài)可以快速轉(zhuǎn)移，分區(qū)遷移、節(jié)點擴縮容將變得非常簡單。共享存儲也是云原生架構(gòu)能否充分利用 Spot 實例的關(guān)鍵。

三、可靠性與可用性實現(xiàn)

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

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

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

架構(gòu)優(yōu)勢

AutoMQ 云原生架構(gòu)為 Apache Kafka 帶來了單副本高可用，秒級分區(qū)遷移，持續(xù)數(shù)據(jù)重平衡，分鐘級平滑擴縮容等技術(shù)架構(gòu)優(yōu)勢（更多細節(jié)參看官方文檔）。

十倍降本增效解讀

AutoMQ 團隊將云原生架構(gòu)的技術(shù)優(yōu)勢，兌現(xiàn)為成本優(yōu)勢和運維效率，為 Apache Kafka 帶來的十倍的降本增效。

運維效率提升

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

分區(qū)遷移，Kafka 遷移分區(qū)需要進行數(shù)據(jù)復制，一方面額外的復制流量對生產(chǎn)環(huán)境會產(chǎn)生穩(wěn)定性影響，另一方面復制耗時一般比較長，導致遷移分區(qū)的操作需要長時間進行觀察，以確保系統(tǒng)達到終態(tài)。

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

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

計算和存儲降本

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

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

通過無狀態(tài)的架構(gòu)設計，內(nèi)置 Auto Balancing 組件，實現(xiàn)自動擴縮容能力，再充分利用 Spot 實例，能做到計算成本降低 11.09 倍。

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

總結(jié)

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

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