这个被忽视四年的AWS功能，让我省下一半成本

2020年，AWS发布了一个功能，当时没多少人当回事。四年过去，用它的人开始偷偷省钱。

synchronous Express Workflows——同步快速工作流。名字拗口，但用起来像给Lambda装了个大脑。作者去年大规模试了一年，结论是：这才是构建微服务的正确姿势。

Lambda的甜蜜与苦涩

Lambda是AWS无服务器的门面。输入输出，简单直接，"把这个消息入队"或"按key取数据库记录"——这种活它干得很漂亮。

但现实复杂得多。一个同步请求里要做多件事，要有分支逻辑，要处理错误。一旦偏离"就是个函数"的模型，成本、性能、可观测性全开始出问题。

电商订单处理是典型场景：验证商品、检查库存、预留库存、处理支付、保存订单。每个环节都可能失败，失败要回滚，还要快速响应。

用纯Lambda写这段逻辑？可以，但代码里会塞满重试逻辑、补偿逻辑、状态管理。维护起来像拆炸弹。

Step Functions的隐藏版本

Step Functions本身不新，但大多数人用的是标准版——异步、按状态转换计费、适合长时间运行。

Express版是另一个东西。2020年发布，同步响应，按执行次数计费，最长5分钟。作者去年才真正大规模用上。

关键区别：标准版像寄挂号信，Express版像打电话。一个等回音，一个立刻回。

在Step Functions控制台里，这套流程可以画出来：并行执行验证和库存检查，错误状态用菱形框标出，补偿逻辑用虚线连接。Workflow Studio支持拖拽，做完能导出到基础设施即代码。

作者的项目用AWS CDK管理。目录结构很清晰：bin放入口，lib放栈定义和状态机，functions放七个Lambda——验证订单、预留库存、释放库存（补偿用）、处理支付、保存订单、查订单、列商品。

预留库存和释放库存是一对。Map状态循环处理每个商品项，失败时触发补偿，把已预留的全部释放。这是Saga模式的朴素实现。

钱是怎么省下来的

成本结构完全不同。标准Step Functions按状态转换收费，复杂工作流转一次可能几十个状态，费用线性增长。

Express版按执行次数收费，与状态数量无关。并行步骤不额外计费，错误处理不额外计费，重试逻辑也不额外计费。

性能也有优势。同步模式省掉轮询开销，端到端延迟更低。作者没给具体数字，但强调"performant and economical"——又快又便宜。

可观测性是意外收获。状态机可视化就是天然的操作手册，哪个环节失败、走到哪一步补偿、整体执行路径，控制台里一目了然。不用在CloudWatch里翻Lambda日志拼故事。

什么时候该用它

不是万能药。超过5分钟的长流程、需要人工审批的环节、跨天暂停的场景，还是得用标准版。

但微服务里的请求-响应式流程，特别是有明确成功/失败定义、需要强一致性的交易类操作，Express版是更优解。

作者的样本项目已经开源。从CDK初始化到完整可部署的订单系统，代码结构可以直接抄。

2020年发布时，这个功能被低估了。四年过去，云成本压力变大，人们重新发现它。技术选型里常有这种时差——好工具需要坏环境来证明自己。