Cloudflare模块化Worker应对多租户边缘计算挑战

一个承载数十万个租户流量的边缘平台，最初可能只有一个Cloudflare Worker和一个fetch入口，用于拦截请求、改写标头并转发源站。但随着图片优化、故障转移、路由、Cookie处理和租户配置查询不断加入，单一入口会变成由多个团队共同维护、却无人完整负责的“边缘单体”。由于Worker位于所有请求的同步路径上，任何额外的1毫秒都会被所有用户共同承担。

这种架构会带来多重风险：所有改动绑定在一次部署中，发布节奏受最慢功能限制；异常、低效正则或热点循环可能影响全部功能和租户；共享的CPU额度、脚本体积及依赖还会造成资源竞争。故障转移等稳定功能与快速迭代的图片处理功能被迫共处，也容易引发合并冲突、权责不清和不敢修改代码的问题。在多CDN环境中，同一能力还必须适配不同平台。

可行方案是保留一个轻量网关，并将各项能力拆成独立Worker。Cloudflare的服务绑定可在同一机器和隔离沙箱内调度，调用开销接近普通函数调用，避免传统微服务的DNS、TLS和网络往返成本。网关只负责组合顺序、请求预处理、标头规范化和可观测性，功能Worker则拥有自己的依赖、测试和发布流程。

网关通过轻量的shouldApply判断是否需要启用功能，只有判断为真时才通过绑定执行实际任务。典型流程是先检查故障转移，再进行请求预处理，随后决定是否交给图片优化Worker，最后在响应阶段处理源站5xx等情况。网关仅持有Fetcher，不引入功能代码，因此依赖和CPU配额彼此隔离；功能Worker异常或超时时，可退回未经转换的源站响应，避免单个模块拖垮整条请求链。

为控制契约漂移，网关与各功能Worker可放在同一代码库中，通过包边界保持独立构建和部署，既共享接口这一事实来源，又不共享发布节奏。不过，模块化也会带来协调和观测成本：请求链上的下游Worker只能看到局部信息，网关通过响应标头传递诊断数据时，下游内部捕获的信息仍可能丢失，端到端追踪不再像单体架构那样天然完整。

这套设计不能直接平移到所有CDN。Cloudflare以完整请求为中心，Worker可自行决策、调用其他Worker、访问源站并改写响应；Akamai则以property规则引擎为配置单元，Image Manager属于由规则启用的托管能力，EdgeWorker只是特定生命周期事件中的插件，不能直接调用图像转换逻辑。实际实现中，EdgeWorker只能计算租户是否退出图片转换，并将结果写入PMUSER_SKIP_TRANSFORM等请求变量，再由下游property读取。因此，跨CDN复用的关键不只是迁移代码，还要重新适配平台提供的底层原语。