背景介绍

本篇是北京云栖大会Tech Insight Workshop金融云主题《使用SOFA来快速构建金融级分布式交易系统》中的一个组成部分.

通过前面的篇章，我们已经借助SOFA Boot框架构建了基于微服务架构的分布式交易系统框架，以及借助数据访问代理将系统的订单库由单库单表模式改造为分库分表，便于支撑平台日益增长的数据量。

在本章节中会介绍如何通过引入蚂蚁中间件的分布式事务产品来保证金融级交易系统的一致性问题，并且会分别介绍分布式事务的两种模式：TCC模式和自动模式的使用方式。

DEMO整体架构与说明

实验涉及SOFA产品

分布式事务

环境准备

通过之前步骤的操作，目前分布式交易系统DEMO已经具备了交易与支付两个微服务
在这里我们依然需要基于SOFA Boot框架构建一个Core工程（facade范式）：【账务】服务，该服务将用于处理消费者和商家之前的转账操作。（具体实现代码会在审核后放出）
基于事务的视角，【支付】服务发起转账（事务）请求，【账户】服务处理实际的转账（事务）操作，那么【支付】服务在这里被视为事务的发起者，而【账户】服务被视为事务的参与者。
分布式事务被简称为DTX（Distribution Transaction）

详细步骤

基于TCC模式的代码改造

为【参与者】代码工程增加分布式事务的依赖包

基于facade范式构建的工程，在service模块XML文件中配置分布式事务扫描器
在facade中设计并参与者的从属业务（AccountTransMinus & AccountTransAdd）需要提供的TCC接口
在service中实现参与者的从属业务接口
实现了接口后就可以提供RPC服务进行发布了（生产者）
将会基于共享版中间件进行发布，配置相关云上共享版的账户，截止当前步骤TCC模式下的参与者代码修改已经完成
为【发起方】（【支付】服务）代码工程增加分布式事务的依赖包

为【支付】服务引入【账务】服务的RPC调用的依赖，以及引入对应的bean

模块XML文件中引入DTX扫描器
改造【支付】服务，开启分布式事务，调用【账务】服务的两个从属业务接口
至此，基于TCC模式下的分布式事务改造就完成了（当然，需要配置对应的账务数据库，相关的DDL语句与DAL代码请在DEMO源码开放出后进行参照）。

基于自动模式的代码改造

可以看到，基于TCC的分布式事务改造虽然并不复杂，但是毕竟需要对已有的业务实现进行改造。自动模式的诞生就是为了解决这个问题，它的出现很大程度上可以通过不修改已有的业务代码就可以实现事务一致性的保障。

为【参与者】工程引入分布式事务的依赖包

配置分布式事务的扫描器
通过原始业务代码中增加注解，来表示这里的业务逻辑包含事务，需要保障一致性
修改数据源配置
因为自动模式需要在参与者所使用的数据源中记录事务信息，所以需要手动在对应的业务数据库中创建两张表

CREATE TABLE `dtx_row_lock` (
  `action_id` varchar(128) NOT NULL COMMENT '分支事务号',
  `tx_id` varchar(128) NOT NULL COMMENT '主事务号',
  `table_name` varchar(64) DEFAULT NULL COMMENT '表名称',
  `row_key` varchar(512) NOT NULL COMMENT '行唯一key',
  `instance_id` varchar(32) NOT NULL COMMENT '实例id',
  `context` varchar(2000) DEFAULT NULL COMMENT '分支上下文',
  `feature` varchar(2000) DEFAULT NULL COMMENT '扩展属性',
  `gmt_create` datetime NOT NULL COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL COMMENT '修改时间',
  PRIMARY KEY (`row_key`,`instance_id`),
  KEY `idx_txid_action_id` (`action_id`,`tx_id`,`instance_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='行锁';

CREATE TABLE `dtx_branch_info` (
  `action_id` varchar(128) NOT NULL COMMENT '分支事务号',
  `tx_id` varchar(128) NOT NULL COMMENT '主事务号',
  `status` varchar(4) DEFAULT NULL COMMENT '事务状态',
  `log_info` blob COMMENT 'undo/redo log',
  `biz_type` varchar(32) DEFAULT NULL COMMENT '发起方业务类型',
  `instance_id` varchar(32) DEFAULT NULL COMMENT '实例id',
  `context` varchar(2000) DEFAULT NULL COMMENT '分支上下文',
  `feature` varchar(2000) DEFAULT NULL COMMENT '扩展属性',
  `gmt_create` datetime NOT NULL COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL COMMENT '修改时间',
  PRIMARY KEY (`action_id`),
  KEY `idx_txid_action_id` (`action_id`,`tx_id`,`instance_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='分支记录日志';

至此，自动模式下参与者的修改就完成了
进行对发起方的修改，首先是添加依赖包

增加分布式事务的扫描器
增加注释，以表明这里包含事务
修改数据源
至此，基于自动模式的【发起方】的代码改造也已完成。相关的DEMO源码需要在审核后对外进行发布。

结论

至此，基于SOFA这个可扩展的分布式云平台所构建的金融交易系统就创建完毕了，整个DEMO分别涉及到分布式数据库，微服务框架，分布式事务等构建金融相关应用所需的基本服务框架，整体的构建过程也比较清晰明了，便于用户的快速入手。在最后环节的分布式事务演示中可以看到，基于自动模式的分布式事务对业务的改造量非常的小，基本可以说是没有侵入性，非常适合需要低成本快速接入分布式事务来保证业务的一致性，同时对TPS以及并发要求不高的业务场景使用。

北京云栖大会Tech Insight Workshop：《用分布式事务中间件来保障金融级交易系统的一致性》篇...