微服务

微服务分布式协同工作模型介绍

在微服务架构中，分布式事务和协同工作是核心挑战之一。以下是常见的分布式协同工作模型及其特点：

1. Saga 模式

核心思想

  • 将一个长事务拆分为多个本地事务（子事务），通过补偿机制实现最终一致性。
  • 两种实现方式：
    • 编排式（Choreography）：通过事件驱动，各服务自主触发后续操作。
    • 编排式（Orchestration）：由中央协调器（Saga Orchestrator）统一调度。

流程

  1. 按顺序执行各子事务。
  2. 若某个子事务失败，触发逆向补偿操作（Compensating Transaction）回滚已完成的步骤。

优点

  • 避免全局锁，适合长事务（秒/分钟级）。
  • 天然适应服务自治的微服务架构。

缺点

  • 补偿逻辑复杂，需为每个正向操作设计逆向操作。
  • 无法保证中间状态的隔离性（可能读到脏数据）。

适用场景

  • 电商订单（创建订单→扣库存→支付→发货）。
  • 跨服务业务流程（如旅行预订：机票+酒店）。

2. 两阶段提交（2PC, Two-Phase Commit）

核心思想

  • 通过协调者（Coordinator）统一管理事务提交，分为两阶段：
    1. 准备阶段（Prepare Phase）：参与者预提交并锁定资源。
    2. 提交阶段（Commit/Rollback Phase）：协调者根据所有参与者的响应决定提交或回滚。

优点

  • 强一致性，适合短事务（毫秒级）。
  • 传统数据库事务的经典模型。

缺点

  • 同步阻塞：资源锁定期间其他操作被阻塞。
  • 协调者单点故障可能导致系统僵局。
  • 不适合跨网络调用延迟高的场景。

适用场景

  • 传统单体数据库的分布式扩展（如分库分表）。
  • 对一致性要求极高的金融交易（如银行转账）。

3. 三阶段提交（3PC, Three-Phase Commit）

核心思想

  • 在 2PC 基础上增加 预提交阶段（CanCommit Phase），减少阻塞风险：
    1. CanCommit：协调者询问参与者是否具备提交条件。
    2. PreCommit：参与者预锁定资源。
    3. DoCommit：最终提交或回滚。

优点

  • 降低阻塞概率，协调者故障时参与者可自动超时提交。

缺点

  • 实现复杂，网络交互次数增加。
  • 仍无法彻底解决数据不一致问题。

适用场景

  • 对 2PC 的改进需求场景，但实际应用较少。

4. TCC（Try-Confirm-Cancel）

核心思想

  • 将事务分解为三个阶段：
    1. Try：预留资源（如冻结库存）。
    2. Confirm：确认提交（如实际扣减库存）。
    3. Cancel：取消预留（释放资源）。

优点

  • 细粒度控制，可避免长期资源锁定。
  • 支持自定义业务逻辑的补偿。

缺点

  • 需为每个操作实现 Try/Confirm/Cancel 接口，开发成本高。
  • 可能因网络重试导致重复调用（需幂等性设计）。

适用场景

  • 高并发场景（如秒杀系统）。
  • 需要灵活控制资源预留的业务（如优惠券核销）。

5. 事件驱动（Event Sourcing + CQRS）

核心思想

  • 通过事件溯源记录状态变化，结合异步消息实现最终一致性。
  • CQRS（Command Query Responsibility Segregation）：读写分离，命令端生成事件，查询端通过订阅事件更新数据。

流程

  1. 服务 A 执行操作并发布事件到消息队列。
  2. 服务 B 订阅事件并更新自身状态。

优点

  • 松耦合，服务间通过事件通信。
  • 支持审计和回放（事件日志持久化）。

缺点

  • 最终一致性，存在短暂数据不一致窗口。
  • 事件顺序和重复处理需额外处理（如 Kafka 分区）。

适用场景

  • 用户行为跟踪、审计日志。
  • 复杂业务流程（如物流状态更新）。

6. 异步消息（基于消息队列）

核心思想

  • 使用消息队列（如 RabbitMQ、Kafka）保证消息可靠传递，结合本地事务表实现最终一致性。
  • 本地事务表：业务操作和消息发送在同一个本地事务中完成。

流程

  1. 服务 A 执行本地事务并写入消息到本地表。
  2. 后台进程轮询本地表，将消息发送到队列。
  3. 服务 B 消费消息并处理。

优点

  • 避免分布式事务，依赖消息队列的可靠性。
  • 天然解耦，适合高吞吐场景。

缺点

  • 需处理消息重复消费（幂等性）。
  • 最终一致性，不适合强一致性需求。

适用场景

  • 用户注册后发送欢迎邮件。
  • 订单支付后通知物流系统。

模型对比与选型建议

模型 一致性 性能 复杂度 适用场景
2PC 强一致性 低 中 短事务、强一致性需求（如金融）
3PC 强一致性 中 高 改进 2PC 阻塞问题（实际应用较少）
Saga 最终一致性 高 高 长事务、服务自治（如电商订单）
TCC 最终/强一致性 高 高 高并发、需资源预留（如秒杀）
事件驱动 最终一致性 高 中 松耦合、审计需求（如物流跟踪）
异步消息 最终一致性 高 低 解耦、高吞吐（如通知类业务）

选型关键点

  1. 一致性需求：强一致性选 2PC/TCC，最终一致性选 Saga/事件驱动。
  2. 事务时长：短事务用 2PC/TCC，长事务用 Saga。
  3. 系统复杂度：简单场景用异步消息，复杂业务用 Saga/TCC。
  4. 容错能力：Saga 需设计补偿逻辑，TCC 需处理预留资源。

现代趋势

  • Saga + 事件驱动：结合编排式 Saga 与事件溯源，提升可观测性。
  • 框架支持：Seata（AT/TCC/Saga）、Axon Framework（事件溯源）、Narayana（2PC）。
  • Serverless 集成：通过无服务器架构（如 AWS Step Functions）实现 Saga 编排。

通过合理选择模型，可在微服务架构中平衡一致性、可用性和性能。

在微服务架构中，由于服务独立部署、数据分库存储，跨服务的事务和协同变得复杂。以下通过一个电商下单流程的示例，说明分布式事务和协同工作的挑战：

场景描述

用户下单购买商品，涉及以下服务：

  1. 订单服务：创建订单。
  2. 库存服务：扣减商品库存。
  3. 支付服务：处理用户支付。
  4. 积分服务：为用户增加积分（促销活动）。

用户期望：订单成功 = 订单创建 + 库存扣减 + 支付成功 + 积分增加，所有操作需全部成功或全部回滚。

挑战 1：分布式事务的一致性

问题示例

  • 用户下单后，订单服务创建订单（本地事务提交成功）。
  • 库存服务扣减库存（成功）。
  • 支付服务因网络超时返回失败。
  • 结果：订单已存在，库存已扣减，但支付未完成，用户未付款却库存减少，数据不一致。

核心难点

  • 原子性难以保证：传统单体应用的数据库事务（ACID）无法跨服务生效。
  • 补偿逻辑复杂：需为每个正向操作设计逆向操作（如扣减库存后需自动恢复库存）。

挑战 2：服务协同的可靠性

问题示例

  • 支付服务处理完成后，需通知积分服务增加积分。若积分服务宕机或消息丢失：
    • 同步调用：支付服务阻塞，用户体验下降。
    • 异步消息：用户积分未及时到账，需额外设计消息重试和幂等性。

核心难点

  • 服务依赖耦合：支付服务需感知积分服务的存在，违背微服务自治原则。
  • 最终一致性延迟：用户可能看到积分未及时更新，需处理中间状态。

挑战 3：异常场景的复杂性

问题示例

  1. 网络分区：

    • 订单服务调用库存服务扣减库存，但因网络故障未收到响应。
    • 订单服务：无法判断库存是否扣减，重试可能导致重复扣减。
    • 库存服务：可能已扣减但未返回结果，需设计幂等接口。

  2. 服务雪崩：

    • 促销活动期间，积分服务因高并发宕机。
    • 支付服务因依赖积分服务而阻塞，导致整个下单流程崩溃。

解决方案示例

1. Saga 模式（最终一致性）

  • 正向流程：
    订单创建 → 扣减库存 → 支付 → 增加积分。
  • 逆向补偿：
    若支付失败，依次触发：
    取消支付 → 恢复库存 → 删除订单。
  • 缺点：需为每个服务设计补偿接口（如 RestoreInventory()）。

2. TCC 模式（Try-Confirm-Cancel）

  • Try 阶段：
    预留资源（如冻结库存、预扣款）。
  • Confirm 阶段：
    确认资源（实际扣减库存、完成支付）。
  • Cancel 阶段：
    释放预留资源（解冻库存、退回预扣款）。
  • 优点：避免长期资源占用，适合高并发场景。

3. 异步消息 + 本地事务表

  • 支付服务完成支付后，将“支付成功”消息写入本地数据库事务表。
  • 后台任务轮询事务表，将消息发送到 Kafka。
  • 积分服务消费消息并增加积分，确保最终一致性。
  • 优点：解耦服务，但需处理消息重复消费（幂等性）。

挑战总结

挑战类型 具体问题 解决方案示例
事务原子性 跨服务操作无法全部成功/回滚 Saga 模式、TCC 模式
服务依赖 同步调用导致耦合和雪崩风险 异步消息、事件驱动
异常处理 网络超时、服务宕机、消息丢失 重试机制、熔断降级、幂等设计
数据一致性 中间状态可见（如积分未到账） 明确提示用户、补偿任务自动修复

实际案例：航空订票系统

  1. 用户预订机票，涉及服务：
    • 订单服务、座位库存服务、支付服务、短信通知服务。
  2. 问题：
    • 支付成功后，短信服务故障，用户未收到确认信息。
    • 座位库存服务因并发超卖，需回滚已确认的订单。
  3. 解决：
    • 使用 Saga 模式，支付失败时触发“释放座位”补偿操作。
    • 短信通知改为异步消息，允许延迟送达，但需记录日志人工兜底。

总结

分布式事务和协同的挑战本质是在失去全局锁和共享数据库的情况下，如何协调多个独立服务的操作。需根据业务场景权衡：

  • 强一致性：2PC/TCC（牺牲性能）。
  • 最终一致性：Saga/异步消息（接受短暂不一致）。
  • 容错设计：超时控制、熔断降级、幂等性。

这些挑战迫使开发者从“上帝视角”的单体思维，转变为“协同自治”的分布式思维。