第3章：工作流（Workflows）
一、导读
1.1 本章学习目标
第3章讲解微服务之间的协作模式——如何在分布式环境中实现跨服务的业务流程。
1.2 为什么第三章如此重要
微服务之间的协作是微服务架构中最复杂的部分。分布式事务、数据一致性、故障恢复，都是需要仔细设计的问题。
1.3 核心问题引导
编排和编舞有什么区别？
Saga 模式如何解决分布式事务？
如何处理跨服务的数据一致性？
工作流失败时如何恢复？
二、核心概念详解
3.1 编排 vs 编舞
编排（Orchestration）：
- 中心协调器控制整个流程
- 协调器调用各个服务
- 适合复杂流程
编舞（Choreography）：
- 没有中心协调器
- 服务之间通过事件通信
- 每个服务独立决策
- 适合简单流程3.2 Saga 模式
Saga 将分布式事务分解为一系列本地事务，每个本地事务都有对应的补偿操作：
订单 Saga：
1. 创建订单 → 补偿：取消订单
2. 预留库存 → 补偿：释放库存
3. 处理支付 → 补偿：退款
4. 确认订单 → 补偿：无
如果第3步失败：
- 执行补偿：释放库存、取消订单3.3 事件驱动工作流
java
// 事件定义
public class OrderCreated {
String orderId;
String userId;
List<OrderItem> items;
}
// 事件处理
public class InventoryService {
@EventListener
public void onOrderCreated(OrderCreated event) {
boolean reserved = reserveStock(event.items());
if (reserved) {
eventBus.publish(new StockReserved(event.orderId()));
} else {
eventBus.publish(new StockReservationFailed(
event.orderId(), "Out of stock"));
}
}
}三、实战案例
3.1 订单流程
编排模式：
OrderOrchestrator
├── createOrder()
├── reserveStock()
├── processPayment()
└── confirmOrder()
编舞模式：
OrderService → 发布 OrderCreated
→ InventoryService → 发布 StockReserved
→ PaymentService → 发布 PaymentProcessed
→ OrderService → 发布 OrderConfirmed四、本章小结
微服务之间的协作需要仔细设计。编排适合复杂流程，编舞适合简单流程。Saga 模式通过补偿机制解决分布式事务。
五、思考与练习
编排和编舞如何选择？
Saga 模式有什么局限性？
如何处理 Saga 中的并发问题？
事件驱动架构如何保证消息不丢失？
如何监控和调试工作流？