Temporal工作流引擎

Temporal 是一套用于编排有状态、可能长期运行的应用流程的工作流运行平台。它把流程代码的执行状态记录为事件历史，并由 Temporal Service 调度任务、由应用 Worker 执行代码；当进程或机器发生故障后，流程可以根据已记录的历史恢复并继续推进。Temporal 常用于订单履约、账户开通、支付协调、审批及其他跨服务的后台流程。它的核心关注点是分布式应用中的持久化执行与故障恢复，并不等同于专门为大语言模型代理图设计的框架。

在 Temporal 中，开发者使用受支持的 SDK，以通用编程语言定义 Workflow。Workflow 表达业务流程的控制逻辑，例如先校验订单、再预留库存、等待付款结果，最后发出发货指令。一个 Workflow Definition 是流程代码，一个 Workflow Type 是它在系统中的名称，而 Workflow Execution 是以特定输入运行的一次实例。Temporal 文档将平台描述为 Temporal Service 与应用 Worker 共同组成的运行时：Client 发起或查询执行，Service 保存状态并安排任务，Worker 实际运行用户的 Workflow 和 Activity 代码。Temporal 对平台的说明和架构工作原理分别介绍了这些组成部分。

“持久化执行”（durable execution）的重点，是把业务流程的推进过程从单一进程的内存状态中解耦。若 Worker 重启，工作不必简单地从头盲目再跑；Temporal 可用已记录的事件重建 Workflow 的逻辑状态，再执行尚未完成的步骤。这一模型适用于包含等待、重试、跨服务调用或需人工介入的流程，但需要应用开发者遵守确定性、部署兼容性和副作用处理等约束。

Workflow 是流程的协调层：它维护由输入、已记录事件和消息所决定的逻辑状态，并安排 Activity、计时器或子 Workflow。Workflow 代码必须满足确定性要求，即在相同输入和同一段历史下，重放时应按相同顺序发出相同的 Temporal 命令。像本地时钟、未记录的随机值、网络请求或数据库访问等非确定性操作，通常不应直接放在 Workflow 逻辑里，而应放到 Activity；SDK 提供的时间、计时器等接口则与重放机制配合。Workflow 定义文档说明了确定性约束以及代码变更可能导致的不匹配。

Activity 是执行具体动作的函数或方法，适合调用外部 API、读写数据库、发送通知、处理文件或进行计算。Activity 可以使用普通库并与外部系统交互；它的执行结果或失败信息由 Worker 回传给 Temporal Service，供 Workflow 决定下一步。Temporal 会按配置的 Retry Policy 对失败的 Activity 尝试重试；长时间运行的 Activity 可以用 Heartbeat 汇报进度，开发者也可保存检查点以便后续尝试续作。Activity 的粒度会影响故障恢复和超时边界：把不可分解的大任务写成一个长 Activity，通常不如拆成若干有明确输入、结果和超时的步骤容易管理。Activity 文档介绍了 Activity 的职责、重试和 Heartbeat。

Workflow 与 Activity 并不是“可重试逻辑”和“不可重试逻辑”的简单二分。Workflow Task 失败与 Workflow Execution 业务失败是不同情况：前者例如 Worker 故障或重放不确定性，Service 会重新安排 Workflow Task；后者则表示业务流程执行失败，是否开启整个 Workflow 的重试取决于相应策略。配置重试时，应区分暂时性故障与业务上的最终拒绝，避免无界或不合适的重试。失败处理文档概述了应用失败、超时及重试策略。

Temporal 的关键状态载体是 Workflow Execution 的 Event History：按顺序记录执行生命周期中发生的事件，包括启动、Activity 排程及完成、计时器、消息和结束状态等。Workflow 运行时，SDK 将诸如“安排 Activity”或“启动计时器”的意图作为命令发送给 Service；Service 根据命令更新执行状态、持久化事件并在需要时创建任务。Worker 后续接到 Workflow Task 时，SDK 依据事件历史重新运行 Workflow 代码以重建逻辑状态；历史中已有的 Activity 结果会被读取，而不是在重放过程中再次调用外部系统。事件历史说明和重放工作流程解释了事件、命令与恢复之间的关系。

这不是把一个运行中进程的内存快照原样迁移到另一台机器。重放依赖当前可用的 Workflow 实现与历史保持兼容；如果修改仍在运行的 Workflow，使其在相同历史下产生不同的命令序列，就可能出现非确定性错误。对于持续时间长、跨多个代码版本运行的执行，团队需要设计安全的代码演进策略。Temporal SDK 提供 Workflow 版本控制和补丁应用等机制，供开发者在引入有影响的流程变更时控制旧执行与新代码的兼容性；具体用法依语言 SDK 而异，应按对应版本的官方指南实施。版本与 patching 指南讨论了相关隐患。

Temporal Service 负责接受 SDK Client 的控制请求、保存 Workflow 状态和历史，并把待处理工作交给任务队列。官方架构资料将服务端主要职责分为 Frontend（API 入口）、History（执行状态与事件历史）和 Matching（任务队列及任务分发）等部分。应用 Worker 则运行在用户管理的进程或部署环境中，使用 Temporal SDK 轮询任务队列、执行已注册的 Workflow 或 Activity，并把命令、结果或失败报告回 Service。Temporal Server 不直接执行用户的应用代码。架构概览提供了 Client、Service、Worker 和数据库之间的交互说明。

Task Queue 是 Worker 获取特定任务的逻辑路由点；Workflow Task 让 Worker 推进 Workflow，Activity Task 则要求它执行一次 Activity 尝试。多个 Worker 可轮询同一队列以分担任务，Worker 进程不必向 Temporal Service 暴露供其回调的端口。队列中的 Workflow 与 Activity 任务在 Worker 暂时不可用时可留待之后处理，但队列本身不意味着应用容量无限：Worker 数量、任务处理时长、并发槽、数据库和服务端配置仍会影响延迟与积压。将某类 Activity 路由到单独的队列，可以让团队分别部署和配置相应 Worker，但必须确保监听同一队列的 Worker 能处理发送到该队列的任务。Task Queue 文档说明了轮询、路由和任务持久性。

Temporal 允许团队自行托管 Temporal Service，也可使用由 Temporal 运营的 Temporal Cloud；两种方式下，应用 Worker 都运行在应用侧。自托管部署意味着团队还需规划数据库、升级、认证、监控、保留策略和故障恢复等运维事项。云服务则由服务提供方运营 Temporal Service，应用团队仍需维护 Worker、Workflow 代码、容量与业务数据处理。选择运行方式时，应结合组织现有运维能力、数据治理要求和可接受的控制边界评估。Temporal 文档介绍了自托管服务与 Temporal Cloud 的基本关系。

Temporal 以配置的策略处理失败，不意味着所有错误都会无条件自动修复。Activity 的 Retry Policy 可以限制尝试次数、重试间隔及可重试错误类别；Timeout 用于界定排队、单次执行或整体 Activity 执行可等待的时长。长 Activity 的 Heartbeat 还可用于报告活性和携带恢复信息。具体超时选项和默认值因 Activity 类型与 SDK 而异，应根据操作性质、外部系统限制和流程总体时限设置，而不是套用一组通用数值。重试策略和失败检测文档列出 Temporal 的错误处理概念。

最重要的边界是：持久化工作流状态不等于外部副作用 exactly-once。设想 Worker 已调用支付服务并完成扣款，但在把成功结果报告给 Temporal Service 前发生故障；系统可能无法仅凭内部历史判断外部扣款是否已经成功，重试同一 Activity 时便存在重复执行外部动作的风险。因此官方建议 Activity 尽量幂等。实际系统可使用支付服务支持的幂等键、业务唯一请求号或下游去重机制，并妥善处理结果未知的情况；跨多个系统无法原子提交的业务流程，还可设计补偿操作。Temporal 负责协调与记录流程，外部系统的一致性语义仍需应用设计来保障。Activity 说明明确建议考虑幂等，以避免重试造成重复副作用。

外部客户端可在 Workflow 运行期间查询或改变其业务状态。Temporal 提供三种常见消息类型：Query 用于读取当前 Workflow 状态，不修改执行历史；Signal 是异步写入请求，发送方通常不等待 Workflow 处理结果；Update 是可等待处理结果或错误的写入请求，并可在被接受前进行验证。它们适合分别表达“查看状态”“通知流程发生了什么”和“提交一项需确认的更改”。例如，物流流程可通过 Signal 接收承运方状态变更、通过 Query 查看当前节点，或通过 Update 提交一个要求 Workflow 校验的改派请求。消息传递文档比较了 Query、Signal 和 Update。

从架构角色看，Task Queue 的工作是把 Temporal 已经安排的任务交给合适的 Worker；它与通用消息系统用于发布领域事件、供不同服务订阅的职责并不相同。应用可以把消息系统用于事件传递，再由消费者启动或通知 Workflow；Temporal 则记录每个 Workflow Execution 如何推进。两者是否组合以及如何保证消息与启动请求之间的业务一致性，仍需由应用架构决定。Temporal 的主要价值在于用代码表达跨时间、跨服务的协调逻辑，并借助事件历史、Worker 和重试策略应对进程故障与临时错误。它不负责替代数据库事务、消息总线、外部 API 的业务约束或人的运维决策；也不自动保证第三方系统的副作用只能发生一次。部署和维护时还需监控任务队列积压、Worker 可用性、Activity 耗时及失败类别，并在流程代码变更时验证重放兼容性。对于短且同步的单次请求、简单数据变换，或已有平台已充分满足状态流转与恢复需求的场景，引入一套持久化工作流服务可能增加不必要的架构和运维成本。