# 第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）

---

## 今天的小测验

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

---

## 延伸阅读

- [Step Functions 开发者指南](https://docs.aws.amazon.com/step-functions/latest/dg/)
- [EventBridge 用户指南](https://docs.aws.amazon.com/eventbridge/latest/userguide/)
- [Step Functions 工作流示例](https://docs.aws.amazon.com/step-functions/latest/dg/create-sample-projects.html)

---

## 明天预告

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