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

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

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

云原生的能力

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

服務(wù)化的產(chǎn)品

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

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

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

彈性

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

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

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

API 定義一切

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

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

云服務(wù)依賴選型

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

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

選擇標(biāo)準(zhǔn)化的云服務(wù)以避免廠商鎖定，我們?cè)O(shè)計(jì)的云原生架構(gòu)必須是所有云的原生架構(gòu)，而不能單純是某朵云的原生架構(gòu)。

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

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

無限的容量，給單個(gè)租戶的視圖一定是無限的容量，無限的存儲(chǔ)和計(jì)算資源，業(yè)務(wù)再也不需要進(jìn)行容量評(píng)估了。

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

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

AutoMQ 云原生架構(gòu)

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

AutoMQ 在進(jìn)行 Kafka 和 RocketMQ 重新設(shè)計(jì)之初，就定義了幾個(gè)設(shè)計(jì)目標(biāo)：

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

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

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

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

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

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

一、存算分離至服務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

十倍降本增效解讀

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

運(yùn)維效率提升

Kafka 運(yùn)維有兩個(gè)痛點(diǎn)，給運(yùn)維人員帶來了極大的運(yùn)維成本：

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

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

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

計(jì)算和存儲(chǔ)降本

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

充分利用對(duì)象存儲(chǔ)和 EBS 的低成本特性，將存儲(chǔ)成本降低了 90%。

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

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

總結(jié)

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

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