Cloudflare 邊緣運算
狀態化邊緣計算：Durable Objects、Workflows 與即時協同應用開發
狀態化邊緣計算：Durable Objects、Workflows 與即時協同應用開發
Workers 跑得再快，本質上還是無狀態的：一個隔離區處理完這次請求，下一次未必是同一個隔離區接手，狀態留不住。Cloudflare 補上這塊缺口的做法是 Durable Objects，把運算與儲存綁在同一個單例實體上，靠單執行緒天生排除並行衝突，不必自己寫分散式鎖，因此成為即時協作、計數器這類需要嚴格排序場景的首選。
長任務則交給 Workflows：把一個流程拆成一個個步驟，哪一步失敗就重跑哪一步，不必整條重來。官方架構文件揭露一個關鍵細節：每個 Workflow 實例背後，其實就是一個由 SQLite 支援的 Durable Object，兩者在底層是同一家人。2026 年，Cloudflare 更進一步為了 AI agent 以接近機器的速度大量呼叫 workflow，重新設計了控制層架構。
你將學到什麼
Durable Objects 是什麼？
運算與儲存綁在同一個單例實體上，天生單執行緒，不必自己搶鎖或加分散式鎖。
強一致性怎麼來的？
同一個實體同一時間只處理一個請求，其他請求排隊等候，並行衝突從架構上就被排除。
Workflows 是什麼？
把長任務拆成一步步可獨立重試的步驟，某一步失敗只重跑那一步，不必整條流程重來。
兩者其實是一家人
官方架構顯示，每個 Workflow 實例背後就是一個 SQLite 支援的 Durable Object，稱為 Engine。
以下把這兩塊拼圖拆開來看：Durable Objects 怎麼靠單例模型做到強一致、適合放進哪些場景，以及 Workflows 的步驟編排在底層怎麼運作。
為什麼無狀態的 Workers 撐不住這些場景？
V8 隔離區的特性是輕、快、可大量並存，但也因此不保證同一個使用者的下一次請求，會落在同一個隔離區上。狀態留不住，是 Workers 架構天生的取捨，不是實作沒做好。
- 多人共編的白板或文件，每個人的編輯動作都要落在同一份最新狀態上。
- 限量搶購的計數器，同一秒湧入的請求要嚴格排隊扣減庫存，不能有兩個人搶到同一件。
- 需要記住上一步進度的長任務，中斷後要能從斷點接續，而不是從頭開始。
Durable Objects 就是官方針對這個缺口設計的解法，它把運算與儲存綁在同一個單例實體上，同一個實體、同一份狀態，不必在多個隔離區之間同步。
Durable Objects 如何靠單例模型做到強一致？
每個 Durable Object 實體是單獨一份，官方文件說它會自動佈署在靠近第一次請求來源的位置，且它的儲存空間只屬於它自己。
關鍵在於它是單執行緒、合作式多工，同一個實體同一時間只處理一個請求，其他請求得排隊。
- 不用自己寫鎖：並行衝突從架構上就被排除，不必額外引入分散式鎖機制。
- 儲存分兩層：記憶體內狀態負責快速讀寫，另有交易式、強一致的持久化儲存，可透過鍵值或 SQL 介面存取。
- 儲存私有：一個實體的儲存空間，其他實體完全存取不到，天生做到隔離。
與其把 Durable Objects 想成資料庫，不如想成一個帶著私有硬碟、天生只能一次做一件事的常駐小程式。需要搶鎖的場景，把「誰能動這筆資料」這件事直接交給某一個固定的 Durable Object 實體處理，天生沒有並行衝突。
這個排隊機制也有代價：如果某個實體同時湧入大量請求，它自己就會變成處理速度的瓶頸。常見的因應方式是依業務邏輯拆分，例如一個房間一個實體、一筆訂單一個實體，讓熱點分散到多個實體上，而不是把所有流量塞進同一個實體硬扛。
多人協作的 WebSocket 連線，該接到哪裡？
官方文件把「多個 WebSocket 客戶端連到同一個 Durable Object 實體，互相協調」列為代表性場景，聊天室與多人遊戲都是例子。
做法是每個房間、每張畫布對應一個固定的 Durable Object 實體，所有參與者的連線都接到同一個實體，狀態更新在這裡集中處理再廣播出去。
- 單一房間的訊息量與人數會直接影響這個實體的負載，人數多、更新頻率高的場景要提早評估是否分房。
- 斷線重連要設計狀態同步機制，讓重新連上的使用者能拿到目前最新的狀態，而不是從零開始。
- 實體所在的地理位置固定在第一次請求來源附近，跨洲協作的延遲會比同區域協作明顯。
這個模式的好處是不用另外架設一台專門處理連線狀態的伺服器，代價是實體要撐住整個房間的訊息量，設計時得把上面這幾個限制一併考慮進去。
長任務該怎麼交給可重試的步驟處理？
有些流程天生要跑很久，串接多個外部 API、等待人工核准、或是分批處理大量資料，中途任何一步失敗都不該讓整條流程從頭來過。
官方把 Workflows 定位成建構這類多步驟應用的平台，開發者不需要自己處理逾時與重試邏輯，每個步驟可以獨立重試，狀態能維持從幾分鐘到幾週的時間跨度。
- 步驟之間的狀態自動保存，某一步失敗重跑時不會遺失前面已完成步驟的結果。
- 逾時與重試策略由平台管理，不必自己寫一套指數退避的重試迴圈。
- 支援長時間的休眠等待，例如等一個外部審核流程走完，中間不必占用運算資源空跑。
對開發者來說，等於把「這一步做完了，換下一步」與「這一步失敗了，怎麼安全地重來」這兩件麻煩事，都交給平台處理。
Workflows 底層真的只是一個 Durable Object 嗎？
官方架構文章揭露了一個有意思的細節：每個 Workflow 實例背後，其實是一個由 SQLite 支援的 Durable Object，官方稱它為 Engine，負責執行該實例的步驟、重試與休眠邏輯。
| 元件 | 角色 |
|---|---|
| Durable Objects | 提供單例、強一致的運算與儲存單元，是底層積木 |
| Workflow 的 Engine | 每個 Workflow 實例對應一個 SQLite 支援的 Durable Object，負責跑該實例的步驟與重試 |
| Workflows 平台 | 在 Engine 之上，再包一層步驟編排、重試策略與可觀測性的開發者介面 |
理解這層關係，有助於判斷該直接用 Durable Objects 自己刻協調邏輯，還是交給 Workflows 現成的步驟編排機制。
2026 年為什麼要重新設計 Workflows 的控制層？
Cloudflare 官方部落格在 2026 年 4 月發文說明，Workflows 原本設計是承接人類觸發的操作，例如使用者完成註冊後跑一段後製流程，呼叫頻率相對從容。
隨著 AI agent 在背景以接近機器的速度大量建立與呼叫 workflow 實例，原本集中在單一元件上的控制層容易變成瓶頸，官方因此把它重新設計為可以水平擴展的架構。簡單說，當呼叫方是人類，系統可以假設請求之間有明顯間隔；當呼叫方是大量並行運作的 agent，這個假設不再成立，控制層要撐住的是完全不同量級的建立與查詢頻率。
官方公告同時大幅提高了同時執行實例數、建立速率與排隊上限這幾項容量指標，確切數字會隨版本調整，規劃前請直接查當期官方公告。
落地前的三個檢查點
- 需要嚴格排序、不能並行衝突的狀態，例如計數器或房間狀態，優先考慮 Durable Objects 而不是自己在應用層搶鎖。
- 任務天生要跑很久、牽涉多個外部呼叫，優先考慮 Workflows 的步驟拆解與自動重試，而不是自己寫一套重試邏輯。
- WebSocket 協作場景，先估算單一房間的訊息量與人數上限，必要時提早規劃拆分多個 Durable Object 實體的機制。
