Vercel Daemons 新增服务绑定：私有服务直连

Vercel 为 Daemons 引入了服务绑定（service bindings）能力，让常驻后台的守护进程可以直接调用同一部署内的其他服务。这个改动看似只是配置项的增加，实质上补上了 Daemons 在部署内部通信上的关键一环。

服务绑定解决了什么问题

在 Vercel 的部署模型里，Services 承载具体的应用逻辑，Daemons 则是长期运行的进程，比如 worker、队列消费者或后台任务处理器。此前这两类组件之间的通信需要依赖外部暴露的 HTTP 地址，这意味着要么把服务公开出去，要么自行搭建内部访问通道。

服务绑定改变了这一点。据 Vercel 官方说明，Daemon 可以通过声明绑定来获取目标服务的 URL，Vercel 负责处理内部路由、身份认证和 TLS，服务本身保持私有状态，不需要对外暴露。

Daemons 与 Services 的定位差异

理解服务绑定的价值，需要先厘清 Vercel 部署模型中的两个核心构件。Services 是请求驱动的应用单元，通常以 HTTP 服务的形式响应用户或上游调用；而 Daemons 是常驻进程，生命周期与部署绑定，适合承载 worker、队列消费者、定时任务等后台逻辑。二者的运行形态决定了它们的通信需求不同：Services 之间可以通过平台提供的路由被发现，而 Daemons 长期处于“发起方”角色，此前缺少一条受平台托管的内部链路。服务绑定正是为这一角色补上的通道。

内部路由与 TLS 由平台托管意味着什么

在传统自建架构里，内部服务调用通常需要自行维护服务发现、mTLS 证书轮换和访问控制列表。Vercel 在服务绑定中把这些职责收归平台：绑定声明之后，平台负责把目标服务的 URL 解析到正确的内部端点，并在传输层完成 TLS 与身份校验。对开发者而言，这意味着不必在业务代码里嵌入证书、签名逻辑或内部 DNS 配置，服务也无需暴露公网入口。代价是这条链路的行为由平台定义，排查问题时要依赖平台提供的可观测性手段。

配置方式：声明式绑定

绑定的声明写在 vercel.toml 中。开发者需要指定三项内容：目标服务的名称、接收服务 URL 的环境变量名，以及绑定格式。

[[daemons.worker.bindings]]
type = "service"
service = "api"
format = "url"
env = "API_URL"

这段配置的含义是：worker 这个 Daemon 绑定 api 服务，服务的 URL 会被注入到环境变量 API_URL 中。format = "url" 表明注入的是可直接使用的 URL 字符串。

vercel.toml 与部署描述文件

vercel.toml 是 Vercel 项目中用于声明部署行为的配置文件，与 vercel.json 同属项目级配置，但采用 TOML 语法，更适合表达嵌套结构和数组表。文中 [[daemons.worker.bindings]] 的双括号写法即 TOML 的数组表语法，表示向 bindings 数组追加一个元素，因此同一个 Daemon 可以声明多条绑定。type、service、format、env 四个字段共同描述了一条绑定的完整语义：绑定类型、目标服务、注入格式和接收变量。理解这一点有助于在需要绑定多个服务时正确组织配置，而不是误以为只能声明一条。

调用方式与普通 HTTP 无异

拿到 URL 之后，Daemon 里的代码用标准 fetch 就能发起请求：

await fetch(new URL('jobs/next', process.env.API_URL));

对开发者来说，心智负担很低：不需要引入专有的 SDK，不需要处理签名或证书，内部路由和认证由平台兜底。这种设计把复杂性留在平台侧，把简单的 HTTP 接口留给业务代码。

单向绑定与实例稳定性

有两个边界条件值得注意。

绑定是单向的：Services 可以绑定到 Daemons 之外的服务，但反过来，Services 不能绑定到 Daemons。这与 Daemons 的定位一致——它们是后台消费方，而非被调用的服务端。如果你的架构需要双向通信，Daemon 侧仍需借助其他机制。

另一个细节是实例的持续性。每个 Daemon 实例始终调用启动它的那次部署，即使之后发生了 promotion 或 rollback 也不改变。这对长时间运行的后台任务很关键：一次部署变更不会让正在处理中的 worker 突然指向新版本的服务，避免了版本错配带来的隐患。反过来说，这也意味着滚动更新期间新旧实例会各自访问各自的部署，需要开发者在设计上考虑这种短暂的不一致。

promotion 与 rollback 的含义

在 Vercel 的部署体系中，每次推送都会生成一个独立的、不可变的部署，并带有自己的 URL。promotion 指把某个既有部署提升为生产别名所指向的版本，rollback 则是把生产别名切回此前的部署。两者都是别名层面的切换，并不重新构建或重启已有实例。正因如此，已经在运行的 Daemon 实例仍持有其启动时那次部署的上下文，它注入的环境变量和绑定的服务 URL 都指向原部署。这一机制保证了长任务不会在版本切换时被静默改道，但也要求开发者在滚动更新窗口内接受新旧实例并存、各自访问各自部署的短暂状态。

对架构设计的实际影响

服务绑定让 Vercel 上的后台任务架构更接近传统的内网服务调用模型：私有、免认证配置、走内部链路。对于把 worker 和 API 拆分部署的团队，这项能力减少了对外网入口的依赖，也让权限边界更清晰。

不过它并非万能。单向绑定加上实例锁定部署的特性，决定了它更适合“worker 消费内部 API”这类单向数据流场景，而不是需要灵活服务发现或双向调用的复杂拓扑。把这两点纳入考虑，才能用好这项新能力。