边缘计算中的单体陷阱与破局之道

在构建面向全球多租户的 SaaS 平台时，开发者往往倾向于使用一个简单的 Cloudflare Worker 来处理所有请求。这种模式在初期非常轻量且高效，但随着业务增长，单一入口很快会演变成“共享单体”。

面临的核心挑战

当平台承载数十万个租户时，这种单体架构的弊端会急剧放大：

• 部署耦合：所有功能共享同一个部署单元。任何微小的代码修改都需要重新部署整个脚本，导致不同团队的发布节奏被迫同步，回滚风险极高。
• 故障爆炸半径：Worker 位于请求的同步路径上。代码中的异常、正则表达式错误或热点循环，不仅会拖垮该功能，还会导致整个平台对所有租户不可用。
• 资源与权责错配：所有团队共享有限的 CPU 和脚本大小配额。由于缺乏明确的边界，修改“图片优化”功能的开发者可能无意中破坏了“故障转移”逻辑，引发合并冲突。

解决方案：模块化 Worker 架构

要解决这些问题，最直观的办法是拆分，但直接拆分到多个服务会增加网络延迟，违背了边缘计算“低延迟”的核心意义。在 Cloudflare 上，我们可以利用服务绑定技术，在不牺牲性能的前提下实现模块化。

1. 架构设计：网关与功能 Worker

我们将架构拆分为两层：

• 网关 Worker（Gateway）：作为唯一入口，负责全局路由、请求预处理（如标头重写）和可观测性。它不包含具体业务逻辑，只负责决策。
• 功能 Worker（Feature Workers）：每个功能拥有独立的 Worker，只负责单一职责（如图片优化、故障转移）。它们拥有独立的依赖、测试套件和部署流程。

2. 核心机制：服务绑定

这是该方案的关键。不同于 HTTP 调用，Cloudflare 的服务绑定允许网关在同一个隔离沙箱内调用其他 Worker。

• 零网络开销：调度发生在本地，没有 DNS 解析、TLS 握手或往返延迟，开销近似普通函数调用。
• 隔离性：各 Worker 的依赖和资源配额完全隔离。

3. 实战代码与逻辑编排

网关通过“内联判断 + 远程调用”的模式来编排功能。网关会先在本地执行判断函数 shouldApply()，只有当条件满足时，才通过服务绑定调度对应的 Worker。

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    // 1. 阶段一：故障转移拦截（请求阶段）
    if ((await shouldServeFailover(request, env)).serve) {
      return env.FAILOVER.fetch(request);
    }

    // 2. 阶段二：请求预处理
    const originRequest = prepareOriginRequest(request, env);

    // 3. 阶段三：图片优化决策
    const response = (await shouldOptimize(originRequest, env)).optimize 
      ? await env.IMAGE_OPTIMIZER.fetch(originRequest) 
      : await fetchFromOriginOrCache(originRequest, ctx);

    // 4. 阶段四：响应阶段拦截
    return shouldServeFailoverForResponse(request, response).serve 
      ? env.FAILOVER.fetch(request) 
      : sanitize(response);
  }
};

4. 容错与降级策略

在多租户架构中，容错至关重要。当某个功能 Worker 发生异常或超时时，网关不应返回错误页面，而应直接回退到源站原始响应。这种设计确保了即使下游服务挂掉，用户的请求依然能被处理，极大地降低了可用性风险。

5. 保持契约一致：单一代码库策略

虽然我们拆分了部署单元，但建议将所有 Worker 放在同一个代码库中。理由如下：

• 避免契约漂移：如果拆分到多个仓库，接口变更会变得极其困难，集成测试成本高昂。
• 唯一事实来源：同库开发能确保网关与功能 Worker 的接口契约始终一致。

通过这种方式，我们既获得了独立服务的所有权和部署灵活性，又保留了单一代码库的一致性。

跨平台移植性思考

这种“网关模式”并非所有边缘计算平台都原生支持。例如，在 Akamai 上，计算单元是插件而非拥有完整请求上下文的处理器，难以实现类似 Cloudflare 的灵活编排。因此，在选择边缘架构时，必须考察平台提供的底层原语是否支持这种细粒度的模块化调用。