在承载数十万个租户账号Web流量的边缘平台上，一个Cloudflare Worker、一个fetch处理函数和一个路由的初始架构很容易理解，但位于大型SaaS产品前方的Worker会不断累积职责。图片优化、故障转移页面、路由、请求标头和Cookie重写以及按租户配置查询等功能陆续加入，且大多由不同团队维护，最初的单个文件逐渐变成所有人都在修改、却没有团队全权负责的共享单体，其危害在边缘场景下更为严重。

在SaaS规模下，Worker处在所有请求的同步路径上，每增加1毫秒耗时，所有用户都会多等1毫秒。平台运行在多个CDN上，同一功能必须在所有CDN上正常运行。只有一个Worker时，任何改动都会重新部署整个脚本，所有团队的发布节奏由最慢的变更决定，回滚一个功能就是回滚所有功能。Worker还存在硬性资源上限，每个功能的依赖项都会导致共享代码包膨胀，并在热路径中增加解析和启动工作。

边缘会放大单体架构的所有弊端：在应用服务器里只是麻烦的耦合问题，到这里就变成可用性风险。解决思路是保留边缘最看重的轻量入口，同时给每个团队一个属于自己、可以独立测试并按自己节奏部署的单元。拆分最直接的反对理由是成本，但Cloudflare的服务绑定让Worker之间的调用在同一台机器、同一个隔离沙箱内完成调度，没有DNS解析、TLS握手等网络开销，调用写法与fetch()一样，开销近似普通函数调用，使边缘侧的模块拆分具备可行性。

该模式由一个前置的精简网关Worker和一组单一用途的功能Worker组成。网关只拥有组合逻辑（判断当前请求要启用哪些功能、执行顺序）和全局横切关注点（请求预处理、请求标头规范化、可观测性），不包含功能逻辑。每个功能Worker只拥有一个关注点、自己的依赖包、测试套件和部署流程，从而实现内部高内聚、彼此低耦合。