236 lines
7.1 KiB
Markdown
236 lines
7.1 KiB
Markdown
# 第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 的版本、认证、限流和监控。
|