從 OpenAI 的 Kafka 實(shí)踐看 Kafka 的云原生演進(jìn)

2025 年 6 月的 Confluent Current 大會(huì)上，OpenAI 的實(shí)時(shí)基礎(chǔ)設(shè)施團(tuán)隊(duì)連續(xù)做了兩場分享，完整披露了他們?nèi)绾卧谝荒陜?nèi)將 Apache Kafka 吞吐量提升 20 倍、可用性從不到 3 個(gè) 9 拉到 5 個(gè) 9（來源：OpenAI at Confluent Current 2025）。更值得拆解的是他們?yōu)榇朔艞壛耸裁矗号判颉⑹聞?wù)、分區(qū)處理，這些 Kafka 最核心的語義。

1 37 個(gè)集群、5 萬連接、3 個(gè) 9 都保不住

2024 年上半年，OpenAI 的流處理平臺(tái)已經(jīng)被幾乎所有產(chǎn)品團(tuán)隊(duì)采用，數(shù)據(jù)攝入、異步處理、服務(wù)間通信，ChatGPT 的后端鏈路上到處都是 Kafka。但平臺(tái)本身的狀態(tài)用"混亂"來形容并不過分。

當(dāng)時(shí) OpenAI 內(nèi)部有超過 30 個(gè)獨(dú)立的 Kafka 集群，大多數(shù)是各產(chǎn)品團(tuán)隊(duì)在不同時(shí)期臨時(shí)自建的。這些集群配置互不兼容，部分甚至運(yùn)行在不同的 Kafka 兼容引擎上。一個(gè)新加入的工程師面對(duì)的第一個(gè)問題不是"怎么用 Kafka"，而是"我的 topic 在哪個(gè)集群上"。產(chǎn)品團(tuán)隊(duì)接入 Kafka 要花數(shù)天甚至數(shù)周，本來幾小時(shí)就該搞定。

擴(kuò)展性問題更為嚴(yán)峻。OpenAI 的外部服務(wù)有大量副本來承載 ChatGPT 的流量，每個(gè)副本都獨(dú)立連接 Kafka 集群。更棘手的是，OpenAI 主要使用 Python，而 Python 的 GIL 限制意味著單個(gè) pod 內(nèi)需要運(yùn)行多達(dá) 50 個(gè)獨(dú)立進(jìn)程來榨取并行性能，每個(gè)進(jìn)程都會(huì)建立自己的 Kafka 連接。結(jié)果是某個(gè)集群的單個(gè) broker 承受了 50,000 個(gè)并發(fā)連接，JVM 內(nèi)存直接打滿，連接不斷被丟棄。這不是連接風(fēng)暴，而是穩(wěn)態(tài)下的常態(tài)過載。

可用性方面，Kafka 集群是許多內(nèi)部服務(wù)的單點(diǎn)故障。一次區(qū)域故障或集群崩潰就意味著面向外部的產(chǎn)品硬停機(jī)或數(shù)據(jù)丟失。整個(gè)平臺(tái)連 3 個(gè) 9 都撐不住，對(duì)于支撐 ChatGPT 的基礎(chǔ)設(shè)施來說，這是不可接受的。

這些問題都還能忍。真正卡死他們的是基礎(chǔ)設(shè)施團(tuán)隊(duì)根本動(dòng)不了：產(chǎn)品服務(wù)與具體的 Kafka 集群緊耦合，想做集群遷移、版本升級(jí)、甚至只是調(diào)整配置，都需要協(xié)調(diào)大量產(chǎn)品團(tuán)隊(duì)。

2 在 Kafka 之上再建一層

要打破這種耦合，OpenAI 選擇了一個(gè)經(jīng)典的架構(gòu)手段：在客戶端和 Kafka 集群之間加一層代理，讓所有服務(wù)都通過代理交互，而不是直連集群。

首先要解決的是連接數(shù)爆炸。他們構(gòu)建了 Prism，一個(gè)極簡的 gRPC 服務(wù)，只暴露一個(gè) ProduceBatch 端點(diǎn)。生產(chǎn)者把消息和目標(biāo) topic 發(fā)給 Prism，由 Prism 負(fù)責(zé)路由到正確的底層 Kafka 集群。用戶不再需要知道哪個(gè)集群承載哪個(gè) topic，也不需要配置集群憑證和防火墻規(guī)則。他們甚至開發(fā)了一個(gè)叫 Photon 的客戶端庫，讓接入簡化到"import 庫，調(diào)用一個(gè)函數(shù)"的程度。單個(gè) Prism pod 服務(wù)多個(gè)客戶端 pod，Kafka broker 的直連數(shù)大幅收斂。

連接數(shù)收斂了，但集群耦合還在。Prism 真正強(qiáng)大的地方在于多集群路由：同一個(gè) topic 可以由多個(gè) Kafka 集群服務(wù)，Prism 負(fù)責(zé)在這些集群之間做負(fù)載均衡。如果某個(gè)集群的發(fā)布請(qǐng)求失敗，Prism 會(huì)透明地重試到另一個(gè)集群；如果某個(gè)集群長時(shí)間降級(jí)，熔斷器會(huì)將其標(biāo)記為不可用，自動(dòng)繞過。配合 Cluster Group 的概念（一組包含相同 topic 的 Kafka 集群集合），高可用 Cluster Group 將多個(gè)集群部署在不同區(qū)域，Prism 寫入任意一個(gè)健康的集群。所有這些對(duì)生產(chǎn)者完全不可見。

openai prism for kafka生產(chǎn)者側(cè)解耦了，消費(fèi)者側(cè)同樣需要脫離對(duì) Kafka 客戶端的直接依賴。OpenAI 采用了 Uber 開源的 UForwarder，并將其定制為內(nèi)部的 Kafka Forwarder。這是一個(gè)推送模型的消費(fèi)平臺(tái)：UForwarder 從 Kafka 拉取消息，通過 gRPC 推送給消費(fèi)者服務(wù)。消費(fèi)者只需要暴露一個(gè)處理消息的 gRPC 端點(diǎn)，不需要接觸 Kafka 客戶端、不需要管理 offset、不需要配置憑證。UForwarder 還內(nèi)置了重試、死信隊(duì)列等生產(chǎn)級(jí)能力，并且支持超越 partition 數(shù)量的并行度。

uber UForwarder for kafka遷移過程本身設(shè)計(jì)得很巧妙：在新集群上創(chuàng)建 topic，UForwarder 同時(shí)從新舊集群消費(fèi)，Prism 逐步將寫入切換到新集群，舊集群數(shù)據(jù)過期后下線。單次遷移約 30 分鐘完成流量切換，對(duì)用戶完全透明。最終成果：

3 代價(jià)：為了可用性，OpenAI 放棄了什么

OpenAI 的工程師在演講中非常坦誠地承認(rèn)了一件事：這套架構(gòu)要求他們放棄 Kafka 的幾項(xiàng)核心語義。

這不是邊緣功能的取舍。排序、事務(wù)、分區(qū)，這些是 Kafka 區(qū)別于普通消息隊(duì)列的核心能力，是很多流處理場景的基礎(chǔ)假設(shè)。OpenAI 的哲學(xué)是"Simple things should be simple, complex things should be possible"，他們?yōu)樯贁?shù)需要這些能力的用例保留了直連 Kafka 的逃生通道，但絕大多數(shù)用例被引導(dǎo)到了代理層。

OpenAI 的工程師說，經(jīng)驗(yàn)上用戶確實(shí)不太在意這些限制，采用率反而因?yàn)楹喕焖僭鲩L。這在 OpenAI 的語境下可能是對(duì)的，他們的 Kafka 用例以異步處理和數(shù)據(jù)攝入為主，對(duì)排序和事務(wù)的需求確實(shí)不高。但對(duì)于更廣泛的 Kafka 用戶群體來說，這個(gè) trade-off 暴露了一個(gè)根本性的問題：如果獲得云級(jí)別的彈性和可用性，必須以放棄核心語義為代價(jià)，那說明問題不在應(yīng)用層的 trade-off 決策，而在 Kafka 引擎層本身。

4 繞行方案背后的根因

OpenAI 用代理層繞過的每一個(gè)問題，根因都一樣：broker 既管計(jì)算又管存儲(chǔ)，狀態(tài)和節(jié)點(diǎn)綁死。如果這個(gè)根因在引擎層被解決，broker 變成無狀態(tài)的，數(shù)據(jù)持久化到共享對(duì)象存儲(chǔ)，這些繞行方案就失去了存在的前提。

回到 OpenAI 那個(gè) 5 萬連接打滿 JVM 的場景。他們用 Prism 收斂連接數(shù)，本質(zhì)上是因?yàn)椴荒茈S意增加 broker，每加一個(gè) broker 就要做數(shù)據(jù) rebalance，搬遷大量分區(qū)副本，過程緩慢且影響在線流量。如果 broker 是無狀態(tài)的，擴(kuò)容就是加一個(gè)計(jì)算節(jié)點(diǎn)的事情，連接容量隨 broker 數(shù)量線性擴(kuò)展，甚至可以用 Kubernetes HPA 自動(dòng)伸縮。

擴(kuò)容的故事也類似。OpenAI 選擇"加新集群"而非"給現(xiàn)有集群加 broker"來做水平擴(kuò)展，就是因?yàn)楹笳叩?rebalance 太危險(xiǎn)。當(dāng) partition 的數(shù)據(jù)不在 broker 本地而是在共享存儲(chǔ)上時(shí)，partition 遷移變成純?cè)獢?shù)據(jù)操作：更新一下"這個(gè) partition 由哪個(gè) broker 服務(wù)"的映射關(guān)系就行，不搬一個(gè)字節(jié)的數(shù)據(jù)。彈性問題從根源上消失了。

再看 OpenAI 花了最大工程量的部分：多集群 HA Group、Prism 熔斷器、跨集群重試，這整套故障轉(zhuǎn)移體系。傳統(tǒng) Kafka 的多副本復(fù)制提供了 broker 級(jí)別的容錯(cuò)，但面對(duì)區(qū)域故障或整個(gè)集群不可用的場景，副本復(fù)制無能為力，因?yàn)楦北径荚谕粋€(gè)集群內(nèi)。

如果數(shù)據(jù)直接寫入 S3 等對(duì)象存儲(chǔ)，持久化天然是多 AZ 的（S3 通過糾刪碼提供 11 個(gè) 9 的持久性），broker 故障時(shí)任何存活節(jié)點(diǎn)都可以接管分區(qū)并在數(shù)秒內(nèi)恢復(fù)服務(wù)。S3 的多 AZ 糾刪碼已經(jīng)做了這件事，OpenAI 在應(yīng)用層又做了一遍。

當(dāng)單集群就能通過彈性伸縮應(yīng)對(duì)流量變化、通過對(duì)象存儲(chǔ)保證跨 AZ 持久性時(shí)，OpenAI 維護(hù) 37 個(gè)集群的前提就不存在了。集群數(shù)量自然收斂，ZooKeeper 的瓶頸也隨之消失，存算分離架構(gòu)天然適配 KRaft，無需外部協(xié)調(diào)組件。而最關(guān)鍵的是，OpenAI 放棄排序、exactly-once semantics、分區(qū)處理，根本原因是多集群路由破壞了 key 到 partition 的映射關(guān)系。在存算分離架構(gòu)下，單集群就能提供足夠的彈性和可用性，不需要多集群路由這個(gè)前提，自然也就不需要放棄這些語義。100% 的 Kafka 協(xié)議兼容意味著所有現(xiàn)有的 Kafka 客戶端、Kafka Connect、Kafka Streams 都可以無縫使用，不需要改一行代碼。

AutoMQ 就是沿著這個(gè)方向構(gòu)建的存算分離 Kafka 實(shí)現(xiàn)。把 OpenAI 的每個(gè)痛點(diǎn)、他們的代理層方案、以及引擎層的直接解法放在一起：

當(dāng)然，把數(shù)據(jù)寫到 S3 不是沒有代價(jià)。對(duì)象存儲(chǔ)的 API 調(diào)用延遲高于本地磁盤，尾延遲（p99/p999）需要額外優(yōu)化；高頻小批量寫入場景下 S3 API 調(diào)用本身的成本也不能忽略。這是一個(gè)不同的工程權(quán)衡點(diǎn)，不是銀彈。

存儲(chǔ)成本方面，傳統(tǒng) Kafka 的三副本復(fù)制疊加 EBS（Elastic Block Store）自身的冗余復(fù)制，實(shí)際存儲(chǔ)冗余度遠(yuǎn)高于對(duì)象存儲(chǔ)的糾刪碼方案。存算分離架構(gòu)消除了 broker 間的副本復(fù)制，數(shù)據(jù)直接寫入 S3，由對(duì)象存儲(chǔ)的糾刪碼保證持久性，存儲(chǔ)成本顯著降低。具體的成本對(duì)比數(shù)據(jù)可參考 AutoMQ 官方 benchmark。

5 路標(biāo)與終點(diǎn)

在 2025 年 6 月 Confluent Current 的 Q&A 環(huán)節(jié)，有人問 OpenAI 的工程師怎么看 Diskless Kafka，回答是"非常積極地在思考和探索"。當(dāng)你已經(jīng)為繞過傳統(tǒng) Kafka 的限制付出了這么大的工程代價(jià)，引擎層的根本性演進(jìn)自然是最有吸引力的下一步。OpenAI 證明了即使放棄排序和事務(wù)也能讓 Kafka 在超大規(guī)模下工作，但這個(gè)代價(jià)本身就是最好的論據(jù)：引擎層的演進(jìn)已經(jīng)不是可選項(xiàng)。對(duì)于正在規(guī)劃下一代流處理基礎(chǔ)設(shè)施的團(tuán)隊(duì)來說，問題只是現(xiàn)在就在引擎層解決，還是先建一層代理再說。

如果你也正在為各種 Kafka 挑戰(zhàn)而煩惱，可以立即通過 AutoMQ 官網(wǎng)或者 Github 體驗(yàn)和嘗試我們的產(chǎn)品。