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

分布式系统架构中，分布式事务问题是一个绕不过去的挑战。而微服务架构的流行，让分布式事问题日益突出！

下面咱们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！

如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都作了分布式系统架构拆分，按上数中的流程步骤进行分析：

一、电商平台中建立订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，由于此时已经要跨多个内部服务修改数据；

二、支付平台中建立支付订单（选银行卡支付）：查询帐户、查询限制规则，符合条件的就建立支付订单并跳转银行，此时不会有分布式事务问题，由于还不会跨服务改数据；

三、银行平台中建立交易订单：查找帐户、建立交易记录、判断帐户余额并扣款、增长积分、通知支付平台，此时也会有分布式事务问题（若是是服务化架构的话）；

四、支付平台收到银行扣款结果：更改订单状态、给帐户加款、给积分账户增长积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；

五、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增长消费积分等，系统内部各服务间调用也会遇到分布式事问题；

 

如上图，支付平台收到银行扣款结果后的内部处理流程：

一、支付平台的支付网关对银行通知结果进行校验，而后调用支付订单服务执行支付订单处理；

二、支付订单服务根据银行扣款结果更改支付订单状态；

三、调用资金帐户服务给电商平台的商户帐户加款（实际过程当中可能还会有各类的成本计费；若是是余额支付，还多是同时从用户帐户扣款，给商户帐户加款）；

四、调用积分服务给用户积分帐户增长积分；

五、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；

六、调用通知服务将支付处理结果通知电商平台；

 

如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：

/** 支付订单处理 **/

@Transactional(rollbackFor = Exception.class)

public void completeOrder() {

  orderDao.update();  // 订单服务本地更新订单状态

  accountService.update();  // 调用资金帐户服务给资金账户加款

  pointService.update();  // 调用积分服务给积分账户增长积分

  accountingService.insert();  // 调用会计服务向会计系统写入会计原始凭证

  merchantNotifyService.notify();  // 调用商户通知服务向商户发送支付结果通知

}

 

本地事务控制还可行吗？

 

以上分布式事务问题，须要多种分布式事务解决方案来进行处理。

 

订单处理：本地事务

 

资金帐户加款、积分帐户增长积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。

 

会计记帐：异步确保型事务（基于可靠消息的最终一致性，能够异步，但数据绝对不能丢，并且必定要记帐成功）

 

商户通知：最大努力通知型事务（按规律进行通知，不保证数据必定能通知成功，但会提供可查询操做接口进行核对）

 

针对上以分布式事务问题，龙果学院（http://www.roncoo.com）的《微服务架构的分布式事务解决方案》视频教程中将提供详细完整的方案供你们学习和应用。

http://www.roncoo.com/details?cid=7ae3d7eddc4742f78b0548aa8bd9ccdb