celld：Deno开源的自托管Durable Objects替代方案

什么是celld

近日，Deno团队开源了一个名为 celld 的新项目，在GitHub上迅速走红，单日新增星标超过500个，目前累计已达2371星。这个用Rust编写的项目，定位相当清晰：一个自托管、可分布式部署的 Durable Objects 实现。

对于熟悉Cloudflare生态的开发者来说，Durable Objects（持久对象）并不陌生。它是Cloudflare Workers生态中一项极具特色的能力，用于在边缘环境中提供有状态、强一致性的计算单元。具体而言，Durable Objects是Cloudflare在2020年推出的一项创新技术，它本质上是一个结合了单线程Actor模型和持久化存储的编程原语。每个Durable Object都拥有自己的私有存储（基于SQLite或KV存储）和独占的执行线程，这意味着开发者无需担心并发锁或分布式事务问题。与传统的数据库+缓存架构不同，Durable Object将计算和状态紧密绑定在一起，实现了"数据跟着代码走"的设计哲学。在Cloudflare的实现中，Durable Objects会根据请求来源自动迁移到最优的边缘节点，实现智能化的数据局部性。

值得深入了解的是，Durable Objects底层使用SQLite作为持久化存储引擎。SQLite是全球部署量最大的数据库引擎（估计超过1万亿个活跃实例），它以嵌入式库的形式运行，无需独立的服务器进程。Cloudflare在2022年将Durable Objects的存储后端从自研KV存储迁移到SQLite，原因在于SQLite提供了完整的ACID事务语义、丰富的SQL查询能力和经过数十年验证的可靠性。对于celld而言，每个Durable Object对应一个独立的SQLite数据库文件，这种"每对象一数据库"的架构天然实现了数据隔离，同时保持了极低的读写延迟（本地磁盘I/O，无网络往返）。

要理解这种设计的革命性，可以将其与传统的微服务架构对比。在典型的微服务系统中，应用逻辑（无状态的计算层）和数据（有状态的存储层）是分离的：服务实例从Redis缓存或PostgreSQL数据库中读取状态，处理完后再写回。这种分离虽然带来了横向扩展的灵活性，但也引入了缓存失效、分布式锁竞争和网络往返延迟等复杂性。Durable Objects彻底消除了这层间接性——状态就在计算发生的地方，读写操作都是本地内存级别的速度，只有在持久化时才涉及磁盘I/O。这种"colocated compute and state"的模式，在需要频繁读写共享状态的场景下，性能优势可达数个数量级。

而celld的出现，意味着开发者可以在自己的基础设施上运行类似的能力，摆脱对特定云厂商的绑定。

celld项目主页

Durable Objects究竟解决什么问题

从无状态到有状态的边缘计算

传统的Serverless函数（如AWS Lambda、Cloudflare Workers）本质上是无状态的——每次请求都可能被调度到不同的实例，函数之间不共享内存状态。这在处理大量独立请求时非常高效，但一旦涉及到需要维护会话、协调并发、保证顺序的场景，就会遇到困难。

这里需要理解"无状态"设计的深层权衡。无状态函数的优势在于极致的弹性伸缩：因为任何实例都可以处理任何请求，负载均衡器可以自由地将流量分配到任何可用节点。AWS Lambda可以在毫秒内从0扩展到数千个并发实例，正是得益于这种无状态特性。然而，当开发者需要实现诸如"同一用户的请求必须按顺序处理"或"多个客户端需要看到一致的共享状态"时，就不得不引入外部协调机制——Redis分布式锁、数据库乐观并发控制或消息队列的顺序投递。这些外部依赖不仅增加了系统复杂度，还引入了额外的网络延迟和潜在的故障点。

Durable Objects的核心思想是：为每一个逻辑实体分配一个全局唯一、单点存在的对象。无论请求来自何处，同一个对象ID的所有请求都会被路由到同一个实例上处理。这天然地解决了并发协调和状态一致性的难题。

从分布式系统理论的角度看，这一设计本质上是在CAP定理中做出了特定权衡。CAP定理指出一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三者最多只能同时满足两个。Durable Objects选择了CP（一致性+分区容错），牺牲了部分可用性：当对象所在节点不可达时，该对象的请求会失败而非返回过期数据。这与最终一致性系统（如DynamoDB默认模式或Cassandra）形成鲜明对比。对于计数器、限流、协作编辑等场景，强一致性是刚性需求；而对于社交媒体feed或推荐系统，最终一致性通常就足够了。理解这一权衡有助于开发者判断celld是否适合自己的场景。

这一设计深受Actor模型的影响。Actor模型最早由Carl Hewitt在1973年提出，后来被Erlang/OTP广泛应用于电信系统中。在Actor模型中，每个Actor是最基本的计算单元，拥有自己的私有状态，只通过消息传递与外界交互。Erlang的成功验证了这一模型的工程价值：爱立信使用Erlang构建的AXD301 ATM交换机实现了99.9999999%（九个9）的可用性，其核心就是依赖Actor模型实现的故障隔离和热更新能力。

Durable Objects继承了这一思想，但做了重要扩展：它在Actor的基础上加入了持久化存储，使得即使对象被回收（GC），状态也不会丢失；同时通过全局唯一ID实现了跨集群的精确路由。Microsoft的Orleans框架（Virtual Actor模型）也是类似的思路——Orleans引入了"Virtual"的概念，即Actor不需要显式创建和销毁，框架会在收到消息时自动激活Actor并在空闲时自动回收，开发者只需关注业务逻辑。Xbox Live的后端服务就大量使用Orleans来管理数百万玩家的实时状态。但Orleans主要面向后端集群，而Durable Objects将这一模型推广到了边缘计算场景，并且利用Cloudflare的全球网络实现了Actor的地理位置感知——对象会自动"飘"到请求最多的区域，这是传统Actor框架所不具备的特性。

典型应用场景

这类技术特别适合以下场景：

实时协作：如多人在线文档、白板，需要一个中心化的协调点管理编辑状态。以Google Docs类产品为例，当多名用户同时编辑同一段落时，系统需要一个权威的状态协调者来解决冲突。Durable Objects为每个文档分配一个对象，所有对该文档的编辑操作都串行通过这个对象处理，天然避免了Operational Transformation（OT）或CRDT算法中的复杂冲突解决逻辑。
聊天室与游戏房间：每个房间对应一个对象，管理成员和消息广播。一个典型的多人在线游戏可能有数十万个同时活跃的房间，每个房间需要维护玩家列表、游戏状态和消息历史。传统方案需要一个Redis集群来存储这些分散的状态，而Durable Objects让每个房间成为一个自包含的计算单元。
限流与计数器：需要强一致的计数，避免分布式环境下的竞态。例如API限流场景中，如果使用Redis集群做分布式计数，由于网络分区和复制延迟，可能出现短暂超额的情况。Durable Objects的单点执行保证了计数的绝对精确。
WebSocket连接管理：维护长连接的状态。每个Durable Object可以同时持有数百个WebSocket连接，并在收到消息时向所有连接广播，本质上充当了一个轻量级的消息代理。

以往这些能力如果想要，几乎只能选择Cloudflare的托管服务。celld则把这套模型带到了自托管世界。

celld的技术架构与核心价值

用Rust构建的高性能分布式基础设施

celld选择Rust作为实现语言，这符合近年来基础设施软件的技术趋势。Rust自2015年发布1.0版本以来，已经在系统编程领域建立了稳固的地位。它的核心竞争力在于"零成本抽象"——开发者可以写出高层次的安全代码，编译后获得接近C/C++的运行时性能。Rust的所有权系统和借用检查器在编译期就消除了数据竞争、悬垂指针和内存泄漏等问题，这对于需要7×24运行的基础设施软件尤为关键。

具体到celld的场景，Rust的优势体现得尤为明显。一个Durable Objects运行时需要同时管理大量活跃对象的生命周期——创建、激活、休眠、持久化、迁移——这些操作涉及精细的内存管理和并发控制。在Go或Java中，垃圾回收器的STW（Stop-The-World）暂停可能导致延迟尖刺，对于需要亚毫秒级响应的实时应用是不可接受的。Rust没有垃圾回收器，内存在编译期就确定了精确的分配和释放时机，运行时延迟完全可预测。

近年来，Tokio异步运行时的成熟使得Rust在网络编程领域如虎添翼。Tokio提供了一个多线程的工作窃取（work-stealing）调度器，能够高效地在少量OS线程上调度数十万个异步任务。配合tower中间件生态和hyper HTTP库，Rust已经形成了完整的网络服务开发栈。Linux内核已开始接纳Rust代码（从6.1版本起），而TiKV（分布式KV存储）、Firecracker（AWS Lambda底层的microVM）、Bottlerocket（AWS的容器操作系统）等重要基础设施项目都选择了Rust，celld的技术选型延续了这一工程趋势。

对于Durable Objects这类需要精确管理状态、路由和一致性的系统而言，Rust的类型系统和所有权模型能有效降低隐蔽的并发bug，确保在高并发场景下的稳定性。

分布式对象路由与一致性保证

celld实现分布式Durable Objects的核心技术挑战在于：如何保证同一个对象ID在整个集群中只有一个活跃实例。这涉及分布式共识这一计算机科学的经典难题。常见的解决方案包括基于一致性哈希的静态路由（类似Amazon DynamoDB的分区策略）或基于分布式锁/租约的动态调度。一致性哈希将对象ID映射到特定节点，优点是无需中心协调器，缺点是节点变更时需要状态迁移。租约机制则允许对象在节点间动态迁移，通过类似etcd/ZooKeeper的分布式协调服务来仲裁对象的归属权。Cloudflare内部使用基于Colo（数据中心代号）的智能路由算法，综合考虑请求来源地理位置和节点负载来决定对象放置。celld需要在自托管环境中实现类似的路由保证，同时保持API层面与Cloudflare Durable Objects的兼容性。

celld架构相关

摆脱云厂商锁定的自托管方案

celld最大的价值主张在于**self-hosted（自托管）和distributed（分布式）**这两个关键词。

长期以来，Durable Objects是Cloudflare的独门能力，开发者一旦依赖它，就很难迁移到其他平台。云厂商锁定（Vendor Lock-in）是云计算时代最受争议的话题之一。当企业深度使用某家云厂商的专有服务后，迁移成本会随时间指数级增长——不仅涉及技术重构，还包括运维知识、监控告警体系和团队技能的重新适配。据Gartner统计，约70%的企业表示曾因锁定效应被迫接受不合理的价格上涨。

锁定效应的技术层面更为微妙。以Durable Objects为例，如果一个应用的核心状态管理逻辑都围绕Durable Objects的API设计——包括alarm（定时唤醒）、transactional storage（事务性存储）和WebSocket hibernate（连接休眠）等Cloudflare专有特性——那么迁移意味着几乎重写整个状态层。这比简单的"换一个对象存储服务"要复杂得多，因为Durable Objects不仅仅是存储，它是一个融合了计算、存储和网络路由的完整编程模型。

开源替代方案的价值在于提供"可逃逸性"：即使企业当前使用某家云服务，只要底层编程模型与开源方案兼容，就保留了未来迁移的可能性。Kubernetes对AWS ECS的替代、MinIO对S3的替代，都是这一趋势的典型案例。celld对Durable Objects的开源替代，延续了这条"开源平权"的路径。

企业可以在私有云、混合云甚至本地数据中心部署这套能力，既保留了Durable Objects编程模型的便利，又获得了对基础设施的完全控制权。

Deno边缘计算生态的战略延伸

有意思的是，celld出自Deno团队之手。Deno由Node.js创始人Ryan Dahl于2018年创建，最初定位为"更好的Node.js"，强调安全性（默认沙箱）、TypeScript原生支持和现代Web标准兼容。作为一个现代JavaScript/TypeScript运行时，Deno一直在探索边缘计算和Serverless的方向。

Ryan Dahl在2018年的JSConf演讲"10 Things I Regret About Node.js"中详细阐述了创建Deno的动机：Node.js的安全模型过于宽松（任何npm包都能访问文件系统和网络）、package.json和node_modules的设计导致了依赖地狱、缺乏对TypeScript的原生支持等。Deno从底层重新设计了这些方面——默认情况下脚本无法访问文件、网络或环境变量，必须通过显式的权限标志授权。这种"最小权限原则"的安全模型对于边缘计算环境尤为重要，因为边缘节点可能运行来自不同租户的不可信代码。

celld运行用户代码时依赖的隔离机制基于V8 Isolates技术。V8 Isolate的安全模型源自Chrome浏览器的多进程架构理念——每个Isolate拥有独立的堆内存和垃圾回收器，一个Isolate中的代码无法访问另一个Isolate的内存空间。这种隔离在底层由操作系统的虚拟内存机制和V8引擎的内部检查共同保障。此外，WebAssembly（Wasm）作为补充隔离层也在边缘计算领域快速崛起：Wasm模块只能访问显式导入的函数和线性内存，无法直接调用系统API。Fastly的Compute@Edge和Fermyon的Spin等边缘计算平台就采用Wasm作为核心隔离层，celld未来也可能在这一方向上进行探索。

2021年Deno推出Deno Deploy——一个基于V8 Isolates的边缘计算平台，直接对标Cloudflare Workers。V8 Isolates技术允许在同一进程中运行数千个隔离的JavaScript执行环境，启动时间仅需几毫秒，远低于容器（通常100ms-1s）或虚拟机（数秒到数十秒）方案。V8 Isolates的核心优势在于共享底层的V8引擎实例和编译器基础设施，每个Isolate只需额外分配少量内存（通常几MB）来维护自己的堆和执行上下文。相比之下，一个Docker容器即使运行最精简的Alpine Linux镜像也需要数十MB的基础开销。这种轻量级隔离使得单台服务器可以同时运行数万个租户的代码，将多租户部署的经济性推到了极致。Deno Deploy目前在全球35+个区域拥有边缘节点。

celld的推出，可以看作是Deno在构建完整边缘计算栈上的又一步棋——补齐有状态计算这块拼图。使其边缘计算栈从"只能跑无状态函数"升级为"可以构建复杂有状态应用"的完整平台。从战略角度看，Deno正在构建一个从运行时（Deno CLI）到云平台（Deno Deploy）再到基础设施组件（celld）的完整技术栈，这使其在与Node.js/Vercel和Bun/Cloudflare的竞争中拥有差异化的定位。

对开发者意味着什么

需要理性看待的适用边界

当然，也要保持理性。Cloudflare的Durable Objects之所以强大，很大程度上依赖其全球边缘网络——请求能被就近路由到离用户最近的节点。Cloudflare拥有遍布100多个国家、310多个城市的数据中心，这种全球基础设施密度是任何单一企业难以复制的。自托管方案在网络覆盖、边缘节点密度上难以与全球性云网络相提并论。

更具体地说，Cloudflare网络的另一个隐藏优势是其Anycast路由技术。当用户发起请求时，BGP路由协议会自动将流量导向最近的Cloudflare数据中心，而无需DNS层面的地理路由判断。这意味着即使DNS缓存过期或用户使用VPN，路由仍然是最优的。自托管部署通常依赖DNS GeoDNS或Application Load Balancer做地理分发，在网络层面的优化深度上存在先天差距。

celld更适合那些对数据主权、成本控制、私有部署有强需求的场景，而非追求极致全球低延迟的应用。例如金融机构因合规要求（如GDPR、中国《数据安全法》或新加坡MAS指引）必须将数据留在本地、游戏公司希望在特定区域部署专用服务器以获得可预测的延迟表现、或是对Cloudflare定价模型不满意的中小团队（Durable Objects按请求数和存储量计费，高流量场景下成本可能快速攀升），这些都是celld的理想用户画像。

此外，作为一个新兴的开源项目，celld的生态成熟度、文档完善度和生产环境验证仍需时间积累。当前的高热度更多反映了社区对这一方向的期待。生产级使用需要考虑的因素远不止核心功能——监控可观测性（分布式追踪、指标采集）、故障恢复机制（对象迁移的一致性保证）、多租户隔离的安全边界、以及与现有基础设施（Kubernetes、Terraform等）的集成便利性，都是企业评估时需要重点关注的维度。

总结

celld的出现，是开源社区对云厂商专有能力的又一次"平权"尝试。它把Cloudflare式的Durable Objects编程模型带到了自托管、分布式的语境下，用Rust保证了底层的可靠性与性能。

对于关注边缘计算、有状态Serverless架构的团队来说，celld值得持续关注。它既是Deno完善自身生态的战略布局，也为整个行业提供了一个摆脱厂商锁定的重要参考。随着项目的成熟，我们或许会看到更多自托管的"边缘计算全家桶"方案出现，推动整个边缘计算生态向更开放、更多元的方向演进。从更长远的视角来看，celld所代表的趋势——将云厂商的创新性设计通过开源标准化并回馈社区——可能最终倒逼云厂商在功能创新和定价策略上更加积极，形成良性的竞争循环，最终受益的是整个开发者生态。