冷启动一直是 Serverless 与边缘计算平台无法回避的痛点。对于运行在 Cloudflare 网络上的 Workers 而言,冷启动不仅影响单次请求的响应延迟,更会因为频繁驱逐与重新实例化而浪费内存与计算资源。Cloudflare 在早期通过在 TLS 握手阶段利用 SNI 做预热,显著降低了首次请求的冷启动可见延迟;但随着用户在 Workers 上部署越来越复杂的应用,冷启动耗时已逐步超越 TLS 握手的时长,单靠握手预热的策略已不足以满足更高的体验与规模要求。为此,Cloudflare 推出了一套基于一致性哈希的"Worker 分片"(Worker sharding)技术,旨在通过路由请求到已有的"热"实例来大幅减少冷启动的发生。本文将从根本问题、实现思路、关键技术与实际效果四个维度,系统性地说明分片如何改变冷启动博弈,并探讨这一策略的工程要点与适用场景。 为什么冷启动变得更难消除 Worker 的冷启动包含一系列环节:从脚本源代码的取回、压缩数据传输、代码编译,到顶层代码执行与首次请求调用。
任何环节的增长都会延长冷启动的时长。近几年,Cloudflare 为满足用户对复杂应用的需求,逐步放宽了对 Workers 的限制:付费用户的脚本压缩后大小从最初的 1MB 上调到 5MB,随后又提升到 10MB;免费用户的上限也从 1MB 提升至 3MB;同时启动阶段允许的 CPU 时间从 200ms 增加到 400ms。这些放松看似利好开发者,但对冷启动带来了双重负担:更多数据需要在实例化时传输与解析,代码编译复杂度上升,顶层初始化逻辑可能更长,导致冷启动总耗时有显著增长。 Cloudflare 早期的 TLS 握手预热利用了 TLS SNI 在握手首次消息即传递目的域名的特性。握手时间被视为用户必须等待的时间窗口,平台在这段时间内触发 Worker 的预热流程,理论上可以把冷启动"藏"在握手之中,让用户感受不到延迟。然而当冷启动耗时超过握手耗时时,预热的效果就有限了。
因此降低冷启动的绝对发生概率,成为一种更有效的策略:与其继续在每次请求上与握手竞速,不如尽可能把请求路由到已经存在的热实例上。 从单机孤岛到整体缓存式分片思维 很多 CDN 与缓存系统的高命中率来自于把逻辑缓存打散到数据中心内的各个服务器上,并通过哈希算法将同一资源的请求路由到同一台服务器,以提高命中率与资源利用。Cloudflare 的 HTTP 缓存长期采用一致性哈希环来减少服务扩缩容时的重映射。Worker 分片理念正是把相同的思想应用到运行时:把数据中心视为一个逻辑上的"Worker 池",通过一致性哈希将 Worker 脚本 ID 映射到数据中心内的某台"分片服务器"(shard server),并把接到请求的服务器作为"分片客户端"(shard client)根据同一哈希环将请求路由到分片服务器上执行。 传统做法中,每台服务器都独立维护本地的 Worker 集合,若请求落到没有热实例的机器上就会直接触发冷启动,导致在低流量但多节点负载均衡下,冷启动频繁发生。以一分钟一次的请求分布到 300 台服务器为例,每台平均每 5 小时才收到一次请求;这段间隔足够导致本地实例被驱逐,从而每次都要冷启动。
通过分片把这些分散请求集中到少数节点上,可以让某台服务器长期保持热实例,显著降低驱逐率与冷启动概率。 一致性哈希环的优势在于稳定性:服务器上下线只会影响环上相邻一段映射,避免大规模迁移与重新冷启动。映射过程为:对 Worker 脚本 ID 进行哈希定位到环上,找到环上紧随其位置的服务器作为 home(分片服务器)。分片客户端对该哈希环有相同视图,接收请求后决定将请求转发到对应分片服务器。 处理过载的必要性 将请求集中到少数节点带来优势,但也存在风险:某些 Worker 的请求可能突然爆发,单个分片服务器承载会导致过载。Worker 并非静态缓存对象,而是可以执行长时间且不定性计算的活跃实体,单个请求可能占用高达数分钟的 CPU 时间。
因此设计必须支持水平扩容与优雅的负载削峰,让系统在需要时能够创建额外实例而不产生错误或不一致。 为此,分片机制要求分片服务器能够在高负载时拒绝执行请求,同时分片客户端要能优雅处理这种拒绝。常见两种负载削峰方式分别是先询问许可(类似 HTTP 的 Expect: 100-continue)和先发送请求再由服务器决定是否转发。前者增加一轮往返延迟,后者可能扩大 trombone 问题(请求字节被先发送到分片服务器,然后转发回客户端或其他节点)。Cloudflare 在实践中选择了后者的优化方案,并结合底层 RPC 框架对 trombone 效果做了最小化处理。 Cap'n Proto 与乐观发送:减少 trombone 的工程技巧 Workers 运行时内部使用 Cap'n Proto RPC 做跨实例通信。
Cap'n Proto 的分布式对象模型(capability)允许在 RPC 调用中传递对对象的"句柄",这为实现延迟加载、拒绝后回退等复杂场景提供了一个天然的构建块。分片客户端在向分片服务器发送请求时,会附带一个指向本地懒加载 Worker 实例的 capability;该本地实例在本地尚未被真正冷启动,只有在被调用时才会触发实例化。如果分片服务器决定因负载或资源紧张而拒绝执行,则不是简单返回错误,而是把传入的 capability 原样返回给分片客户端。 分片客户端在收到返回的 capability 后会意识到这是一个本地 capability,于是会中断对分片服务器的继续上载请求体,并把剩余的字节直接发送给本地懒加载实例。这样,分片服务器并没有为无谓的数据传输消耗带宽与计算,也避免了请求在网络中反复绕行导致的高延迟。这一技巧将"乐观发送"的好处最大化:在绝大多数情况下分片服务器会接收并执行请求,从而避免冷启动;在少数需要拒绝的情况下,回退成本被控制到最小。
Worker 相互调用与上下文迁移 实际应用中,一个请求往往涉及多个 Worker 的嵌套调用,例如动态调度 Worker(dynamic dispatch)、用户 Worker、以及可能的出站 Worker(outbound Worker)。Workers for Platforms 场景更为复杂,调度 Worker 会选择并调用用户 Worker,用户 Worker 可能再调用出站 Worker 或服务绑定(Service Bindings),请求的执行链条会在多台服务器之间扩散。为了确保跨实例迁移后语义与资源限额、追踪、权限等上下文保持一致,分片实现需要把执行上下文序列化,并通过 Cap'n Proto 在节点间传输和复原。 Cloudflare 将上下文栈(包括所有权覆盖、资源限制、信任等级、尾随 Worker 配置、出站 Worker 参数以及追踪回调等)序列化为 Cap'n Proto 数据结构,传递给分片服务器。分片服务器反序列化为本地对象并继续执行。更多令人称道的是,Cap'n Proto 的 capability 让回调能够透明地指向原始主机;例如,在动态调度 Worker 的场景中,可以创建一个 reportTraces() 的 capability 放入上下文栈,这样被分片到多个节点的子调用都能把追踪数据上报回动态调度 Worker 的 home 服务器,实现追踪数据的集中汇总,而无需分片节点关心目标主机的位置。
实际部署效果与指标提升 分片功能在全面部署后,Cloudflare 观测到显著的运营与体验收益。尽管仅约 4% 的企业流量请求被分片(这些请求大多是低频长尾 Worker),但全局 Worker 驱逐率下降了 10 倍。驱逐率是衡量内存压力和实例生命周期频繁程度的重要指标,驱逐率下降意味着系统能够在更长时间内保持热实例,内存与 CPU 的利用效率显著提升。对于企业流量而言,暖请求率(即请求命中热实例的比例)从 99.9% 提升到 99.99%,代表冷启动发生率从 0.1% 下降到 0.01%,整体冷启动事件减少了十倍。 这种高杠杆效应源于互联网流量的幂律分布:大部分请求集中到少数高流量 Worker,而大量低流量 Worker 组成长尾。分片主要帮助长尾低频 Worker 把请求集中到更少的宿主机器,从根本上减少了这些 Worker 的驱逐与冷启动,因而在总体上带来超比例的改进。
工程与实践启示 分片策略的成功离不开若干工程决策的支撑。首先,使用一致性哈希环避免了因服务器拓扑变化导致的大规模重新映射,从而减小了冷启动回撤的面。其次,选择乐观发送加上 capability 回退的设计,在性能与鲁棒性间找到了平衡:避免了额外的握手延迟,同时确保拒绝场景能高效退回本地执行。再次,通过序列化上下文并将回调以 capability 的形式传递,分片可以安全地支持复杂的 Workers 嵌套、服务绑定与平台级的调度模式。 未来展望与未尽之事 虽然分片显著减少了冷启动并提高了资源利用,但 Cloudflare 团队明显还在继续优化:图表顶部仍有一丝空间,向 99.999%(五个九)目标迈进仍是长期工程与算法优化的方向。未来可能涉及更细粒度的热度预测、更智能的请求聚合策略、跨数据中心共享热实例的研究,或者基于实时负载与成本模型进行更动态的分片调度。
总结 对于边缘计算平台而言,冷启动不是单纯的延迟问题,而是与内存管理、实例生命周期、路由策略、跨实例通信等多维因素紧密相关。Cloudflare 的分片方案通过把一致性哈希与 Cap'n Proto 的能力结合起来,实现了在不牺牲可扩展性的前提下,显著降低冷启动发生率并提升系统效率。分片不只是工程上的优化,更是一种思维转换:把数据中心视为一个整体的计算资源池,通过智能路由与最小化回退成本,让热实例最大化其价值。对于运行高可用、低延迟应用的工程团队而言,理解并利用类似的分片与能力模型,是应对冷启动挑战的有效路径。 。
