celld 開源自架 Durable Objects，兼容同維運要自己處理

Durable Objects 離開 Cloudflare

iThome 報道，Deno 開源咗分散式執行環境 celld，等開發團隊可以喺自有 server 運行兼容範圍內嘅 Cloudflare Workers 同 Durable Objects app。呢件事值得睇，因為 Durable Objects 最吸引嗰套「運算連狀態一齊走」模式，一直同 Cloudflare 平台綁得好實；celld 就嘗試保留編程方式，再畀團隊自己揀機器、網絡同儲存位置。

Durable Objects 適合聊天室、協作文件、遊戲房間同 AI agent 呢類要協調狀態嘅工作。每個房間或者文件可以對應一個 object，由單一執行單元順序處理請求，避開多個節點同時改同一份狀態帶嚟嘅衝突。Cloudflare 原生服務幫你處理全球部署、生命週期同基建；celld 就將同一思路搬入企業自己控制嘅環境。

圖片：celld

SQLite 同 bucket 點樣接力

celld 入面每個「cell」都有獨立 SQLite database，節點內置 V8，用嚟執行由支援範圍內嘅 Wrangler 專案打包出嚟嘅程式。成個 fleet 共用一個 S3-compatible bucket，入面除咗有部署檔案同 SQLite 副本，仲有節點 lease、cell ownership 記錄同 peer 驗證 secret。呢個 bucket 實際上兼任持久儲存同簡化版協調層。

當請求搵到某個 cell，節點會靠 object storage 嘅 compare-and-swap 操作搶 ownership lease，同一個 epoch 只容許一個 writer。節點失效或者 cell 轉移時，另一個節點可以由 bucket 還原 SQLite 再接手。官方話，系統會等寫入複製到 bucket 先確認成功，目標係已確認嘅資料唔會因節點突然死機而消失；呢項保證同相關故障數據暫時主要來自項目自己嘅測試，未有足夠獨立實測交叉核對。

控制多咗，代管功能少咗

Cloudflare 原生 Durable Objects 包辦入口、TLS、runtime 更新、容量管理同 placement，收費就跟請求、運算時間同儲存用量計。資料位置方面，Cloudflare 官方文件列出 EU、US 同 FedRAMP jurisdiction，location hint 亦只屬盡力安排。celld 可以放喺指定 VM、私有環境同自選 bucket region，對資料管治或者既有基建限制較多嘅公司確實有用，不過硬件容量、跨區設計、監察、備份同復原時間都要自己定。

celld 呢個 alpha 亦未包齊平台層。官方限制包括每個 fleet 只跑一套 app，冇多租戶 scheduler、代管 ingress、全球 placement、自動更新服務同帳戶系統。新增節點只要指向同一 bucket，架構係幾直接；但新節點有冇足夠容量、流量點樣送到 owner、bucket 變慢時點處理，全部屬營運團隊嘅工作。

只兼容一部分 Workers 生態

celld 唔可以當成完整兼容或者一鍵取代 Cloudflare。 而家支援 module Workers、fetch、部分 JS RPC、service binding、靜態資產，Durable Objects 方面就有 SQLite storage、alarm 同部分 WebSocket 功能。KV、R2、Cache API、Workers AI、Vectorize、Hyperdrive、cron trigger、custom domain 同 TLS termination 都唔喺完整支援範圍，部分 Web Crypto、Node.js API、RPC 同 WebSocket 行為亦有缺口。

部署設定同樣只認一部分 Wrangler 格式：官方列明接受 wrangler.json 或 wrangler.jsonc，但唔接受 wrangler.toml；可用設定 key 亦有限，碰到 routes、kv_namespaces、triggers 等設定會直接報錯。現有 Workers 專案想搬過去，第一步應該係逐項盤點 binding、runtime API 同設定檔，唔好見到「runs Workers」就估原有 app 可以原封不動轉場。

安全責任直接交到你手

節點間請求有 HMAC、內容簽章、時效限制同防重播機制，不過 peer HTTP 本身冇 TLS。官方要求 peer address 只放喺可信私有網絡，或者用 WireGuard、Tailscale 呢類加密 overlay，peer port 唔應直接公開。公眾入口嘅 TLS、app 身份驗證、防火牆同網絡分段，都要部署者自行安排。

Bucket 權限尤其敏感，因為部署程式、資料副本、ownership 記錄同 fleet secret 全部喺入面；攞到 bucket credentials，基本上就攞到 fleet 管理員權限。官方亦明講 alpha 未適合 hostile multi-tenant 環境。換句話講，自有基建帶嚟指定資料位置同較大控制空間，同時亦將憑證輪換、最小權限、事故調查同版本修補交返畀公司自己。

現階段先用非關鍵 app 測試

celld 官網有成本、延遲同故障復原數據，亦宣稱大規模運行可以平好多；未有獨立 benchmark 前，呢啲數字只適合作估算起點。Cloudflare 帳單可以直接量度，celld 就要計埋 VM、bucket 操作、網絡、入口層、預留容量同 on-call 人手，兩邊唔可以淨係比較每次請求嘅標價。

撰文時 GitHub repo 顯示只有 3 個 commits，官方亦話 runtime 同 compatibility surface 仲喺變。想減少平台綁定、指定儲存位置，或者研究自有狀態運算嘅開發團隊，可以先用非關鍵 app 驗證 API、節點故障、bucket 權限同復原流程；正式承載客戶資料，就等兼容範圍、版本維護同獨立測試再成熟啲。

參考來源

• iThome — Deno開源celld專案，將Durable Objects有狀態運算帶到自有伺服器 — original report
• denoland/celld GitHub repository — 官方原始碼、架構概覽、專案狀態同部署說明
• celld：Cloudflare compatibility — 官方列出已支援、部分支援同未支援嘅 Workers／Durable Objects API
• celld：Limitations — 核對 alpha 階段、多租戶、入口、TLS、更新同節點調度限制
• celld：Security — 核對 peer 連線、bucket credentials、管理員權限同部署者安全責任
• celld：Testing — 了解官方測試方法同效能、故障數據嘅來源及適用條件
• Cloudflare Durable Objects documentation — 核對原生 Durable Objects 嘅定位、狀態運算模式同代管功能
• Cloudflare Durable Objects：Data location — 核對 jurisdiction、location hint 同資料位置限制

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。