logo
简体中文

导航菜单

Cloudflare 入门

Service Bindings（服务绑定）

关于 Service Bindings

Service Bindings（服务绑定）允许一个 Worker 调用另一个 Worker，而无需通过公开可访问的 URL。Service Binding 允许 Worker A 调用 Worker B 的方法，或者将请求从 Worker A 转发到 Worker B。

Service Bindings 提供了微服务或面向服务架构的关注点分离，而无需配置麻烦、性能开销或学习 RPC 协议。

  • Service Bindings 速度很快。 使用 Service Bindings 时，没有开销或增加的延迟。默认情况下，两个 Worker 运行在同一 Cloudflare 服务器的同一线程上。当你启用 Smart Placement 时，每个 Worker 都会在最佳位置运行以获得整体性能。
  • Service Bindings 不仅仅是 HTTP。 Worker A 可以暴露方法，这些方法可以被 Worker B 直接调用。服务之间的通信只需要编写 JavaScript 方法和类。
  • Service Bindings 不会增加成本。 你可以将功能拆分为多个 Worker，而不会产生额外成本。了解更多关于 Service Bindings 的定价。

Service Bindings 是零成本抽象

Service Bindings 通常用于：

  • 为多个 Worker 提供共享的内部服务。 例如，你可以将身份验证服务部署为独立的 Worker，然后让任意数量的独立 Worker 通过 Service Bindings 与其通信。
  • 将服务与公共互联网隔离。 你可以部署一个无法通过公共互联网访问的 Worker，只能通过另一个 Worker 声明的显式 Service Binding 访问。
  • 允许团队独立部署代码。 团队 A 可以按照自己的发布计划部署他们的 Worker，团队 B 可以单独部署他们的 Worker。

配置

通过修改调用者（你希望能够发起请求的 Worker）的 Wrangler 配置文件 来添加 Service Binding。

例如，如果你希望 Worker A 能够调用 Worker B，你需要在 Worker A 的 Wrangler 配置文件 中添加以下内容：

wrangler.jsonc

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "services": [
    {
      "binding": "<BINDING_NAME>",
      "service": "<WORKER_NAME>"
    }
  ]
}

wrangler.toml

services = [
  { binding = "<BINDING_NAME>", service = "<WORKER_NAME>" }
]
  • binding：你想要在 env 对象上暴露的键名。
  • service：你想要与之通信的目标 Worker 的名称。该 Worker 必须在你的 Cloudflare 账户中。

接口

声明了到 Worker B 的 Service Binding 的 Worker A 可以通过两种不同的方式调用 Worker B：

  1. RPC 允许你使用你定义的函数调用在 Worker 之间进行通信。例如，await env.BINDING_NAME.myMethod(arg1)。这适用于大多数用例，允许你创建自己的内部 API，供其他 Worker 使用。
  2. HTTP 允许你通过调用其他 Worker 的 fetch() 处理器 在 Worker 之间进行通信，发送 Request 对象并接收 Response 对象。例如，env.BINDING_NAME.fetch(request)。

示例 — 使用 RPC 构建你的第一个 Service Binding

此示例扩展 WorkerEntrypoint 类 以支持基于 RPC 的 Service Bindings。首先，创建你想要与之通信的 Worker。我们称之为 “Worker B”。Worker B 暴露公共方法 add(a, b)：

wrangler.jsonc

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "worker_b",
  "main": "./src/workerB.js"
}

wrangler.toml

name = "worker_b"
main = "./src/workerB.js"

import { WorkerEntrypoint } from "cloudflare:workers";


export default class WorkerB extends WorkerEntrypoint {
  // 目前不支持没有命名处理器的入口点
  async fetch() { return new Response(null, {status: 404}); }


  async add(a, b) { return a + b; }
}

接下来，创建将调用 Worker B 的 Worker。我们称之为 “Worker A”。Worker A 声明了对 Worker B 的绑定。这使其有权调用 Worker B 上的公共方法。

wrangler.jsonc

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "worker_a",
  "main": "./src/workerA.js",
  "services": [
    {
      "binding": "WORKER_B",
      "service": "worker_b"
    }
  ]
}

wrangler.toml

name = "worker_a"
main = "./src/workerA.js"
services = [
  { binding = "WORKER_B", service = "worker_b" }
]

export default {
  async fetch(request, env) {
    const result = await env.WORKER_B.add(1, 2);
    return new Response(result);
  }
}

要在本地开发中运行 Worker A 和 Worker B，你必须在终端中运行两个 Wrangler 实例。对于每个 Worker，打开一个新终端并运行 npx wrangler@latest dev。

每个 Worker 都是单独部署的。

生命周期

Service Bindings API 是异步的 — 你必须 await 你调用的任何方法。如果 Worker A 通过 Service Binding 调用 Worker B，而 Worker A 没有等待 Worker B 完成，Worker B 将被提前终止。

有关通过 RPC 通过 Service Binding 调用 Worker 的生命周期的更多信息，请参阅 RPC 生命周期 文档。

本地开发

Service Bindings 支持本地开发。对于每个 Worker，打开一个新终端并在相关目录中使用 wrangler dev。运行 wrangler dev 时，服务绑定将显示为 connected/not connected，具体取决于 Wrangler 是否可以找到该 Worker 正在运行的 wrangler dev 会话。例如：

$ wrangler dev
...
Your worker has access to the following bindings:
- Services:
  - SOME_OTHER_WORKER: some-other-worker [connected]
  - ANOTHER_WORKER: another-worker [not connected]

Wrangler 还支持用一个命令同时运行多个 Worker。要尝试此功能，请向 Wrangler 传递多个 -c 标志，如下所示：wrangler dev -c wrangler.json -c ../other-worker/wrangler.json。第一个配置将被视为主 Worker，它将像往常一样通过 HTTP 在 http://localhost:8787 上公开。其余配置文件将被视为辅助，只能通过主 Worker 的服务绑定访问。

部署

使用 Service Bindings 的 Worker 是单独部署的。

在开始和首次部署时，这意味着目标 Worker（上面示例中的 Worker B）必须在 Worker A 之前部署。否则，当你尝试部署 Worker A 时，部署将失败，因为 Worker A 声明了对 Worker B 的绑定，而 Worker B 尚不存在。

在对现有 Worker 进行更改时，在大多数情况下，你应该：

  • 首先部署对 Worker B 的更改，以与现有 Worker A 兼容的方式。例如，向 Worker B 添加新方法。
  • 接下来，部署对 Worker A 的更改。例如，从 Worker A 调用 Worker B 上的新方法。
  • 最后，删除任何未使用的代码。例如，删除 Worker B 上以前使用的方法。

Smart Placement

Smart Placement 自动将你的 Worker 放置在最小化延迟的最佳位置。

你可以将 Smart Placement 与 Service Bindings 一起使用，将你的 Worker 拆分为两个服务：

Smart Placement 和 Service Bindings

有关更多信息，请参阅 Smart Placement 文档。

限制

Service Bindings 有以下限制：

  • 通过 Service Binding 对 Worker 的每个请求都计入你的子请求限制。
  • 单个请求最多有 32 个 Worker 调用，每次调用 Service Binding 都会计入此限制。后续调用将抛出异常。
  • 调用服务绑定不计入同时打开的连接限制。

总结

Service Bindings 是 Cloudflare Workers 的强大功能，允许你在 Worker 之间进行高效通信，而无需通过公共 URL。通过 Service Bindings，你可以构建微服务架构，实现关注点分离，同时保持高性能和零额外成本。

核心要点

  • 零成本抽象：Service Bindings 不会增加延迟或成本
  • 两种通信方式：支持 RPC 和 HTTP 两种接口
  • 关注点分离：可以将功能拆分为多个独立的 Worker
  • 独立部署：不同团队可以独立部署和维护各自的 Worker
  • 本地开发支持：完全支持本地开发和调试

适用场景

  • 构建微服务架构
  • 提供共享的内部服务（如身份验证服务）
  • 隔离服务与公共互联网
  • 实现团队间的独立部署
  • 与 Smart Placement 结合优化性能

最佳实践

  • 使用 RPC 接口进行类型安全的函数调用
  • 将前端和后端逻辑拆分为不同的 Worker
  • 在后端 Worker 上启用 Smart Placement
  • 按照正确的顺序部署 Worker（目标 Worker 先部署）
  • 使用 await 确保异步操作完成

注意事项

  • Service Bindings 是异步的，必须使用 await
  • 每个请求最多 32 个 Worker 调用
  • 本地开发需要为每个 Worker 运行独立的 wrangler dev 实例
  • 部署时目标 Worker 必须先存在
上一章节Smart Placement了解 Cloudflare Workers 的 Smart Placement 功能，自动优化 Worker 的执行位置以降低延迟

搜索