事件驱动工作流 = Choreography vs Orchestration
解决什么问题：跨多微服务的业务流程如何协调—— Choreography 隐式协调，Orchestration 显式协调，选择决定可维护性。
业务问题
真实场景
场景 1：电商下单工作流
业务流程：下单 → 扣库存 → 收款 → 发货 → 通知
方案 A：Choreography（事件驱动 + 无中心）
OrderService 下单 → 发 OrderCreated 事件
↓
InventoryService 监听 → 扣库存 → 发 InventoryReserved
↓
PaymentService 监听 → 收款 → 发 PaymentCompleted
↓
ShippingService 监听 → 发货 → 发 OrderShipped
↓
NotificationService 监听 → 通知
方案 B：Orchestration（中央协调器）
OrderOrchestrator 接收下单请求
→ 调 InventoryService 扣库存
→ 调 PaymentService 收款
→ 调 ShippingService 发货
→ 调 NotificationService 通知Bellemare Ch 8 原话：
"The Choreography Pattern... Microservices react to their input events as they arrive, without any blocking or waiting, in a manner fully independent from any upstream producers or subsequent downstream consumers."
失败模式
| 失败模式 | 后果 |
|---|---|
| 选错模式 | 工作流难维护或难追踪 |
| 混合用 | 行为不一致、难调试 |
| 无关联 ID | 无法追踪 |
控制论视角
Ch 21："多级分散系统的协调" + Ch 4 §4.6："反馈环路"
Choreography = 多级分散（无中心）
- 各服务独立反应（反馈环路短）
- 协调是涌现行为
Orchestration = 中心协调（控制器）
- 一个中央控制器协调
- 协调逻辑集中（可观测）对位：
- Choreography = 分布式控制律（每服务一个控制律）
- Orchestrator = 中央控制律（一个服务协调全局）
- Saga = 长链路反馈控制
核心概念
Choreography 详解
特征：
- 服务间无直接调用
- 通过事件流通信
- 工作流是"涌现行为"
优点：
- 松耦合
- 易添加/删除服务
- 故障隔离
- 高伸缩性
缺点：
- 工作流难追踪（无中心）
- 中间插入步骤难
- 顺序修改困难
- 业务逻辑分散Orchestration 详解
特征：
- 中央 Orchestrator 服务
- 显式调用其他服务
- 显式工作流逻辑
- 显式补偿逻辑
优点：
- 工作流清晰可见
- 易于修改
- 易于追踪
- 业务逻辑集中
缺点：
- Orchestrator 是单点
- 紧耦合到 Orchestrator
- 难演化
- 协调器容易膨胀决策矩阵
| 维度 | Choreography | Orchestration |
|---|---|---|
| 工作流复杂度 | 低 | 高 |
| 修改频率 | 低 | 高 |
| 团队数量 | 多 | 少 |
| 故障容忍 | 高 | 中 |
| 可观测性 | 低 | 高 |
| 伸缩性 | 高 | 中 |
| 调试难度 | 高 | 低 |
Saga 模式（两者的混合）
Saga = 多步 + 补偿
类型：
- Orchestrated Saga：中央协调器
- Choreographed Saga：事件驱动协调
例：下单 Saga
Step 1: 创建订单（OrderService）
Step 2: 扣库存（InventoryService）
Step 3: 收款（PaymentService）
Step 4: 发货（ShippingService）
任一步失败 → 补偿已完成的步骤
Step 1 失败 → 取消订单
Step 2 失败 → 取消订单 + 释放库存（如果已扣）
Step 3 失败 → 退款 + 取消订单 + 释放库存工程实践
决策树
决策：
1. 工作流步骤数 > 5？
- 是 → Orchestration 更可管理
- 否 → Choreography 即可
2. 业务逻辑变更频繁？
- 是 → Orchestration（业务集中）
- 否 → 两者都可
3. 团队规模 > 10？
- 是 → Choreography（自治）
- 否 → Orchestration（效率）
4. 故障容忍要求高？
- 是 → Choreography（无中心）
- 否 → 两者都可实战 1：监控 Choreography 工作流
方法：
- 关联 ID（贯穿所有事件）
- 分布式追踪（OpenTelemetry）
- 状态机建模
- 工作流完成检测（超时 + 完成标志）实战 2：Orchestrator 实现
python
class OrderOrchestrator:
def execute(self, order):
try:
# 步骤 1：扣库存
self.inventory_service.reserve(order)
# 步骤 2：收款
self.payment_service.charge(order)
# 步骤 3：发货
self.shipping_service.ship(order)
# 步骤 4：通知
self.notification_service.send(order)
except InsufficientStock:
self.compensate_inventory(order)
raise
except PaymentFailed:
self.compensate_payment(order)
self.compensate_inventory(order)
raise
# ...反模式 vs 正模式
| 反模式 | 正模式 |
|---|---|
| Orchestrator 调用所有步骤（含业务逻辑） | Orchestrator 只协调，业务逻辑在服务 |
| Choreography 但有强顺序要求 | 用事件顺序或 Saga |
| 混合 Choreography + Orchestration | 明确选一种 |
| 无关联 ID | 强制关联 ID |
性能指标
| 指标 | 衡量 | 健康值 |
|---|---|---|
| 工作流完成率 | 成功完成的工作流比例 | > 99% |
| 平均完成时间 | 工作流耗时 | 业务决定 |
| 可追踪工作流比例 | 可端到端追踪的工作流 | > 95% |
| 补偿成功率 | Saga 补偿成功比例 | > 99% |
边界判断
何时用 Choreography（默认）
- 简单工作流（< 5 步）
- 步骤独立
- 高伸缩性需求
- 故障容忍重要
何时用 Orchestration
- 复杂工作流（> 5 步）
- 业务逻辑复杂
- 频繁修改
- 需要集中监控
何时用 Saga
- 跨服务事务
- 需要补偿
- 业务一致性要求
关键洞察
- 选择决定可维护性——不是技术对错，是运维体验。
- Choreography + 关联 ID = 可追踪——没有 ID 就没救。
- Orchestrator 是状态机——避免变成"上帝服务"。
- Saga 是分布式事务的标准答案——比 2PC 简单 100 倍。
- 与 cybernetics 同构——Ch 21 多级分散协调 = Choreography；Ch 4 §4.6 中央反馈 = Orchestration。