持久工作流选型：队列还是编排引擎

退款任务执行到一半，Pod 崴溃了；新用户开通流程还没走完，服务又发布了。任务能不能接着做、已经完成的步骤会不会重复执行，才是这篇 Temporal、BullMQ 与 AWS Step Functions 对比真正讨论的问题。

作者的结论是：Node 后台任务优先考虑 BullMQ，需要长期保存流程进度时考虑 Temporal，深度使用 AWS 的团队可以选择 Step Functions。这个划分有参考价值，但文中「90%」和「exactly-once」的说法，需要拆开看。

先分清你需要队列，还是需要保存整个流程

持久化工作流（durable workflow）解决的是：进程退出、机器故障或版本发布之后，业务流程仍然知道自己走到了哪里。

队列解决的问题更集中：把任务交给 Worker，控制什么时候执行、同时执行多少个，以及失败后是否重试。一个任务内部如果包含多个业务步骤，队列未必知道这些步骤各自完成了没有。

BullMQ 是基于 Redis 的 Node 任务队列，提供延迟任务、重复任务、优先级和并发限制。作者认为，大量 Node 应用需要的就是「执行任务，失败重试几次，必要时延迟」，因此采用成本很低。

但如果一个任务先创建资源，再更新数据库，最后发送邮件，第二步失败后从哪里继续，就需要额外设计。重跑整个任务，可能重复创建资源；直接跳过，又可能漏掉操作。

选型前最该确定的是：故障之后，由谁记住业务进度、决定下一步。

原文把 BullMQ 描述成适合「90% 的 Node 应用」，还说可以一个下午部署完成。这些都是作者的经验判断，没有样本、测量方法或对照数据，不能当成普遍结论。

Temporal 接管恢复，但代码要遵守回放规则

Temporal 的优势是把流程状态、重试和超时纳入引擎。作者列出的适用场景包括订阅开通、许可证发放、用户引导和分布式事务。这些业务的共同点是：流程可能跨越数小时，中间失败了也不能丢失上下文。

它依赖确定性回放（deterministic replay）：引擎记录执行历史，恢复时利用历史重建流程状态。因此，工作流代码必须满足回放要求，不能随意读取系统时钟等会让执行结果变化的信息。

作者用一个 Node SaaS 的用户开通流程举例：

1. 通过 SDK 完成注册。
2. 创建用户所需的资源。
3. 向候补名单发送邮件。
4. 失败后按上限重试，耗尽次数后告警或记录可查询的日志。

使用 BullMQ，需要在 Worker 中处理部分完成状态、补偿和恢复。使用 Temporal，可以把流程组织成一个异步工作流，将具体操作交给 Activity，并配置重试和超时。

这里要修正原文容易造成的印象：「从最后完成的事件恢复」不等于进程内存被保存，更不等于从某一行代码继续执行。关键是执行历史与回放机制。

原文进一步把 Temporal 和「exactly-once」联系起来，却没有交代外部副作用的边界。对于创建资源、发送邮件这样的操作，不能仅凭流程引擎支持恢复，就认定业务操作绝不会重复。原文没有给出足以支持这种保证的实现细节。

代价也很明确：团队需要自建 Temporal 服务，或者购买 Temporal Cloud，还要学习回放、超时和工作流编写规则。作者提醒，自建服务不可用时，依赖它的流程也会受阻。

Step Functions 省下运维，也带来平台约束

AWS Step Functions 用 JSON 定义状态机，把步骤连接到 Lambda、SQS、ECS、Glue 等 AWS 服务。已经围绕 AWS 建设系统的团队，可以让平台负责状态保存和重试，不必自行运行编排服务。

它与 Temporal 的差别不只是部署位置。Temporal 侧重用代码表达流程；Step Functions 主要通过状态定义和 Workflow Studio 组织服务调用。团队是否接受这种表达方式，会直接影响维护成本。

原文认为，Step Functions 的问题集中在 JSON 和映射约束、状态机层的延迟、AWS 绑定，以及频繁状态转换产生的费用。对于交互密集的审批流程，作者判断它可能既难写又昂贵，但没有提供具体工作流、账单或延迟测试。

成本也不能只看许可证：

• Temporal 开源核心为 $0，自建仍需承担服务器和运维成本；Temporal Cloud 按用量收费，原文提到提供免费试用。
• BullMQ 使用 MIT 许可证，但 Redis 的运行、持久化和故障恢复仍需有人负责。
• Step Functions 由 AWS 托管，原文概括为按状态转换和请求付费，没有展开不同执行模式的计费差异。

因此，这篇文章适合帮助初筛，不足以直接估算预算。标题虽然标着 2026，正文也没有给出具体版本、价格表或可复现的性能测试。

我的判断

我认同作者按「谁负责恢复」来划分三种工具。这比堆功能清单更接近业务问题：队列里的任务还在，并不代表一个多步骤流程的状态就一致。

不过，原文有两处表述需要收紧。

第一，它一边介绍 BullMQ 的重试能力，一边又说重试和退避要自己写。更准确的区分是：可以使用队列提供的重试机制，但业务上的幂等、补偿和部分完成状态，仍需要开发者设计。配置重试次数和保证业务正确，是两件不同的事。

第二，Temporal 接管了大量恢复逻辑，但原文没有证明它能替所有外部操作提供「恰好一次」保证。把这个词直接当成选型理由，会掩盖真正需要检查的故障窗口。

简单任务用队列往往划算；恢复逻辑已经散落在多个服务里时，才更值得评估专门的工作流引擎。

至于 Step Functions，是否合适取决于现有系统与 AWS 的结合程度。省下编排服务的运维后，还要接受状态定义、排障方式和计费模型。原文没有三者的对照实验，这些取舍应当视为架构经验，而非性能排名。

能拿来做什么

• 给 Node 后台任务列出实际步骤，标注每一步的外部副作用，再检查任意两步之间崩溃后会发生什么，用这张表判断队列是否够用。
• 已经使用 BullMQ 的项目，可以先检查资源创建、数据库更新和邮件发送是否支持安全重试，并明确把部分完成状态保存在哪里。
• 评估 Temporal 时，用一条真实的用户开通流程验证 Worker 中断后的恢复行为，同时审查工作流中读取时间等不符合回放要求的代码。
• 已经使用 AWS 的团队，可以把同一条流程拆成 Step Functions 状态转换，估算请求与转换数量，再结合 JSON 定义的维护成本做选择。