分布式交易系统架构实践-优化银行信息系统架构

支付宝是业界第三方支付领域很有代表性的分布式交易系统。为提升并行计算能力，支付宝绝大部分系统和数据架构都是按照分布式可伸缩架构进行设计的。截至目前，已完成所有核心系统和数据库的可伸缩性设计，从集中式的小型机和高端存储升级到分布式PC服务解决方案，做到无厂商依赖，标准化的分布式架构建设。主旨思路如下：

按照业务类型进行垂直拆分SOA化处理，如交易、支付、账务等核心业务分而治之；应用程序无状态，支持水平无限拓展；对某个业务单元再按照客户请求进行水平拆分，业务自治领域实现动态可伸缩；对于读远远大于写的业务进行读写分离和数据复制处理，最低成本的实现并行处理；对于涉及多个数据的业务，采用分布式柔性事物保障数据一致性；对于复杂架构能力可自动化评估与识别，可高效构建并自检并行处理能力。

1.SOA化架构

由于业务场景急剧丰富，一个金融系统服务能力往往不止一个应用提供，而是由成百上千个应用协同服务，不仅要考虑到商业逻辑代码单元的可维护性、可扩展性，同时应用系统在分业务单元构建过程中，对应的应用服务器集群规模也在极速扩容，这也加剧了单库连接数的上升，单机数据库的CPU、内存、存储空间等资源也逐步出现瓶颈。

与传统金融架构不同的是，支付宝在构建高内聚、低耦合、分层管理的应用系统架构的同时，也对数据按照业务单元进行了SOA化，让业务本身从应用到数据都可以做到闭包管理（见图5-55），很好地展现了SOA化的过程，数据独立管控，应用之间通过简单、精确定义的服务接口进行交互，从而达到对核心业务也能自由伸缩扩展、自由运维、自由发布。

图5-55 SOA化架构

2.水平可扩展的数据结构

IT系统一般是流水型和信息型业务，金融系统除此之外还增加了状态型账务业务，蚂蚁金服根据业务类型不同，定义了不同的数据处理策略。

（1）流水型交易业务 2014年双十一当天每秒钟产生的交易为42561笔，支付15311笔，用户在网上的每一笔交易都会产生大量数据记录，交易数据库不仅需要处理大量的SQL，且每笔交易都需要在百毫秒完成，这对交易这种流水型系统的应用和数据架构设计有非常大的挑战。

图5-56所展现了流水型交易业务的可伸缩性架构设计，根据不同的用户需求拆分了三大数据集群：

1）主交易数据库集群：每一笔交易创建和状态的修改首先在这里完成，产生的变更再通过可靠数据复制中心复制到其他两个数据库集群“消费记录数据库集群”和“商户查询数据库集群”。该数据库集群的数据被水平拆分成多份，为了保证可伸缩性和高可靠性，每一个节点都会有与之对应的备用节点和failover节点，在出现故障时可在秒级内切换到failover节点。

2）消费记录数据库集群：提供消费者更好的用户体验和需求。

3）商户查询数据库集群：提供商户更好的用户体验和需求。

（2）信息型业务 信息型业务系统的读请求远大于写请求，比如会员信息系统。蚂蚁金服所有会员信息只有一份主数据源数据，整体做读写分离，由读库（数据库）直接向外提供查询服务；而对于数据库本身复制存在网络开销，则通过分布式缓存架构来解决业务所需的一致性，如图5-57所示。

图5-56 流水型交易业务的可伸缩性架构

图5-57 信息型业务系统

1）会员核心系统服务器仅访问同数据中心全量数据的分布式缓存。这样当缓存服务器不可用时，影响范围有限，且可将影响到的系统临时切换到其他IDC的分布式缓存集群上。

2）变更只在一个数据库中进行，提交后同步给其他分布式缓存集群。账户信息的变更量小，将变更集中在一个逻辑应用集群访问单点数据主库，变更数据库主库记录。事务提交后同步数据到各IDC的分布式缓存集群中，同城IDC的数据时效性延迟在3ms左右，异地IDC的数据时效性延迟在30ms左右，因账户信息不涉及资金金额，业务可接收该延迟。

通过在账户信息变更时在数据库同事务中保留一致性流水记录，基于时间版本规避数据乱序，应用层通过异步复制和定时调度2种机制驱动账户信息在各数据中心、各城市的数据版本最终一致。(www.xing528.com)

3）交易数据弹性扩容。对于分拆出来的各个数据节点，为了保证对上层应用系统的透明，通过数据中间产品（分布式数据访问层）来保证交易数据做到弹性的扩容。

（3）状态型账务 对于状态型账务业务水平拆分方案也大致相同，只不过一笔转账业务会涉及多个借贷方，多个借贷方的数据一致性问题在账务系统基于柔性事务处理机制做了一层内部控制。

3.分布式事务保障

针对柔性分布式事务机制一般有以下四种，本章节结合金融IT特性只重点介绍同步分布式事务策略和可靠消息最终一致性策略，如图5-58所示。

图5-58 针对柔性分布式事务机制

（1）同步分布式事务策略 分布式架构下，既要保证事务的原有的ACID（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Dura-bility））特性，还要保证高可用和可伸缩性是非常具有挑战性的。试想用户同时支付了两笔资金，这两笔资金的事务在分布式环境下相互影响，那么如果其中一个笔交易发生资金回滚，另外一笔交易也会受到影响，这种情况对用户是难以接受的。

根据CAP和BASE原则，再结合蚂蚁金服系统在线实效性特点，设计了一套基于服务层面的分布式事务框架，支持两阶段提交协议，但是做了很多的优化，在保证事务的ACID原则的前提下，确保事务的最终的一致性。

与传统金融行业的两阶段提交协议（2PC）比较，同步分布式事务模型具有以下优点：没有单独的准备阶段，降低协议成本；系统故障容忍度高，恢复简单。

图5-59为分布式事务框架的流程图，核心思想是：一个完整的业务活动由一个主业务服务与若干从业务服务参与者组成；主业务服务负责发起并完成整个业务活动；从业务服务参与者提供TCC型业务操作；业务活动管理器即分布式事务总控者控制业务活动的一致性，它登记业务活动中的操作，并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作。

（2）可靠消息最终一致性策略 图5-60为可靠消息最终一致性策略流程图。

1）若在第2、3、4步出现故障，业务系统自行决定回滚还是另起补偿机制；若在第6、7步出现异常，消息中心需要回查生产者；若在第8步出现异常，消息中心需要重试。第6步的确认消息由消息中心组件封装，应用系统无须感知。

2）此套机制保障了消息数据的完整性，进而保障了与通过异步可靠消息通信的系统数据最终一致性。

3）某些业务的前置检查，需要消息中心提供指定条件回查机制。

目前支付宝交易、支付、账务等核心业务数据都采用可靠消息最终一致策略在传播。

总之，并行计算能力对高并发、海量数据处理的金融IT系统来说挑战特别大，支付宝通过SOA化、柔性事务、分库分表、读写分离、流量管控与检测等技术框架改造，构造了一部低成本，线性可伸缩，分布式的架构演变史。

图5-59 分布式事务框架的流程图

图5-60 可靠消息最终一致性策略流程图