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 通常用于：
- 向多个 Worker 提供共享的内部服务。 例如，您可以将身份验证服务部署为独立的 Worker，然后让任意数量的独立 Worker 通过 Service bindings 与其通信。
- 将服务与公共 Internet 隔离。 您可以部署一个无法通过公共 Internet 访问的 Worker，只能通过另一个 Worker 声明的显式 Service binding 访问。
- 允许团队独立部署代码。 团队 A 可以按自己的发布计划部署 Worker，团队 B 可以单独部署 Worker。
通过修改调用方（您希望能够发起请求的 Worker）的 Wrangler 配置文件 来添加 Service binding。
例如，如果您希望 Worker A 能够调用 Worker B——您需要在 Worker A 的 Wrangler 配置文件 中添加以下内容：
{
"services": [
{
"binding": "<BINDING_NAME>",
"service": "<WORKER_NAME>"
}
]
}[[services]]
binding = "<BINDING_NAME>"
service = "<WORKER_NAME>"binding：您希望在env对象上暴露的键名。service：您希望与之通信的目标 Worker 的名称。此 Worker 必须在您的 Cloudflare 账户上。
声明到 Worker B 的 Service binding 的 Worker A 可以通过两种方式调用 Worker B：
- RPC 允许您使用自己定义的函数调用在 Worker 之间通信。例如
await env.BINDING_NAME.myMethod(arg1)。这适用于大多数用例，允许您创建 Worker 向其他 Worker 提供的内部 API。 - HTTP 允许您通过从其他 Worker 调用
fetch()处理程序 在 Worker 之间通信，发送Request对象并接收Response对象。例如env.BINDING_NAME.fetch(request)。
此示例扩展 WorkerEntrypoint 类 以支持基于 RPC 的 Service bindings。
首先，创建您希望与之通信的 Worker。我们称之为 "Worker B"。Worker B 暴露公共方法 add(a, b)：
{
"$schema": "./node_modules/wrangler/config-schema.json",
"name": "worker_b",
"main": "./src/workerB.js"
}"$schema" = "./node_modules/wrangler/config-schema.json"
name = "worker_b"
main = "./src/workerB.js"import { WorkerEntrypoint } from "cloudflare:workers";
export default class WorkerB extends WorkerEntrypoint {
// Currently, entrypoints without a named handler are not supported
async fetch() {
return new Response(null, { status: 404 });
}
async add(a, b) {
return a + b;
}
}接下来，创建将调用 Worker B 的 Worker。我们称之为 "Worker A"。Worker A 声明到 Worker B 的 binding。这使其有权调用 Worker B 上的公共方法。
{
"$schema": "./node_modules/wrangler/config-schema.json",
"name": "worker_a",
"main": "./src/workerA.js",
"services": [
{
"binding": "WORKER_B",
"service": "worker_b"
}
]
}"$schema" = "./node_modules/wrangler/config-schema.json"
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 不 await Worker B 的完成，Worker B 将提前终止。
有关通过 RPC 通过 Service Binding 调用 Worker 的生命周期的更多信息，请参阅 RPC Lifecycle 文档。
Service bindings 支持本地开发。对于每个 Worker，打开新终端并在相应目录中使用 wrangler dev。运行 wrangler dev 时，service bindings 将显示为 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。第一个配置将被视为 primary worker，像往常一样在 http://localhost:8787 上通过 HTTP 暴露。其余配置文件将被视为 secondary，只能通过 primary worker 的 service binding 访问。
使用 Service bindings 的 Worker 单独部署。
首次开始和部署时，这意味着目标 Worker（上述示例中的 Worker B）必须先部署，然后才能部署 Worker A。否则，当您尝试部署 Worker A 时，部署将失败，因为 Worker A 声明了到尚不存在的 Worker B 的 binding。
对现有 Worker 进行更改时，在大多数情况下您应该：
- 首先以与现有 Worker A 兼容的方式部署 Worker B 的更改。例如，向 Worker B 添加新方法。
- 接下来，部署 Worker A 的更改。例如，从 Worker A 调用 Worker B 上的新方法。
- 最后，删除任何未使用的代码。例如，删除 Worker B 上先前使用的方法。
Smart Placement 自动将 Worker 放置在最小化延迟的最佳位置。
您可以将 Smart Placement 与 Service bindings 结合使用，将 Worker 拆分为两个服务：
有关更多信息，请参阅 Smart Placement 文档。
Service bindings 具有以下限制：