众所周知，2007年的时候，整个淘宝网是一个几百兆字节的WAR包(Java网站应用程序包)，大小功能模块超过200个，在当时淘宝业务几乎每隔几个月就翻倍的高速发展情况下，这样的应用架构给当时有着500多人的淘宝技术团队带来了很大的压力。蚂蚁金服的前身支付宝团队当时也在淘宝里，作为淘宝的支付交易模块。而从2006年底开始，现任蚂蚁金服CTO、时任支付宝第一代架构师程立（花名：鲁肃）就开始思考对于支付宝架构的改造，以适应整个淘宝的架构发展，这就是蚂蚁金服中间件的源起。
从淘宝“大饼一沱”的紧耦合系统中分拆出来的松耦合系统，就只有分布式计算架构可选，而淘宝又是互联网应用，于是就需要创造出一个互联网规模的分布式计算架构，“分布式事务”就是在这个拆分过程中出现的问题。淘宝最初是基于IOE设备，无需考虑事务一致性的问题；而在互联网分布式架构下，由于网络和PC服务器等设备的不可靠，数据不一致问题很容易出现。而支付宝作为金融交易系统，对事务型的状态数据一致性处理以及交易成本的要求更高，这背后就是资金安全：资金处理绝对不出差错，交易与数据具备强一致性，在任何故障场景数据不丢不错。
现任蚂蚁金服数据中间件负责人尹博学（花名：育睿）介绍：蚂蚁金服分布式事务（Distributed Transaction-eXtended，简称 DTX）除了协调数据库的事务之外，还可以协调服务的一致性，是在数据库层之上，从业务层保证不同业务之间的数据一致性——即复杂系统之间的一致性，这就是面向未来的核心金融系统。DTX之所以被称为“黑科技”，是因为自设计之初到现在，无论系统多么复杂、交易规模多么庞大，DTX都能在极短的时间内实现数据的一致性：用户无论在哪里，都可放心、流畅地使用支付宝。
（蚂蚁金服数据中间件负责人育睿）
黑科技到底有多“黑”？
尹博学是在2017年被吸引加入蚂蚁金服，之前他在百度也做着类似的工作，但蚂蚁金服在金融级交易这个领域的规模全球独一无二：蚂蚁金服DTX在分布式架构下做到了交易数据的强一致，是目前唯一在超大规模金融级分布式架构上实战验证过的分布式事务方案。
尹博学强调，“事务”是贯穿于所有的金融交易，而金融级交易的数据一致性是要强保证的。例如，支付宝用户A给支付宝用户B转钱，A减钱、B就必须要同时加上钱，这两个动作必须一起成功或是一起都不成功，而不能成功一半，也就是说不能A减了钱但B没有加上，这就会导致资损。
本质上，金融核心系统中的微服务架构，在进行业务垂直拆分和数据水平拆分后，存在大量的微服务和单元数据库，一个完整金融业务需要调用多个服务和数据库完成。同时，不仅微服务之间需要解决一致性问题，不同系统之间的调用也存在事务边界问题，那么强一致的分布式事务服务就将发挥重要作用。
DTX分布式事务服务能满足复杂场景和高并发的挑战，充分考虑各类异常情况，且具备足够的伸缩性、高并发和高可用性，支持跨机房的事务协调能力。“这一整套的协调方式，虽然不是我们独创，但可以认为蚂蚁金服做到了工程的极致。程立最初设计分布式事务的时候，当时只有BASE是一种相对比较成熟的理论，但能达到蚂蚁金服这个量级的，目前只此一家。除了性能和吞吐之外，还要衡量考虑扩展性。集中式架构下用DB2或者Oracle架构，可以从1万个事务提到10万个事务，但是从10万提到200万就几乎不可能；蚂蚁金服可从200万变到2000万，甚至更高，而且成本低。”尹博学表示。
DTX黑科技的亮点很多，其中包括：大规模、高扩展、高性能、低成本等。2017年，DTX支持了双十一峰值25.6万TPS的支付请求；涉及支付、转账、理财、保险等各种业务场景；在支付宝内部，接入DTX的系统超过100＋个；每天处理资金以千亿记，确保资金的绝对安全；按照双活可扩展设计，不受地域、机房等限制，无限加PC服务器等机器就能水平无限扩展；而当出现故障的时候，可很快恢复。整个过程，从始自终，都绝对保证资金安全。
从方法论上保证强一致
2007开始支付宝核心开始SOA服务化之路，服务化拆分一开始就遇到了跨服务分布式事务问题。传统的基于数据库本地事务的解决方案，只能保障单个服务的一次处理具备原子性（一次事务中所涉及的所有操作全部执行或全部不执行）、隔离性、一致性与持久性，但无法保障多个分布服务间处理的一致性。由于业务约束（如红包不符合使用条件、账户余额不足等）、系统故障（如网络或系统超时或中断、数据库约束不满足等），都可能造成服务处理过程在任何一步无法继续。一旦数据不一致，就会产生严重的业务后果。
传统分布式事务需保证ACID属性，强调一致性，要求强一致；而BASE则是与之相对立的理论，认为为了可用性（Availability）而牺牲部分一致性（Consistency）可以显著的提升系统的可伸缩性，这就是异步操作。蚂蚁金服分布式事务产品DTX分别基于两种理论实现了两种模式：基于BASE理论的TCC模式和基于ACID理论的FMT模式。
TCC方案其实是两阶段提交的一种改进，将整个业务逻辑的每个分支分成了Try、Confirm、Cancel三个操作，其中Try部分完成业务的准备工作、Confirm部分完成业务的提交、Cancel部分完成事务的回滚。这三步仅仅是方法论，具体在每一步的操作实现，则由所涉及的服务自行设计代码实现。以简单的A向B转账为例，A加钱与B减钱的操作由两个参与方服务来实现，A和B的两个Try会同时进行业务系统检测和资源预留，只有两个Try都成功了才会往下进行Confirm操作以提交金额的增减。对于复杂的操作，还会在一个分布式事务里嵌套多层参与方，只有每层的Try都成功了，才会完成整个分布式事务的第一阶段，中间一旦任何一层失败都会回滚。
为了解决 TCC 模式的易用性问题，蚂蚁分布式事务后来又推出了框架托管模式（Framework-managed transactions，简称 FMT）。FMT是一种无侵入的分布式事务解决方案，该模式解决了分布式事务的易用性问题，在该模式下，开发者只需关注一阶段操作，框架会自动解析SQL语义，生成二阶段提交和回滚操作，使分布式事务的接入更便捷，该模式下对业务代码几乎无侵入，框架能够“自动化”地解决分布式架构下的数据一致性问题。
“DTX本身是有嵌套的，如果调了一个服务，可能它下面还调用了其它服务，也是分布式的，从而形成多级复杂嵌套。DTX是一个方法论级的保证，不管分多少级，只要层层提交成功了，最终就都能成功提交。”尹博学介绍。DTX本身带有实时监控，可以监控实时的事务信息，包括事务数、成功率、平均耗时等，也可以与链路监控相结合，根据DTX上报的实时信息，提供历史趋势图、同比/环比分析、报警等功能。
这样的DTX就能够保证每年的双十一支付峰值。2017年的支付峰值25.6万笔/秒，相当于200万个分支事务，也就是这200万分支事务都要达到最终一致状态。在峰值的那几秒钟，DTX每秒钟要维护200万分支子事务，监控它们的状态运行，要保证达到最终的一致性；如果200万个分支事务里面发现不一致，就要快速处理。支付宝双十一大促的交易笔数和峰值每年都在以惊人速度大幅增长，蚂蚁金服所面临的极端技术挑战——如何支撑如此大规模交易并保证一致性问题，在全球范围来看都不曾有企业实现过。
如今，整个DTX团队规模并不算大，那又是怎么实现25.6万笔/秒的世界级工程呢？
在阿里集团工作了8年的郎晓东（花名：冰魂）介绍：极致工程主要是靠异步化来实现，也就是延迟提交。在延迟提交的情况下，数据还是对的，不阻碍交易流程，这就叫异步化。也就是说，在极限峰值的情况下，支付宝能向淘宝的请求发出Confirm，保证虽然现在没执行但5分钟之后一定会执行，那么淘宝就可以放心地告诉用户购买成功了。因为双十一大促的最高峰值通常持续时间不长，那么在洪峰之后，稍有喘息就可以释放IT资源来处理“蓄洪”那部分操作。“异步只是在极限情况下采用，双十一零点一过，又是同步了。异步主要是针对成本，如果多加几倍的机器，也可以做到同步，但用户体验要同成本效益达到最佳平衡，又要保证资金安全，因此就开发出了异步的模式。”郎晓东表示，异步模式让DTX具有极强的可扩展性，交易量翻多少倍都可以支持。
当然，处理200万个分支事务/秒的峰值，在搜索等其它非互联网金融领域也是有互联网公司能达到这样的规模，但是要求的严格性不一样。尹博学介绍，协调参与方多的时候，出错的概率就高，一般架构的网站对严格性的要求并不强，数据不一致也问题不大，或者数据最终达到一致性但时间较长也无所谓。但蚂蚁金服属于金融业务，就必须要在高性能、低成本的前提下达到数据的强一致。
用软件保证强一致
“总结蚂蚁金服DTX在工程上的卓越性：首先就是能处理支付峰值200万分支事务；其次是大规模互联网分布式架构；第三，在数据分布设计上采用了抵近存储，也就是让数据靠近业务，再通过批量技术来处理，以减少交互开销、提升整体吞吐性。最重要的就是DTX是通过软件实现分布式，保证处理能力的线性与水平扩展，没有单点、消除单点。”尹博学强调。
所谓用软件实现分布式，即不依赖底层的硬件，默认底层的硬件随时会挂掉。而对于DTX来说，还是在最高的业务层实现的强一致，这就意味着甚至默认底层的数据库也可以随时挂掉。
早年间，淘宝还采用的是Oracle数据库、MySQL开源数据，后来又开发出了自研数据库OceanBase。OceanBase（以下简称OB）金融级分布式关系型数据库也是蚂蚁金服的“黑科技”之一，让用户像使用单机数据库一样方便的使用OB，同时提供更高的性能与更好的服务稳定性等。
DTX的强一致与OB的强一致，有什么区别呢？比如有一张用户表，这张用户表大到单机存不下，那么就在OB里存了两台机器，例如是M1和M2两台机器。一个事务既要操作M1上的一行数据，同时又要操作M2上的一行数据，那么这个事务的一致性是由OB来保证。但在蚂蚁金服架构里还有一张更大用户表，会被拆成25张用户表，这25张用户表中的每张可能“塞”到一个OB集群里，从业务的角度要操作跨两个OB集群的事务，这就是DTX来实现。
DTX主要定位于用户视角的跨库访问，包括单服务、跨服务协调底层多存储资源，支持多种底层数据库，包括MySQL、Oracle、OB等。
对于DTX来说，这些下一层的数据库，也被视为“硬件”。比如OB会认为磁盘属于比较慢的硬件系统，而DTX也同样会极力优化下层数据操作的总体执行性能，因为要考虑到网络延时，这样DTX就会把一次操作的多条SQL语句同时发给OB而不是顺序发送，从而大幅提高单线程的处理能力。简单理解，就是DTX作为处于最高业务层的强一致性方法，统领下面各层资源，在每一层都进行极致优化，从而达到整个DTX操作的最优化。“我们只能把软件当成硬件来优化，一般的公司也不需要优化，因为也抠不到那么细。”尹博学强调。
“没有最大，只有更大”
在谈到来蚂蚁金服一年多的体验，尹博学说这就是不断突破对于“大”的认知。
“在蚂蚁金服场景下，会突破对原有理论的认识，升华到另一个境界。在这么大的交易量下，很简单的问题会变得很复杂。因为你没有在这么‘大’的场景下思考问题，你想当成认为理论就应该是这样。但当遇到这么大的交易量，会发现要考虑的很复杂。当你经历过了这么大的交易量，再用理论总结这个复杂问题时，发现它又会变得比较简单。这是一个认识的深化，原来没想到过这么大的场景、这么大交易量下的主要矛盾是什么，发现了以后又变简单了。”这是尹博学的感觉。
峰值达到每秒25.6万笔、一天要生成几十亿笔交易的订单号，这个“天量”已经突破了所有现有技术的极限，那么解决“天量”规模背后的技术思想就是把同步事情变成提前做或延后做，“抓住这个思想，就会发现又变得简单了，当然前提是要保证提前做或者延后做都是对的”。
DTX的对外输出
如今，DTX技术在对外输出的过程，又变得简单了起来。张森（花名：绍辉）于2011年加入淘宝，于2015年转到蚂蚁金服，之后一直在中间件SOFA团队，主要从事数据中间件分布式事务。
张森介绍，蚂蚁金服的分布式事务有两个名字：对内叫XTS，ExtendedTransaction Service可扩展事务服务；对外叫DTX，Distributed Transaction-eXtended分布式事务。2016年张森负责开发了分布式事务后台运维的自动化，2017年分布式事务产品又开发了可托管版本：FMT，该模式主要是解决用户接入和使用DTX的效率问题，让用户可以基本无侵入的方式下解决分布式事务问题。2018年蚂蚁金服将推出第三代分布式事务解决方案，也就是XA(eXtended Architecture)模式，全面支持标准XA协议，覆盖面广，可无缝接入支持XA的数据库、消息等，帮助传统业务上云，并与自研数据库OceanBase共同打造实时数据一致性的整体解决方案。
蚂蚁金服的技术在2014年开始向生态伙伴和关联机构输出（比如网商银行、天弘基金、Paytm等）
在2017年，南京银行成为了首个国内银行机构客户。在南京银行互联网金融平台项目中，蚂蚁金融级分布式架构解决方案作为一个整体输出，而SOFA中间件包括DTX作为其中非常重要的一部分在项目中落地。2014年是蚂蚁金融科技元年，为了更好的支持网商银行的长远发展，在架构设计初期网商银行架构组就选型DTX做为分布式事务的解决方案。
总结DTX对外输出的优势：第一，相比竞争对手而言，DTX覆盖的金融业务种类是最广的，因为蚂蚁金服是全金融场景，包括了支付、理财、银行、保险等；第二，经过大流量检验过，成就了极致的工程实现；第三，理论发展较快，比如业界其它厂商还停留在TCC模式下，蚂蚁金服已经针对云上的新需求提出FMT、XA等模式，大幅度减少接入的复杂性，并能与蚂蚁金服自研的分布式关系型数据库OceanBase 共同打造实时数据一致性的整体解决方案；第四，金融级解决方案，通过专业的架构转型咨询和实施交付服务，使蚂蚁金服沉淀多年的工程实践精粹与行业落地能力能够结合用户自身的场景进行打通和赋能，为金融机构架构转型带来推动作用，同时也将开放场景定制化能力、大促保障等业务内容，为用户进行量身定制打造最佳方案，为金融机构数字化转型保驾护航。
回顾蚂蚁金服SOFA DTX最近十年的发展过程，简单讲就是一个不断求解金融场景超大规模交易量下分布式架构设计的问题及其工程实现，以优异的性能保障业务数据的一致性，支撑数亿级用户的资金操作。支付宝/蚂蚁金服用十四年时间成就了8.7亿全球用户（2018年5月数据，包括支付宝及其全球合资伙伴）、小微企业与金融机构的普惠金融梦想。“为世界带来更多平等的机会”，一个更加包容、更加可持续、更加绿色的数字金融——这才是蚂蚁金服SOFA DTX分布式事务的黑科技之道。（文/宁川）