wangqifan/aws-doc

Fork 0

wangqifan a80067d684 all

2026-05-08 10:24:39 +08:00

7.1 KiB

Raw Blame History

第29天：Step Functions——编排复杂的业务流程

今天你将学到什么

今天学习 Step Functions——AWS 的工作流编排服务。当你的业务逻辑涉及多个步骤、需要处理分支和错误时，Step Functions 帮你把这些步骤组织成一个可视化的流程图。

为什么需要工作流编排

场景：电商订单处理

用户下单后，需要执行一系列步骤：

1. 验证库存是否充足
2. 扣减库存
3. 创建支付订单
4. 等待用户支付（可能要等几分钟到几小时）
5. 支付成功 → 通知仓库发货
   支付失败 → 恢复库存
6. 发货后更新订单状态
7. 发送物流通知给用户

用 Lambda 硬编码的问题

如果把这些逻辑全写在一个 Lambda 里：

代码又长又复杂，难以维护
Lambda 最长只能运行 15 分钟（等待支付可能超时）
某一步失败了，重试逻辑很难写
看不到流程执行到哪一步了

Step Functions 的解决方案

把每一步拆成独立的 Lambda 函数，用 Step Functions 编排它们：

开始 → 验证库存 → 扣减库存 → 创建支付 → 等待支付
                                            ↓
                              ┌─── 支付成功 ───┐
                              ↓               ↓
                          恢复库存         通知发货
                              ↓               ↓
                          订单取消         发送通知
                              ↓               ↓
                            结束             结束

每一步清晰可见，错误处理和重试由 Step Functions 自动管理。

Step Functions 的核心概念

状态机（State Machine）

Step Functions 的工作流叫"状态机"。它定义了一系列"状态"（步骤）以及状态之间的转换关系。

类比：状态机就像一个流程图。每个方框是一个步骤，箭头表示下一步去哪里。

状态类型

状态类型	作用	举例
Task	执行一个任务	调用 Lambda、发送 SQS 消息
Choice	条件分支	如果库存 > 0 走 A 路径，否则走 B 路径
Wait	等待一段时间	等待 30 秒后继续
Parallel	并行执行多个分支	同时发邮件和发短信
Map	对列表中每个元素执行操作	对订单中的每件商品检查库存
Pass	传递数据（不做操作）	转换数据格式
Succeed	标记成功结束	流程正常完成
Fail	标记失败结束	流程异常终止

实际应用场景

场景一：用户注册流程

开始
  ↓
验证邮箱格式（Task）
  ↓
检查邮箱是否已注册（Task）
  ↓
邮箱已注册？（Choice）
  ├── 是 → 返回错误"邮箱已存在"（Fail）
  └── 否 ↓
创建用户账号（Task）
  ↓
并行执行（Parallel）：
  ├── 发送欢迎邮件（Task）
  ├── 赠送新人优惠券（Task）
  └── 初始化用户偏好设置（Task）
  ↓
注册完成（Succeed）

场景二：视频处理流水线

用户上传一个视频后：

开始
  ↓
获取视频元信息（Task）
  ↓
并行处理（Parallel）：
  ├── 转码为 1080p（Task）
  ├── 转码为 720p（Task）
  ├── 转码为 480p（Task）
  └── 生成缩略图（Task）
  ↓
所有转码完成
  ↓
更新数据库（Task）
  ↓
通知用户"视频处理完成"（Task）
  ↓
结束

场景三：审批流程

员工提交报销申请
  ↓
金额 > 5000？（Choice）
  ├── 是 → 需要总监审批（Task + Wait）
  │         ↓
  │       审批结果？（Choice）
  │         ├── 通过 → 财务打款
  │         └── 拒绝 → 通知员工
  └── 否 → 经理审批（Task + Wait）
            ↓
          审批结果？（Choice）
            ├── 通过 → 财务打款
            └── 拒绝 → 通知员工

Step Functions 的优势

1. 可视化

在 AWS 控制台可以看到流程图，实时显示每一步的执行状态（绿色=成功，红色=失败，蓝色=执行中）。

2. 内置错误处理

不需要自己写 try-catch。Step Functions 支持：

重试（Retry）：某一步失败了，自动重试 3 次，每次间隔递增
捕获（Catch）：重试都失败了，走备用路径（比如通知人工处理）

3. 长时间运行

Step Functions 的工作流可以运行长达一年。适合需要等待人工审批、等待外部事件的场景。

4. 审计追踪

每次执行的每一步都有详细记录：输入、输出、耗时、错误信息。方便排查问题。

Step Functions vs 直接用代码编排

	Step Functions	代码编排
可视化	有流程图	看代码
错误处理	声明式配置	手写 try-catch
长时间等待	原生支持	需要额外机制
并行执行	声明式	手动管理线程/Promise
执行历史	自动记录	需要自己记日志
适合	多步骤、有分支、需要等待	简单线性流程

建议：如果你的流程超过 3 步、有条件分支、或需要等待外部事件，考虑用 Step Functions。

EventBridge——事件驱动架构

和 Step Functions 经常配合使用的还有 EventBridge（事件总线）。

什么是事件驱动

传统方式：服务 A 完成工作后，主动调用服务 B、服务 C、服务 D。

事件驱动：服务 A 完成工作后，发布一个"事件"。对这个事件感兴趣的服务自己来响应。

传统方式：
  订单服务 → 调用库存服务
           → 调用通知服务
           → 调用积分服务
  （订单服务需要知道所有下游服务）

事件驱动：
  订单服务 → 发布"订单创建"事件到 EventBridge
  EventBridge → 库存服务（自动触发）
             → 通知服务（自动触发）
             → 积分服务（自动触发）
  （订单服务不需要知道谁在监听）

EventBridge 的能力

接收来自 AWS 服务的事件（EC2 状态变化、S3 文件上传等）
接收来自你自己应用的自定义事件
根据规则把事件路由到不同的目标（Lambda、SQS、Step Functions 等）
支持定时触发（类似 cron）

今天的小测验

Step Functions 解决了什么问题？什么场景适合用它？
Step Functions 中的 Choice 状态和 Parallel 状态分别做什么？
Step Functions 的错误处理机制（Retry 和 Catch）有什么好处？
事件驱动架构和传统的直接调用有什么区别？

明天预告

明天学习 API Gateway——如何为你的后端服务创建统一的 API 入口，管理 API 的版本、认证、限流和监控。

7.1 KiB Raw Blame History Unescape Escape