\n\nTemporal 凭借其开源的“持久化执行”框架，已吸引超 3000 家付费客户。该引擎通过自动持久化状态使代码具备容错性，确保复杂 AI 及分布式工作流在故障后精准恢复。
译自：Temporal hits 3,000 paying customers with its crash-proof workflow engine
作者：Chris J. Preimesberger
如果你在马戏团表演高空走钢丝，为了能在这个行业干下去，你最好在下面准备一张安全网。同样地，如果你有一套为客户昼夜不停运转的 IT 系统，无论涉及一个客户还是 500 万客户，在发生失误或安全漏洞时，你都应该拥有全方位的保护。
总部位于西雅图的 Temporal 最近因其软件在保护 IT 系统（无论是小型系统还是扩容系统）方面的表现而备受关注，尤其是在处理大规模 AI 相关负载时。
Temporal 上周在旧金山举办了 Replay 2026 开发者大会，并展示了其版本的 持久化执行 (Durable Execution)。这是一种基于开源的软件开发框架，通过自动持久化其状态，使代码具备容错能力。这使得长周期运行的流程在发生崩溃、网络故障或重启后，能够准确地从中断处恢复。它通过记录步骤将脆弱的代码转化为防崩溃的工作流，在无需手动编写错误处理逻辑的情况下确保可靠性。
Temporal 由 Samar Abbas 和 Maxim Fateev 于 2019 年创立，基于他们开发的开源 Cadence 工作流编排引擎。目前该公司发展迅速，拥有超过 3,000 家付费客户（包括 Nvidia、Netflix、Snap 和 Stripe）以及数万名开源用户。
Cadence 是由 Uber（具体由 Abbas 和 Fateev 开发）于 2017 年开发的一款开源、容错且高度可扩展的工作流编排引擎，用于管理复杂的、长周期运行的分布式流程。它使开发者能够使用代码而非 DSL（领域特定语言）来定义工作流，使其在服务失效期间仍能保持持久化和状态化。
DSL 在保证企业软件状态方面存在不足，因为它们是为有限的高层抽象而设计的。
Cadence 引擎的直接分支
Abbas 和 Fateev 将这一理念提升到了新高度，创建了 Temporal 作为 Cadence 引擎的直接分支。虽然它们拥有共同的渊源，但 Temporal 在目前的软件中并不使用 Cadence。首席技术官兼联合创始人 Fateev 在大会上告诉参会者，Temporal 是 Cadence 的演进版本，为了专注于改进开发者体验、SDK 设计和数据处理，两者已经发生了显著分歧。
“在一个 API 调用会失败、服务器会崩溃、数据会变得不一致的世界里，Temporal 确保业务流程……在没有人工干预的情况下运行至完成。”
“Temporal 的核心是一个持久化的开源执行框架，它允许开发者编写天生具有弹性的代码，” Fateev 在发言中表示，“在一个 API 调用会失败、服务器会崩溃、数据会变得不一致的世界里，Temporal 确保业务流程——从简单的交易到复杂的 AI 智能体生命周期——在没有人工干预的情况下运行至完成。”
“它有效地在你的应用逻辑之下创建了一个基础层，管理构建大规模分布式系统的繁重工作，这样你的团队就不必亲自操心了。”
云和无服务器选项
除了其前线基于服务器的产品外，Temporal 还提供了一种基于消费模式的 后端集群 SaaS 托管服务。公司保证开源模型与云版本之间的完全兼容。这反映了公司的信念：每位工程师都应该能够获得构建成功、可靠代码所需的工具。
Temporal 的无服务器 Worker (Serverless Workers) 使用户能够在 AWS Lambda 等无服务器计算平台上运行标准的 Temporal Worker。Fateev 表示，无需配置服务器，无需扩展集群，也不必为闲置计算付费。当任务到达时，Temporal 会调用 Worker，任务完成后 Worker 就会关闭。
“Temporal 做出了一系列战略决策，以支持我们的用户有效管理和扩展他们的智能体工作流的能力，” Temporal 工程高级副总裁 Preeti Somal 表示，“Temporal 已经是 AI 工作流的基础，但我们深知投资于此以打造更好产品并支持客户的重要性。我们希望展示我们的功能发布和合作伙伴关系并非随机而为，它们将改变开发者体验持久化执行的方式。”
关键用例示例
在大会上，Temporal 首席开发者布道师 Tom Wheeler 提供了一个基于真实用户的虚构案例，以解释其工作原理：
- Meridian Global 是一家大型零售商，在收购 Grafton Direct 后立即面临运营噩梦。Grafton 的订单管理系统 (OMS) 存在根本性缺陷，所有订单的失败率高达 7%，存在重复扣款、快递无休止延迟以及社交媒体上铺天盖地的投诉。由于 Grafton 疲惫不堪的工程团队在交易完成前集体辞职，留下了一团没有文档记录且复杂的架构债，危机进一步加剧。
- Doug 和 Naomi 开始了为期两天的深度调研。Doug 调查了系统的内部运作，发现应用程序检查点、状态恢复和重试的逻辑“交织在整个代码库中”，导致业务逻辑难以理解。他发现了关键漏洞，例如如果在系统崩溃时未释放订单流程早期预留的库存，以及会导致触发限流或隐式忽略异常的错误重试逻辑。
Naomi 则从外部切入，通过下测试订单来梳理准确的业务需求。她记录了复杂的七步订单流：
- 校验： 验证完整性并使用 AI 检查可疑活动。
- 预留库存： 预留商品以免卖给他人。
- 向客户收费： 这是一个复杂的步骤，涉及信用卡欺诈检查（导致立即取消）或非欺诈性拒付（给予客户 24 小时提供新支付方式的时间）。
- 请求履约： 一个异步步骤，通知仓库打包并选择物流。
- 发货确认： 通知司机取货。
- 送达确认： 司机标记包裹已送达。
- 订单完成： 订单在送达后保持开启 30 天以便退货，然后标记为关闭。
他们得出的结论是，系统的复杂性在于问题本身，因为它依赖于自研的重试逻辑、多个消息队列、数据库轮询以及不可靠的每日 Cron 任务。正如 Doug 所指出的，崩溃经常导致数据库和队列不同步，导致数据丢失或重复重试，从而导致客户被多次扣款。
Temporal 的实施
Naomi 遇到了 Temporal 的解决方案架构师 Elena。Elena 向他们介绍了 Temporal，这是一个旨在处理他们所面临问题的持久化执行平台。
解决 Meridian 问题的关键概念和原语包括：
- 工作流 (Workflows)： 提供防崩溃的持久化执行，消除了对手动检查点和状态持久化逻辑的需求。
- 活动 (Activities)： 用于调用外部系统（如数据库或微服务），并包含内置的容错重试和超时支持。
- 持久化定时器 (Durable Timers)： 允许执行暂停任意时长（秒、天或年），解决了 24 小时支付窗口和 30 天退货关闭问题，并取代了现有且不可靠的 Cron 任务。
- 查询 (Queries)： 允许外部系统检索运行中工作流的当前状态。
- 信号 (Signals)： 允许外部系统（如理货员的应用或送货司机的应用）在人工干预场景下更改工作流状态。
Doug 和 Naomi 迅速构建了一个概念验证 (PoC)。他们的测试证实了持久化执行的有效性：在执行中途杀掉智能体 Worker 不会导致数据丢失或重复工作（如重复扣款）。当他们模拟支付服务停机时，工作流会自动暂停，持续重试直到服务恢复，然后从准确的故障点继续运行。
“在短短几天内，该系统处理的订单量达到了 Grafton 此前峰值的五倍，且未丢失任何一个订单。”
PoC 的效果令他们印象深刻，随后他们在 Kubernetes 集群中部署了数十个 Worker。在短短几天内，系统处理的订单量达到了 Grafton 此前峰值的五倍，且没有丢失任何一个订单。Doug 对代码的简洁性尤为惊叹，他指出工作流代码“读起来就像一份规格说明书”。
他们向 Alex 提交了建议：用基于 Temporal 构建的新系统替换旧系统。为了赶上紧迫的截止日期，他们选择了使用托管服务 Temporal Cloud 以实现快速扩展。
新的 OMS 逐步推广，到下周四已承载 100% 的订单，实现了“零订单丢失 [且] 零客户投诉”。当黑色星期五到来时，系统平稳地处理了接近 Grafton 以前峰值五倍的业务量。
项目结束时，Jane 宣布 Meridian 将用 Doug 和 Naomi 构建的系统替换其原有的旧订单管理系统。他们消除了大量的架构负担和复杂性，证明了 Temporal 提供了简化现代应用所需的必要构建块。
企业平台：连接点滴
Temporal 的真正力量在于它能够将零散的应用程序、智能体和工具连接成一个统一、衔接的企业平台。通过 Nexus 等协议，Temporal 使长周期运行的操作能够跨不同系统可靠地通信。这实现了端到端平台，让静态工作流、自主智能体和数据转换能够顺畅协同工作。
对于企业领导者而言，Temporal 代表了一项“面向未来”的投资。它不会将用户锁定在特定的库或框架中。相反，它提供了底层，让你的组织能够快速行动，做出大胆的技术选择，并适应变化，而不必担心应用程序的结构完整性。全 工智能
