Cloudflare 於二零二六年十月一日宣布推出 K2 無伺服器事件串流服務公開測試，把事件以有序持久日誌寫入建於 R2 物件儲存之上的串流，讓生產者與消費者在規模與時間上解耦。服務面向 Workers Paid 帳戶，測試期不收費，日後預計寫入與讀取各約每 GB 四美分、保留約每 GB 每月兩美分；單串流暫限約十 GB 儲存與每秒約三十 MB 寫入。

Cloudflare／官方：推出 K2 無伺服器事件串流公開測試——建於 R2 持久日誌；解耦生產者與消費者；測試期免費用、日後寫入／讀取每 GB 約四美分

傳統遠端程序呼叫架構要求生產者與消費者在規模與時間上對齊：上游突發流量過大、下游短暫故障，或同一事件需同時供給分析與風控等多個讀者時，訊息往往被丟棄。Cloudflare 在官方開發者網誌宣布以 K2 把事件寫入持久、有序的日誌串流，讓各方可按自身節奏消費，並支援長期保留。本文已核對 Cloudflare 官方網誌原文，來源真實性已驗證；以下整理技術機制、與 Queues／Basin Pipelines 的定位差異、定價與香港／亞洲開發者可落地的應用場景。

一、核心事件：邊緣上的無伺服器事件串流

技術細節

K2 定位為 Cloudflare Developer Platform 上的持久事件串流原語。開發者把事件送入串流後，系統以有序日誌保存；消費者可把讀取負載分散到多個工作節點，或以類似發布／訂閱的方式讓每個訂閱各自收到全部訊息。官方強調架構完全無伺服器，可擴展至大量資料，並支援長期保留，即使消費者長時間離線亦不致因緩衝耗盡而丟事件。

底層上，K2 在 R2 物件儲存之上實作分區持久日誌。官方指出 R2 具備極高耐久（文中寫「十一個九」）與強一致 API；把複製與共識下沉到儲存層，可使應用層更簡、更廉、更高吞吐，並讓運算與儲存獨立擴展。由於物件儲存不支援傳統 append，K2 先在邊緣服務記憶體累積寫入，短時間後把整批事件寫成足夠大的 segment 檔，再以 R2 原子操作維持嚴格遞增偏移。代價是產生延遲較高：初版公開測試下，寫入延遲在回應時間第九十九百分位約為一秒。

官方說明，K2 最初是為 Basin Pipelines 在邊緣提供「從不丟已接受事件」的耐久緩衝而建。Pipelines 採拉取式串流處理，需要另一系統先存事件再轉換寫入 R2；在橫跨逾三百三十五個城市、機器切片相對短暫的邊緣環境，難以直接部署傳統 Apache Kafka 叢集，因而改以 R2 為狀態原語重構日誌系統。

二、技術原理深度解析

與 Cloudflare Queues 相比，兩者都會接收、持久化並投遞事件，但粒度與目標不同。Queues 面向昂貴或耗時的個別工作項（例如影像處理請求），支援重試、延遲與死信佇列等訊息級控制。K2 則面向高規模資料搬運、長期保留與扇出消費：訊息以批次產生與消費，換取吞吐效率，但犧牲單則訊息級重試；批次化亦使寫入延遲高於 Queues。

與 Basin Pipelines 的分工亦清晰：若最終要把事件寫入物件儲存或 Iceberg 表，官方建議用 Pipelines；若需自訂處理或寫往其他目的地，則用 K2。換言之，K2 是「可被多種消費者拉取的耐久日誌」，而非取代所有非同步原語的單一產品。

消費模型上，建立訂閱後，客戶端呼叫 consume 取得一批事件並獲得約五分鐘租約，其後可 ack（確認已處理）、nack（要求重送）或延長租約。同一串流可採「多消費者分攤資料」或「每消費者各自訂閱、人人收到全部訊息」兩種模式，亦可混合。產生端支援 HTTP API 與 Worker binding；資料以位元組表示，應用可自選編碼格式。建立串流可用 cf CLI、Wrangler、儀表板或 API。

路線圖方面，官方預告未來數月將加入更高寫入並行（目標可達多 GB／秒級串流）、訊息鍵與依鍵排序保證、推送式 Worker 消費者、更低延遲的 Express 層，以及 Apache Kafka 客戶端的即插即用支援。

三、定價、可用性與限制

K2 現以公開測試形式提供給擁有 Workers Paid 訂閱的帳戶，初版限制包括：最多約十 GB 儲存用量、每串流寫入約每秒三十 MB。需要更高上限可經 Discord 或官方限額申請表聯絡團隊。測試期間用量不計費；開始收費後，官方預期定價為寫入約每 GB 四美分、讀取約每 GB 四美分、保留約每 GB 每月兩美分。上述數字均來自官方網誌，實際以 Cloudflare 帳單與文件為準。

四、日常應用場景

1. 開發者與技術團隊

電商後端完成交易後，可同時把事件扇出給分析管線與欺詐偵測服務，而無需兩者即時對齊吞吐。產品分析亦可在 Worker 內以 binding 寫入 page_view 等事件，再由訂閱池並行拉取處理。對已在邊緣跑代理或工作流的團隊，K2 可作為「接受後不丟」的耐久緩衝，銜接自訂消費者或日後的 Kafka 相容客戶端。

2. 企業與隱私敏感行業

金融、零售與運營商常見「同一事件多讀者」需求：合規稽核要長期保留，風控要近即時，報表可延遲。把日誌落在 R2 並以串流解耦，有助減少自建 Kafka 叢集的運維負擔。香港企業若已採用 Cloudflare Workers／R2，可先在測試額度內驗證延遲與批次語意是否符合 SLA，再評估正式計費後的成本模型。

3. 一般用戶

一般消費者不會直接接觸 K2，但會受惠於其上的產品體驗：例如結帳後庫存、積分與推薦更快一致，或應用在高峰時較少因訊息遺失而出現狀態錯亂。開發者把耐久串流下沉到平台層，終端體驗通常更穩。

4. 香港與亞洲市場視角

亞洲流量峰谷明顯，跨境電商與遊戲常要同時服務多區讀者。K2 強調邊緣就近與水平擴展，對香港、新加坡等節點密集市場有吸引力；但初版第九十九百分位約一秒的寫入延遲，未必適合極低延遲交易路徑，較適合分析、風控扇出、遙測與代理工作負載。企業亦應把資料管轄、保留天數（建立範例預設 retention_seconds 為 604800，即約七天，可按產品需求調整）與行業合規一併納入設計。

五、專業評價與潛在考量

優勢

以 R2 承載日誌，耐久與儲存成本結構清晰，運算與儲存可分開擴展。
明確對位 Queues 與 Pipelines，降低「又一個佇列」的產品混淆。
公開測試期免費用，並給出預期正式定價，方便做總擁有成本估算。
路線圖包含 Kafka 客戶端相容，有助既有生態遷移。

需要留意的地方

初版寫入延遲（約一秒級 p99）與批次消費語意，不適合替代所有低延遲或需單則精準重試的工作佇列。
測試額度（約十 GB、每秒約三十 MB）對大型企業僅屬試水；正式擴容需另申請。
正式計費時間表未在該文鎖定，採購應以後續官方帳單公告為準。
與傳統 Kafka 在作業介面、生態工具鏈上仍有差異，遷移需驗證。

結語

K2 把「邊緣耐久事件日誌」產品化：用 R2 換取簡化的共識與長期保留，換來的是較高的寫入延遲與批次導向的消費模型。對正在 Cloudflare 上組裝代理、分析與多讀者業務管線的團隊，這是 Birthday Week 系列中與 Workers KV Instant、Basin 等並列、卻定位清楚的新原語。若你在香港規劃雲端遷移、邊緣運算或需要穩定的事件驅動架構，可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security），把平台選型與零信任、可用性要求一併落地。

參考來源

Cloudflare 官方網誌：Announcing Cloudflare K2: serverless event streams（2026-10-01）— https://blog.cloudflare.com/cloudflare-k2-streams/
發現來源：Cloudflare Blog RSS — https://blog.cloudflare.com/rss/