Temporal Serverless Workers on Cloud Run: Scale workers ahead of demand

在 Cloud Run 工作者池上运行 Temporal 无服务器工作者 | Google Cloud 博客

Serverless

在 Cloud Run 上运行 Temporal 无服务器工作者：提前按需扩展工作者

2026 年 10 月 16 日

##### Sagar Randive

产品经理

##### Aniruddh Chaturvedi

工程经理

##### 立即体验 Gemini

职场 AI 的入口

立即体验

开源的 Temporal 执行平台正在迅速成为现代软件基础设施的基础层——尤其是在分布式系统编排和 AI 代理工作负载方面。然而，在 Temporal 中部署和扩展工作者会带来独特的挑战。工作者通过轮询获取任务而非响应请求，因此请求驱动的无服务器平台往往难以适配。这通常导致需要在 Kubernetes 或虚拟机上运行工作者舰队，而你必须持续管理和付费。你构建指标流水线并调整自动扩展触发器，但因指标延迟，扩展仍会滞后于突发流量。每次部署都需要在升级和版本之间反复权衡，无论队列中是否有任务，你都需要为这些计算资源付费。

我们专门为这种基于拉取的工作者场景构建了 Cloud Run 工作者池：你的实例连接到队列或流，获取下一个项目并进行处理。从今天起，Temporal Cloud（Temporal 开源平台的全托管版本）可以为你进行扩展。目前处于预览阶段，Cloud Run 上的 Temporal 无服务器工作者让你可以将工作者部署为工作者池，Temporal 会根据任务队列上的工作量调整池的规模。当没有任务时，它甚至可以将池扩展到零。你无需运行任何集群或自动扩展器，你的工作者代码保持不变。

Cloud Run 工作者池如何与 Temporal 配合

工作者池是 Cloud Run 用于持续后台工作的资源。它没有公共端点，每个实例在其整个生命周期内都会分配到 CPU，这与 Temporal 工作者的运行方式完全匹配。Temporal 以以下方式管理你的 Cloud Run 工作者池：

• 你的 Temporal 工作者作为 Cloud Run 工作者池实例在你的项目中运行，并轮询 Temporal Cloud 获取任务。

• Temporal Cloud 跟踪你的任务队列，并通过 Cloud Run 管理员 API 使用你授予的 IAM 权限设置工作者池的实例数量。Temporal 从不主动连接到你的实例，因此你无需为其打开端口或添加防火墙规则。

• 你将每个构建版本作为独立的 Cloud Run 工作者池运行。旧版本的构建工作者池可以保持在零实例状态，直到某个工作流再次需要它时才重新启动。

你的 Temporal 工作者在你的项目、你的服务账户和你的网络上运行。Temporal 决定它们的运行数量。

你可以使用 Temporal 无服务器工作者构建的内容

Cloud Run 工作者池与 Temporal 无服务器工作者的结合开启了多种有趣的使用场景：

自动扩展的代理工作者：AI 代理运行多步骤的 LLM 推理和工具调用链。Temporal 的持久化执行与 Cloud Run 工作者池在此协同工作。Temporal 工作者可以即时启动以处理 LLM 步骤、嵌入或 API 调用的突发流量，当队列为空时自动扩展到零。工作者可以通过无密钥方式访问 Google Cloud AI API。你还可以附加 GPU 进行推理，附加到 GPU 的工作者仍然可以扩展到零。Temporal 将每个模型和工具调用作为持久化活动运行；如果工作者在步骤中途消失，该活动会在另一个工作者上重试，工作流将继续执行。

长期运行的工作流：Temporal 工作流可以无限期运行，使开发者能够构建跟踪现实世界资源状态的长期应用。这种模式通常被称为“实体模式”，因为工作流代表了某个实体的状态。然而，这些长期运行的工作流通常不会持续占用计算资源：某些步骤耗时很短，某些步骤耗时较长，有时工作流会处于休眠状态，等待外部输入（例如来自人工或其它系统的输入）。Cloud Run 工作池提供了灵活的计算能力来支持这种模式：单个步骤可以运行任意长时间，当没有任务需要处理时，Temporal 会自动缩减工作池规模。

突发性批量任务：工作池仅在实例运行时计费，因此在批量任务之间处于空闲状态的工作池在零实例时不会产生任何费用。对于账单计算或媒体转码等任务，Temporal 会在批量任务到达时扩展工作池规模，在任务队列清空后自动缩减规模。您设置的最大实例数量决定了需要付费的实例上限。超出该容量的任务会进入队列等待，而不是被丢弃。

为什么选择 Cloud Run 工作池作为 Temporal 工作者

此前在 Cloud Run 服务上运行 Temporal 工作者需要一些变通方法：

• 需要 HTTP 监听器，因为服务期望容器监听某个端口
• 基于实例计费，导致工作者在请求之间保持 CPU 占用
• 设置最小实例数量，防止服务缩至零实例

通过在 Cloud Run 工作池上运行 Temporal 工作者，您不再需要这些变通方法，同时获得以下优势：

• 无需管理端点。没有需要锁定的公共 URL 或负载均衡器，也不需要实现健康检查端口。
• 更低成本下的稳定 CPU。实例不会空转或限流。Cloud Run 不会因为实例看似空闲而移除它们，因此 Temporal 独立决定何时缩减工作池规模。工作池的计费价格几乎比基于实例计费的 Cloud Run 服务低 40%（每 vCPU 小时和每 GB 小时）。
• 无版本变更的扩展。修改实例数量不会创建新版本，因此 Temporal 可以根据负载变化频繁调整工作池规模。

Temporal 如何管理工作池的扩展和版本

Temporal 通过一个主要信号决定何时增加容量：任务进入任务队列积压与工作者开始处理之间的延迟。如果该延迟增加，说明可用工作者已饱和。扩展过程如下：

• 服务器端检测：Temporal 服务器跟踪每个任务队列的积压到工作者的延迟。
• 推送通知：当延迟超过触发条件时，服务器向工作者控制器实例发送推送通知。
• 资源分配：工作者控制器随后向工作池添加容量。新实例需要时间启动并连接后才能轮询任务，因此容量增长会滞后于信号。

由于 Temporal 保留了备用容量，因此工作池会在需求增长之前提前扩展，而不是等到任务堆积之后。缩容操作更加保守。Temporal 会在最后一次任务找不到可用工作者后等待一段稳定期（默认 90 秒），并在连续缩容之间暂停。Cloud Run 的可配置优雅关闭机制将关闭时间从 10 秒延长至 10 分钟。这为能够处理 SIGTERM 信号的工作者提供了完成任务或进行检查点的时间。实例数量会保持在您设置的最小值和最大值之间。如果空闲期后第一个任务无法等待实例启动，请将最小值设为大于零。

在不中断正在运行的执行的情况下部署新的工作流代码是一项挑战。Temporal 工作流是状态化且确定性的，因此如果在运行过程中替换其代码，会导致非确定性错误。Cloud Run 上的无服务器工作者通过要求 Temporal 工作者版本化解决了这个问题。您不会使用条件分支来修补代码，而是将每个工作者部署版本作为独立的工作者池部署，通过 deploymentName 和 buildId 进行标识。使用独立的工作者池解决了两个问题：

• 在特定工作者部署版本上启动的工作流将继续在该版本上运行并完成。
• 每个工作者部署版本可以独立进行扩展和下线，使计算支出和利用率与应用程序需求相匹配。随着现有工作流在之前的工作者部署版本上完成并下线，底层工作者池最终会自动缩容至零。

您可以为每种工作流类型设置版本化行为，或设置工作者级别的默认值：

• PINNED：工作流会停留在其启动的工作者版本（构建 ID）上，并在该版本上完成。最适合短时运行的工作流、订单处理和多步骤 API。
• AUTO_UPGRADE：在您进行滚动更新时，工作流会迁移到新的“当前”或“目标”工作者部署版本。最适合长期运行的工作流，如订阅计费或持续数周的任务。

了解如何配置工作者版本化，请参阅此处。

入门指南

设置分为三个步骤：

• 将您的 Temporal 工作者容器化，并作为 Cloud Run 工作者池部署，池名称中包含 Build ID。将 Temporal API 密钥等凭证保存在 Secret Manager 中。
• 通过授予 Temporal Cloud 管理工作者池的权限，将 Temporal 连接到您的工作者池，以便其进行扩展。
• 在 Temporal 中创建指向池项目、区域和名称的工作者部署版本。

Cloud Run 上的 Temporal 无服务器工作者目前处于预览阶段，因此在稳定版本发布前，API 和配置可能会发生变化。要开始使用：

• 了解 Cloud Run 上的无服务器工作者如何扩展和处理版本。
• 使用入门指南部署您的第一个工作者。
• 查看 Cloud Run 工作者池的 CPU、内存、GPU 和网络选项。
• 注册可配置优雅关闭预览功能。

发布在以下类别：

• 无服务器
• 应用程序开发
• Cloud Run
• AI 基础设施