导航菜单

Smart Placement

默认情况下,WorkersPages Functions 会在接收请求的数据中心中执行。如果你在 Worker 中运行后端逻辑,将 Worker 部署在更接近后端基础设施(比如数据库)的位置,而不是更接近最终用户的位置,可能会获得更好的性能。Smart Placement(智能部署)可以自动将你的工作负载放置在最佳位置,以最小化延迟并加速应用程序。

背景

以下示例演示了将 Worker 部署在更接近后端服务的位置如何降低应用程序延迟:

假设你有一个位于澳大利亚悉尼的用户正在访问运行在 Workers 上的应用程序。该应用程序需要多次往返位于德国法兰克福的数据库才能响应用户的请求。

未启用 Smart Placement 的情况:位于悉尼的用户连接到同一区域的 Worker,然后多次往返位于法兰克福的数据库

问题在于 Worker 需要多次往返数据库所花费的时间。启用 Smart Placement 后,Cloudflare 网络会在最接近数据库的数据中心处理请求,而不是在接近用户的位置处理。

启用 Smart Placement 的情况:位于悉尼的用户连接到位于法兰克福的 Worker,然后多次往返位于法兰克福的数据库

Smart Placement 工作原理

Smart Placement 是按 Worker 启用的。一旦启用,Smart Placement 会定期分析 Worker 在全球不同 Cloudflare 位置的请求持续时间。Smart Placement 通过比较在接收请求的位置(Worker 默认运行的位置)的估计请求持续时间与全球一组候选位置的请求持续时间来决定在哪里运行 Worker。对于每个候选位置,Smart Placement 会考虑 Worker 在该位置的性能以及将请求转发到该位置所增加的网络延迟。如果最佳候选位置的估计请求持续时间明显快于接收请求的位置,请求将被转发到该候选位置。否则,Worker 将在最接近接收请求位置的默认位置运行。

Smart Placement 只会考虑 Worker 之前运行过的候选位置,因为每个候选位置的估计请求持续时间是基于 Worker 在该位置运行的历史数据。这意味着 Smart Placement 无法在 Worker 通常不接收流量的位置运行 Worker。

Smart Placement 只影响 fetch 事件处理器 的执行。Smart Placement 不会影响 RPC 方法命名入口点 的执行。没有 fetch 事件处理器的 Worker 将被 Smart Placement 忽略。对于同时具有 fetch 和非 fetch 事件处理器的 Worker,Smart Placement 只会影响 fetch 事件处理器的执行。

同样,Smart Placement 不会影响 静态资源 的提供位置。静态资源将继续从最接近传入请求的位置提供。如果 Worker 被调用并且你的代码通过 静态资源绑定 检索资源,那么资源将从你的 Worker 运行的位置提供。

启用 Smart Placement

Smart Placement 适用于所有 Workers 计划的用户。

通过 Wrangler 启用 Smart Placement

要通过 Wrangler 启用 Smart Placement:

  1. 确保已安装 wrangler@2.20.0 或更高版本(安装指南)。

  2. 在你的 Worker 项目的 Wrangler 配置文件中添加以下内容:

    wrangler.jsonc

    {
      "$schema": "./node_modules/wrangler/config-schema.json",
      "placement": {
        "mode": "smart"
      }
    }
    

    wrangler.toml

    [placement]
    mode = "smart"
    
  3. 等待 Smart Placement 分析你的 Worker。此过程可能需要最多 15 分钟。

  4. 查看你的 Worker 的请求持续时间分析

通过 Dashboard 启用 Smart Placement

要通过 Dashboard 启用 Smart Placement:

  1. 在 Cloudflare Dashboard 中,转到 Workers & Pages 页面。

    前往 Workers & Pages

  2. 概览 中,选择你的 Worker。

  3. 选择 设置 > 常规

  4. 部署位置 下,选择 智能

  5. 等待 Smart Placement 分析你的 Worker。Smart Placement 需要来自全球多个位置的持续流量才能做出部署决策。分析过程可能需要最多 15 分钟。

  6. 查看你的 Worker 的请求持续时间分析

可观测性

部署状态

Worker 的元数据包含有关 Worker 部署状态的详细信息。通过以下 Workers API 端点查询你的 Worker 的部署状态:

curl -X GET https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/workers/services/{WORKER_NAME} \
-H "Authorization: Bearer <TOKEN>" \
-H "Content-Type: application/json" | jq .

可能的部署状态包括:

  • (不存在):尚未对 Worker 进行 Smart Placement 分析。Worker 将始终在最接近接收请求位置的默认 Cloudflare 位置运行。
  • SUCCESS:Worker 已成功分析,并将由 Smart Placement 进行优化。Worker 将在最小化预期请求持续时间的 Cloudflare 位置运行,这可能是最接近接收请求位置的默认位置,也可能是全球其他更快的位置。
  • INSUFFICIENT_INVOCATIONS:Worker 尚未收到足够的请求来做出部署决策。Smart Placement 需要来自全球多个位置的持续流量。Worker 将始终在最接近接收请求位置的默认 Cloudflare 位置运行。
  • UNSUPPORTED_APPLICATION:Smart Placement 开始优化 Worker 并测量结果,结果显示 Smart Placement 使 Worker 变慢。作为响应,Smart Placement 撤销了部署决策。Worker 将始终在最接近接收请求位置的默认 Cloudflare 位置运行,并且 Smart Placement 不会再次分析 Worker,直到重新部署。此状态很少见,占启用 Smart Placement 的 Worker 的不到 1%。

请求持续时间分析

启用 Smart Placement 后,会收集有关请求持续时间的数据。请求持续时间在最接近最终用户的数据中心进行测量。

默认情况下,百分之一(1%)的请求不使用 Smart Placement 路由。这些请求用作比较的基线。

cf-placement 请求头

启用 Smart Placement 后,Cloudflare 会向所有请求添加 cf-placement 请求头。这可用于检查请求是否已通过 Smart Placement 路由,以及 Worker 正在处理请求的位置(显示为最接近数据中心的机场代码)。

例如,cf-placement: remote-LHR 请求头的 remote 值表示请求已通过 Smart Placement 路由到伦敦附近的 Cloudflare 数据中心。cf-placement: local-EWR 请求头的 local 值表示请求未通过 Smart Placement 路由,Worker 在最接近接收请求位置的数据中心调用,靠近纽瓦克自由国际机场(EWR)。

最佳实践

如果你在 Workers 上构建全栈应用程序,我们建议将前端和后端逻辑拆分为不同的 Worker,并使用 Service Bindings 连接前端逻辑和后端逻辑 Worker。

Smart Placement 和 Service Bindings

在后端 Worker 上启用 Smart Placement 将使其在接近后端服务的位置调用,而前端 Worker 在接近用户的位置提供请求。这种架构保持了快速、响应式的前端,同时也改善了调用后端 Worker 时的延迟。

总结

Smart Placement 是 Cloudflare Workers 的一项强大功能,可以自动优化 Worker 的执行位置,从而降低延迟并提升应用性能。通过智能分析请求持续时间并选择最佳执行位置,Smart Placement 特别适合需要频繁访问后端服务(如数据库)的 Worker 应用。

核心要点

  • 自动优化:Smart Placement 自动分析并选择最佳执行位置
  • 降低延迟:将 Worker 部署在更接近后端服务的位置,减少往返时间
  • 易于启用:通过 Wrangler 配置文件或 Dashboard 即可启用
  • 可观测性:提供详细的部署状态和请求持续时间分析
  • 最佳实践:建议将前端和后端 Worker 分离,在后端 Worker 上启用 Smart Placement

适用场景

  • 需要频繁访问数据库的 Worker 应用
  • 需要调用后端 API 的 Worker 应用
  • 全栈应用的后端 Worker
  • 对延迟敏感的应用

注意事项

  • Smart Placement 只影响 fetch 事件处理器的执行
  • 需要来自全球多个位置的持续流量才能做出部署决策
  • 分析过程可能需要最多 15 分钟
  • 静态资源的提供位置不受 Smart Placement 影响

搜索