背景
Cloudflare 近期以公開測試版推出 K2，定位是無伺服器（serverless）事件串流服務，運作核心是一份存放在 R2 物件儲存中的分區持久日誌（partitioned durable log），也就是把事件切成多個分區、以只追加的紀錄形式保存下來，讓消費者依序讀取。這項服務其實來自內部需求：Cloudflare 的資料管線服務 Basin Pipelines 需要一個足夠耐用的地方，先把事件停放下來，再交給採拉取（pull-based）模式的處理引擎讀取與轉換。多數公司在這個階段會直接選 Apache Kafka，但 Cloudflare 無法這樣做。管線運行在橫跨 335 個以上城市的邊緣網路上，執行於零散、短暫的機器，彼此透過公共互聯網連結，而 Kafka 的設計假設根本不是這回事。於是他們選擇建在原本就負責耐用性的那一層：R2 提供強一致 API 與所謂「十一個九」的耐用度（99.999999999% 資料保存比例）。把複製與共識（consensus）下沉到儲存層之後，上層應用變得更簡單，運算與儲存也能各自獨立擴張。這篇報導由 InfoQ 的 Steef-Jan Wiggers 於 2026 年 10 月 9 日刊出，原始文章則署名 Micah Wylde 與 Marc Selwan。
核心內容
物件儲存有一個先天限制：它不能追加（append），而整個抽象剛好就是一份日誌。K2 的解法是先讓邊緣服務把寫入暫存在記憶體中，刻意停頓一下等待更多事件到來，再把累積的批次寫成一個區段檔（segment file）。R2 的原子操作（atomic operations）負責提供排序與遞增的偏移量（offset），因此整套系統不需要任何協調服務。而那個停頓，就是延遲的來源。Cloudflare 直接給出數字：產生端延遲（produce latency）在 p99 約一秒。讀取端採用以租約為基礎的 consume API，消費者輪詢訂閱後會取得一份租期五分鐘的批次，接著以確認（acknowledge）、否定確認（negative ack）觸發重新投遞，或延長租約。這種設計能提高讀取並行度，特別適合消費者本身是並行能力強、但單一算力不大的 Workers。寫入端則透過 Worker 綁定送出批次，並回傳錯誤是否值得重試，讓程式判斷要用 503 或 500 回應；K2 把資料表示成位元組（bytes），編碼交給應用層自行處理。
技術與效能爭議
Hacker News 上的反應多半肯定這個架構方向，但對數字頗為挑剔。有評論指出物件儲存正迅速成為新的核心資料基底（data substrate），「用 S3 重做 Kafka、用 S3 重做 GitHub」已是明顯趨勢；自稱是文章作者兼 K2 技術主管的網友則表示，凡是不需要低於 100 毫秒延遲的資料系統都在往物件儲存走，而且他的團隊就坐在 R2 團隊旁邊，兩個產品可以共同演進。真正尖銳的交鋒來自一位公測使用者：他實測寫入在一秒內，但端對端投遞延遲 p95 達 2.5 秒、p99 達 7.5 秒，並追問這是否符合預期。代表團隊回應的網友承認長尾延遲高於預期，Consume API 在效能上還有功課，讀取延遲的改善大約一週內就能看到。另一位在同領域開發 s2.dev 的競爭者則提出反面觀點：機會其實可以下探到 100 毫秒以下，因為 S3 Express、GCS rapid buckets 等較快的物件儲存層已經出現，只是它們屬單可用區（single-zone），跨區耐用仍需仲裁寫入（quorum write）。他描述的根本張力是：要把資料留多久才刷進物件儲存，等於在延遲與 PUT 操作成本之間直接取捨；他的服務以後端常駐程序持續寫入混雜多個串流的多租戶物件，在同區域做到約 50 毫秒的 p99 確認延遲，同時維持單位經濟性。
影響與限制
價格引來另一項實質質疑。每產生 1 GB 收費 0.04 美元被認為與其他雲端事件串流相當，但消費端同樣按 0.04 美元計價就顯得偏高：最單純的一個消費者情境，實際成本已是 0.08 美元/GB，而扇出（fan-out，一份資料同時餵給多個消費者）的策略會讓費用迅速上升，偏偏扇出正是 Cloudflare 為 K2 定位的用例之一。保留（retention）另計每月每 GB 0.02 美元，公測期間不收費。同一位網友也替成本辯護，認為 K2 相對 Google Pub/Sub 的優勢在於成本，尤其是需要較長保留期時；憑藉物件儲存，它也比自行架構或 Amazon MSK、Confluent 這類託管 Kafka 便宜，且沒有叢集要管理，資料量增長時效能一致。至於與 AutoMQ、WarpStream 這類同樣採物件儲存模式的方案、以及 Kafka 自身的無磁碟主題有何差別，有網友替團隊回答：K2 是為 Cloudflare 生態系打造的，單獨使用意義不大。Kafka 相容已列入路線圖，技術主管坦言自己並不喜歡 Kafka API，認為它對一般使用者太底層、對深度整合又太上層，還需要複雜的客戶端函式庫。目前 Beta 限制為單一串流 10 GB 儲存與 30 MB/s 產生量，訊息金鑰與依金鑰排序、每秒數 GB 的寫入並行度、推播式 Worker 消費者、更低延遲的 express 層與 Kafka 客戶端支援，都列為後續工作；串流可從儀表板、API、Wrangler 或 Cloudflare 同周推出的 cf 指令列工具建立。綜合這些反應，爭點已不在架構是否合理，而在延遲的地板究竟在哪裡：Cloudflare 公布產生端一秒，使用者實測端對端長尾是它的好幾倍，競爭者則宣稱同區域狀態化刷寫能做到 50 毫秒。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。