微服务架构的分布式事务解决方案

微服务架构的分布式事务解决方案

在分布式系统架构中，分布式事务问题是一个绕不过去的挑战。随着微服务架构的流行，这一问题日益突出。本文将通过一个电商购物支付流程的案例，详细分析各个环节可能遇到的分布式事务问题，并提出相应的解决方案。

假设一个典型的电商购物支付流程涉及三大参与者平台：电商平台、支付平台和银行。这些平台的系统都采用了分布式系统架构。以下是整个支付流程中可能遇到的分布式事务问题的场景分析：

1. 电商平台创建订单：在创建订单时，需要预留库存、预扣减积分、锁定优惠券。此时，电商平台内部各服务间会产生分布式事务问题，因为需要跨多个内部服务修改数据。

2. 支付平台创建支付订单（选择银行卡支付）：在支付平台中，需要查询账户和限制规则。如果符合条件，创建支付订单并跳转到银行。此时不会产生分布式事务问题，因为还没有跨服务修改数据。

3. 银行平台创建交易订单：在银行平台中，需要查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台。如果银行系统采用服务化架构，这里也会有分布式事务问题。

4. 支付平台处理银行扣款结果：支付平台需要更改订单状态、给账户加款、给积分账户增加积分、生成会计分录、通知电商平台等。这些操作涉及多个服务间的调用，会产生分布式事务问题。

5. 电商平台处理支付结果：电商平台需要更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等。这些操作同样涉及系统内部各服务间的调用，会产生分布式事务问题。

支付平台处理银行扣款结果的内部流程

1. 支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理。
2. 支付订单服务根据银行扣款结果更改支付订单状态。
3. 调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）。
4. 调用积分服务给用户积分账户增加积分。
5. 调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录。
6. 调用通知服务将支付处理结果通知电商平台。

对应的分布式事务问题的代码场景

@Transactional(rollbackFor = Exception.class)
public void completeOrder() {
    orderDao.update(); // 订单服务本地更新订单状态
    accountService.update(); // 调用资金账户服务给资金帐户加款
    pointService.update(); // 调用积分服务给积分帐户增加积分
    accountingService.insert(); // 调用会计服务向会计系统写入会计原始凭证
    merchantNotifyService.notify(); // 调用商户通知服务向商户发送支付结果通知
}

分布式事务解决方案

针对上述分布式事务问题，可以采用以下解决方案：

• 订单处理：采用本地事务
• 资金账户加款、积分账户增加积分：采用TCC型事务（或两阶段提交型事务），因为这些操作对实时性和数据可靠性要求较高。
• 会计记账：采用异步确保型事务（基于可靠消息的最终一致性），可以异步处理，但数据绝对不能丢失，且一定要记账成功。
• 商户通知：采用最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对）。