在 re:Invent 2025 我最想立刻上手的一项新东西

type
status
date
slug
summary
tags
category
icon
password
name
先把结论放前面：
如果你正在用 Lambda 做“多步骤 + 可能失败重试 + 还要等外部回调/等人审批”的业务流程，Durable Functions 会让你写代码的方式从“拼积木”变成“写顺序逻辑”。
它不是让 Lambda 变强一点点，而是把“流程编排、断点续跑、等待不占用计算”这套能力，塞回了 Lambda 代码里。
说明：re:Invent 发布信息细节（区域、计费、上限、SDK 语言、控制台入口）可能会在后续更新；落地前建议以你所在区域的最新控制台/官方文档为准。我下面写的是“学习心得 + 工程视角”的理解方式。

1）为什么我会被它吸引：我太熟悉那种“长流程被迫碎成一堆 Lambda”的痛

Lambda 的舒适区一直是：短、快、单次。
但现实业务是这样的：
  • 订单链路：校验 → 扣款 → 风控 → 扣库存 → 发货 → 通知
  • 人工审批：发起 → 等 1 天 → 通过/拒绝 → 继续后续动作
  • AI 工作流：多次模型调用 + 外部工具回调 + 中间要等人给反馈
你只要碰到“流程”两个字，Lambda 就容易变成这样：
  • 每一步一个函数
  • 状态落 DynamoDB / RDS
  • 重试、补偿、幂等自己写
  • 等待回调靠队列/事件再触发下一步
  • 一不小心就产生“谁负责把流程推进到下一步”的责任分裂
最后的体感就是：业务代码没写多少，胶水代码写了一堆。
Durable Functions 的价值点就在这里：
让你在一个函数里写出“顺序流程”，平台帮你处理“断点、恢复、等待、重放”。

2）它的核心机制其实就两个词：Checkpoint + Replay

理解 Durable Functions，不需要先背一堆 API。你先把这两个词吃透就行：

✅ Checkpoint（检查点）

你把流程拆成一个个“步骤（step）”，每个关键点平台会把状态持久化下来。
所以流程可以：
  • 中断后恢复
  • 失败后从最近完成的步骤继续
  • 等待很久后回来接着跑

✅ Replay（重放）

恢复的时候不是从某行代码继续跑，而是从头“再跑一遍”。
但注意：已经完成过的 step 会直接复用上次结果，不会再次执行副作用。
这听起来反直觉，但它带来的好处很直接：
你不用自己维护“当前跑到第几步”，你只要把副作用放在正确的地方，流程就能自然地恢复。

3）我最喜欢的两个能力：step 和 wait（这俩就是“写起来顺”的关键）

3.1 step：把副作用关进笼子里

扣款、写库、调外部 API、发消息……这些都是副作用。
Durable 的建议很朴素：
所有“可能重复执行会出事”的逻辑，都放进 step。
step 的意义不只是“分段”，更是：
  • 结果可被 checkpoint
  • 失败可重试
  • 恢复可复用
  • 你更容易做幂等边界

3.2 wait：真正的暂停，而不是“等着烧钱”

以前你想等回调/等审批，常见套路是：
  • 发起动作 → 返回
  • 等回调事件 → 触发下一段 Lambda
  • 你自己保证状态推进正确
现在流程里可以直接写 wait：
挂起执行，等条件满足再恢复。
这对“人在回路（human-in-the-loop）”“外部系统回调”“定时等待”这种场景，体验会非常好。

4）用一段伪代码感受一下：它更像“写脚本”，但能跑一年

我用伪代码写一下“订单 + 审批”的感觉（不是可直接运行的代码）：
你看它读起来就是：
先校验，再扣款，再等审批，再扣库存，再发货。
但它具备“可暂停 + 可恢复 + 可重放 + 可重试”的能力。
这就是它最迷人的地方：写法“像同步”，执行“像异步编排”。

5）最容易踩坑的点（我会在团队里直接写进规范）

我个人认为 Durable Functions 的“难点”只有一个：
你必须接受 replay 的世界观。

5.1 可确定性（deterministic）是第一原则

因为会 replay，所以主流程里不要写这些：
  • Date.now() / 当前时间（重放会变）
  • Math.random() / UUID（重放会变）
  • 不受控的外部调用（重放可能再次调用）
  • 依赖内存状态/全局变量（恢复时不可信）
我的记忆口诀：
主流程只做“编排”。不确定的东西、外部世界、所有副作用，全塞 step。

5.2 step 命名必须稳定

别用时间戳、别拼随机串。
否则恢复时可能对不上“哪个 step 是哪个”。

5.3 状态要小：别把大对象当接力棒

checkpoint 需要持久化状态。
你把状态写得越大：
  • 越慢
  • 越贵
  • 越容易碰上限
工程上更推荐：
  • 状态里只存 ID / 关键字段
  • 大对象放 S3/数据库，step 内按需读取

5.4 幂等不是“选修课”，是“必修课”

Durable 能帮你“从检查点继续”，但它不会替你保证“副作用永不重复”。
支付、扣库存、发货这种动作，必须自己做幂等（比如 idempotency key、去重表、业务幂等约束）。

6）它会替代 Step Functions 吗？我的选型答案是：不会，但会抢走一大块场景

我把它理解成两条路：

更偏 Durable Functions 的场景

  • 你想要“代码即流程”，更愿意用 TS/Python 写顺序逻辑
  • 流程高度业务化、迭代频繁，团队更喜欢“改代码发版”
  • 不想把流程拆得太碎，不想维护一堆状态推进逻辑

更偏 Step Functions 的场景

  • 你需要“可视化流程资产”，跨团队阅读和治理
  • 大量并行/分支/补偿/跨服务编排，想用成熟编排控制面
  • 更希望流程定义独立于业务代码（平台化管理）
一句话我会写在评审结论里：
Durable Functions 更像“把编排能力下沉到 Lambda 代码”；
Step Functions 更像“独立编排控制面”，适合平台化与可视化治理。

7）我会怎么推荐团队上手（半天到一天能摸到门道）

如果让我带新人快速上手，我会按这个顺序：
  1. 先理解 replay：知道为什么“随机数/时间/外部调用”要进 step
  1. 做一个最小流程：3 个 step + 1 个 wait（比如审批）
  1. 补齐工程化：幂等策略、超时策略、失败告警、日志追踪
  1. 写团队规范：step 命名、状态大小、外部调用边界、重试策略
  1. 再考虑扩展：把它用到订单/风控/AI 工作流/后台任务等真实链路

8）写在最后：它让“长流程”终于可以像写代码一样自然

我对这项能力最大的好感，是它把过去“写流程”要面对的一堆碎片问题——
  • 等待
  • 恢复
  • 断点续跑
  • 重试
  • 状态推进
尽可能变成了平台内建，而你能用更“顺序化”的代码表达业务意图。
如果你以前也被“长流程”折磨过（尤其是审批、回调、跨系统协同），Durable Functions 会是那种看完就想开个 repo 试一试的新能力。
Loading...

© Dreamin 2021-2026