2026 年 6 月，AutoMQ 開源倉庫突破 10K GitHub Star。寫下這句話的時候，我們很開心，也很感謝一路關注、試用、提 issue、給反饋的開發者和用戶。

基礎軟件的 Star 通常來得慢一些。開發者點下 Star 之前，往往已經讀過架構、跑過 demo、翻過 issue；企業團隊愿意把它放進 Kafka 選型，也會先評估兼容性、可靠性、遷移成本和長期運維。AutoMQ 的 10K Star 里，有這樣的耐心和真實反饋。根據 OSSInsight 的 GitHub 關注來源統計，約 74% 的關注來自海外；同時，AutoMQ 已經進入中國、東南亞、歐洲和美國企業的生產環境。這個結果讓我們很受鼓舞。

AutoMQ 開源時，我們想推動的是 Kafka 在云時代的存儲架構演進。Kafka 已經沉淀了成熟的協議、語義和生態，這些能力應該繼續保留；持久數據長期綁在 Broker 本地磁盤上，會把數據中心時代的彈性、成本和運維壓力帶到云上。AutoMQ 選擇 Diskless Kafka，把流數據存儲放到對象存儲和共享存儲之上，讓 Broker 成為無狀態計算節點，同時保留 Kafka 成熟的協議、語義和生態。AutoMQ 也是圍繞這條路線最早開源并持續投入生產實踐的 Diskless Kafka 項目之一。

從 10K Star 往回看，AutoMQ 的增長曲線背后有開發者的工程追問、社區里的架構討論、客戶生產環境里的驗證，也有一支中國開源基礎軟件團隊走向全球市場的過程。沿著這些經歷往下看，就能看到越來越多 Kafka 工程師和平臺團隊開始關注 Diskless Kafka 的原因。

01

Diskless Kafka 開拓者亮相

AutoMQ 第一次被大量海外開發者看見，是在 Hacker News。2024 年 4 月，AutoMQ 以Show HN: AutoMQ - A Cost-Effective Kafka Distro That Can Autoscale in Seconds發布，并一度登上 Hacker News 榜首。

這次討論讓我們第一次真切感受到，海外開發者對 Diskless Kafka 這個方向有很強的興趣。評論區集中在標準 Kafka 客戶端兼容、寫入確認、WAL 故障恢復、benchmark 數據等問題上。這些都是真實 Kafka 生產使用里繞不開的問題。那一次，HN 帶來了流量，也帶來了很具體的工程反饋。

HN 之后，AutoMQ 也持續把 Diskless Kafka 的工程實踐帶回 Apache Kafka 社區。我們希望分享過去幾年圍繞共享存儲、云原生彈性和 Kafka 兼容性形成的架構思考。

2025 年，AutoMQ 提出 KIP-1183: Unified Shared Storage。這個提案進入 Apache Kafka 社區后，很快形成了一輪關于共享存儲架構的討論，多位 Apache Kafka Committer / PMC 成員參與其中。討論聚焦在 shared-storage 是否應該進入 Kafka、Stream 抽象如何設計，以及它與 ISR 和本地存儲引擎如何長期共存。

這個 KIP 討論的是 Kafka 如何面向對象存儲、文件存儲、塊存儲等共享存儲服務，抽象出統一的共享存儲層。它延續了 AutoMQ 一直推動的方向，讓 Kafka 保留成熟的協議和生態，同時讓存儲層更好地利用云基礎設施已經提供的持久性、彈性容量和按需付費模型。

到 2025 年 Confluent Current London，這些線上討論變成了面對面的技術交流。Current 是 Kafka 生態里重要的行業會議之一，現場聚集了很多長期使用和建設 Kafka 的工程團隊。我們帶到倫敦的，是 AutoMQ 的開源實現、KIP-1183、海外客戶的生產實踐，以及過去幾年圍繞 Diskless Kafka 做出的工程選擇。

在現場，我們和 IBM、Apple、OpenAI 等多個 Kafka 技術團隊交流了 AutoMQ 低延遲 Diskless Kafka 的架構設計。大家直接討論幾個工程問題：持久數據為什么可以從 Broker 本地盤遷移到共享存儲，Kafka 客戶端和周邊生態如何保持兼容，Broker 故障恢復和擴縮容時怎樣減少數據搬遷。在這樣的技術交流里，AutoMQ 的 Diskless Kafka 路線和低延遲共享存儲實現收到了很積極的反饋。我們也看到，全球一線企業的 Kafka 團隊同樣在探索下一代 Kafka 存儲架構，評估如何從 Broker 本地盤走向 Diskless / shared-storage 形態。在云上和 AI 應用帶來的實時數據需求下，本地盤、多副本復制和大規模數據搬遷，已經成為很多團隊繞不開的負擔。

02

AutoMQ 的 Diskless Kafka 路線

AutoMQ 的技術創新之所以得到這么多開發者關注和認可，原因很直接：Apache Kafka 以 Broker 本地磁盤為中心的傳統架構，已經越來越難滿足云和 AI 時代對成本、彈性和實時數據處理的要求。

Kafka 的協議、語義和生態仍然很成熟，需要重新設計的是存儲模型。HN 評論、KIP-1183 和倫敦現場交流反復回到同一個問題：Kafka 要繼續適配云上和 AI 時代的實時數據需求，Broker 是否還應該和持久數據綁定在一起？

傳統 Kafka 的 shared-nothing 架構在數據中心時代非常合理：每臺 Broker 管理自己的本地磁盤，Partition 數據通過 ISR 在多個 Broker 間復制，系統用應用層副本來獲得可靠性。那個時代，機器之間復制數據通常不會單獨出現在云賬單里，存儲和計算綁定在同一臺物理機上，也是一種簡單直接的工程選擇。

到了云上，這套前提變了。云基礎設施已經把持久性、跨可用區冗余和彈性容量做成了標準服務，但傳統 Kafka 仍然按數據中心時代的方式運行。結果是，團隊在云上同時承擔了幾類重復成本：

?存儲層面，云盤已經提供持久性，傳統 Kafka 仍然會把同一份 Partition 數據復制到多個 Broker。用戶要準備多份云盤容量，也要為副本寫入付出成本。

?網絡層面，Broker 之間跨可用區復制 Partition 數據，會形成持續的跨 AZ 流量成本。

?運維層面，擴縮容除了增減計算節點，還要搬遷大量 Partition 數據，重平衡過程可能持續數小時。

?資源層面，計算、存儲和網絡被綁在 Broker 上，團隊很難只為某一類資源獨立擴容。

AutoMQ 的 Diskless 架構把持久數據放到共享存儲，讓 Broker 成為無狀態計算節點，同時保留 Kafka 的協議、語義和生態。Broker 故障替換或擴縮容時，系統主要切換元數據和流量歸屬，不再為每一次容量變化搬遷大量 Partition 數據。

對企業用戶來說，架構升級不能讓業務代碼和上下游生態重來。AutoMQ 基于 Apache Kafka 代碼庫，在接入層保留 Kafka 的協議語義和客戶端生態，在存儲層用 S3Stream 和共享對象存儲替代傳統本地 LogSegment。客戶端、Connect、Flink、Schema Registry 和運維習慣都可以延續。

下面這張圖比較了 Apache Kafka 和 AutoMQ 在架構上的差異。

03

持續技術創新與全球化

Diskless Kafka 能不能成立，最終要看生產環境。AutoMQ 最早的一批高強度反饋來自國內客戶。

在國內推進 AutoMQ，更像本土作戰。相比海外市場，國內客戶給了我們更早的初始信任，也愿意更早把關鍵 Kafka 負載交給 AutoMQ；國內互聯網業務的數據規模、鏈路復雜度和高峰流量，又讓產品很快面對真實生產壓力。穩定性、Kafka 兼容性、遷移工具、擴縮容過程、故障定位和運維診斷，這些能力都在一線場景里被反復打磨。

2024 年，得物可觀測平臺大面積投產 AutoMQ。2025 年，京東、騰訊在多條業務線使用 AutoMQ，吉利汽車等企業也在生產場景中采用 AutoMQ。2026 年，愛奇藝也開始在業務場景中采用 AutoMQ。這幾年的國內落地，把 AutoMQ 放進了不同類型的高強度場景，也打磨了內核、遷移和運維能力。京東、騰訊、吉利汽車這樣的中國企業服務著大規模用戶和復雜業務，它們的生產驗證，讓海外客戶理解 AutoMQ 時多了一層可參照的工程背景。

進入海外市場后，信任要重新建立。對一家中國背景的基礎軟件公司來說，海外客戶的評估會更謹慎：團隊是否理解 Kafka，架構設計能否解釋清楚，代碼能否通過客戶自己的測試，生產問題出現后能否定位和修復。AutoMQ 采用 Apache 2.0 License 開源，讓用戶可以直接讀代碼、跑測試、看實現細節，也能沿著 issue、PR 和公開設計理解系統為什么這樣工作。

開源之外，我們也持續把技術細節講出來。AutoMQ 定期在國內外分享分區秒級遷移如何實現，基于對象存儲的流存儲引擎如何工作，為什么可以做到 100% Kafka 兼容，以及 Diskless Kafka 和共享存儲架構在云上的取舍。這些分享讓海外開發者看到 AutoMQ 的工程方法和技術判斷，看到這個新架構名字背后的具體實現。代碼、文章、演講、社區討論和生產驗證疊在一起，才讓一個陌生項目進入工程團隊的選型和架構評估。

帶著這些積累，AutoMQ 開始從國內走向東南亞和歐美。新加坡國民級出行應用 Grab、美國 CRM 領導者 HubSpot、英國美容健康領導者 Fresha、德國音樂流媒體巨頭 SoundCloud、瑞士全球物流領導者 Kuehne + Nagel，都在各自的 Kafka 生產場景里采用了 AutoMQ。這些客戶分布在不同地區和行業，面對的數據鏈路也不一樣。AutoMQ 走到這些場景里，靠的是開源透明、Kafka 兼容性、Diskless 架構帶來的彈性和成本優勢，也靠國內大規模生產場景積累下來的工程能力。

Fresha 是其中一個公開留下工程記錄的例子，也讓我們能直接聽到終端客戶自己的聲音。它是英國美容、健康與自我護理行業的 SaaS 平臺，數據平臺需要把大量 PostgreSQL CDC 事件寫入 Kafka，再由 Snowpipe、Flink、StarRocks 等系統消費。它的技術負責人 Anton Borisov 發布過兩篇公開文章，記錄團隊的遷移過程，也寫下了他對 AutoMQ 開源透明和持續創新的評價：

With AutoMQ, we can trace how the system works, why certain choices were made, and where it can improve.

That transparency: messy, evolving, but real is what keeps progress visible.

That’s why I have a soft spot for AutoMQ as they don’t just build the future, they open it up for everyone to build together, yet continuing pushing the frontier with new ideas and features.

— Anton Borisov, Fresha

工程團隊可以沿著代碼、設計和公開討論理解 AutoMQ，追蹤系統如何工作，判斷架構選擇為什么這樣做，也能看到后續還可以在哪里繼續改進。對基礎軟件來說，這種透明性會直接影響工程團隊是否愿意繼續評估、遷移和長期使用。

最終，AutoMQ 能進入 Grab、HubSpot、Fresha、SoundCloud、Kuehne + Nagel 等海外生產環境，靠的是幾件事一起發揮作用。開源帶來的透明性、持續技術分享建立的理解和信任、國內大規模生產場景提供的驗證，以及 Diskless Kafka 架構本身帶來的成本、彈性和運維價值，放在一起，才讓海外客戶愿意把 AutoMQ 放進真實 Kafka 鏈路。

04

展望未來

謝謝每一位 Star 過 AutoMQ、試用過 AutoMQ、提過 issue、貢獻過代碼、給過反饋的開發者。也謝謝那些愿意把 AutoMQ 放進真實生產環境的客戶。

10K Star 是個節點。我們會慶祝它，也會很快回到日常工作里：繼續寫代碼、修 issue、打磨文檔、服務客戶、和社區討論 Kafka 在云上的下一步。

接下來，AutoMQ 會繼續保持 Kafka 兼容和開源透明，繼續打磨低延遲 Diskless Kafka 架構，讓更多企業可以在云上運行關鍵 Kafka 負載時，少一點本地磁盤和數據搬遷帶來的負擔。面向實時分析、數據湖和 AI 應用帶來的新需求，我們也會繼續推進 Table Topic 等能力，讓 Kafka 數據更直接地進入下一代數據基礎設施。

回到那條 Star History 曲線，里面的每一個拐點，背后都有開發者的嘗試、客戶的驗證、伙伴的轉介紹和社區的討論。下一段曲線，希望和更多開發者、用戶和生態伙伴一起寫下去。

如果你也在評估 Kafka 的云原生化、成本優化或彈性擴縮容，可以從 AutoMQ 開源倉庫開始，直接閱讀代碼、運行測試環境，驗證 Diskless Kafka 是否適合你的生產工作負載：在 GitHub 上查看 AutoMQ。