程立 蚂蚁金服CTO程立：金融级分布式交易的技术路径

相关阅读:

正文/蚂蚁金服首席技术官李成

作为新的基础设施，移动互联网、大数据和云计算催生了新的互联网经济，并正在推动各行各业的升级。随着蚂蚁金服在新金融领域的探索，蚂蚁金服的技术团队一直在金融技术和架构领域发展。从2005年每秒处理一笔交易到2016年每秒处理12万笔交易，从单笔支付到覆盖小额贷款、理财、保险、信贷、银行等。经过十多年的探索和实践，我们已经形成了一个完整的框架和技术体系，包括财务级分布式事务、分布式大数据分析和决策等。

财务等级制度的主要目标

如果把建筑系统比作盖楼，应该建立四个支柱来建立一个常规系统:高可用性、安全性、性能和成本。但要在移动互联网时代打造金融级建筑，除了以上四大支柱，还需要增加两大支柱:资金安全和数据质量。这六大支柱是我们构建蚂蚁金服各项体系的首要目标。

具体来说，我们的金融体系有以下主要目标。

高可用性:99.99%以上的高可用性。该系统可以容忍各种硬件和软件设施的故障，不中断服务地升级，保证承诺的服务质量，并容忍恶劣应用场景中的各种人为错误。对于关键系统，也需要异地容灾。

安全性:多层次检测、感知和防御各种安全攻击的能力。系统具有实时准确分析系统行为和数据流，发现异常的能力，必要时可以快速调动资源，拦截大规模、有组织的攻击。

性能:对于实时事务业务，需要极快的响应时间和极高的并发性。对于批量业务，需要很大的吞吐量。尤其重要的是，系统必须具有很强的可扩展性和灵活性，能够在需要时快速调动资源处理突发的业务量。

成本:在高可用性、安全性和性能的前提下，成本是一个重要的约束条件。我们将单笔交易的平均处理成本(每月交易总数/月成本)和高峰交易的处理成本(每1000次TPS升级的额外成本)作为持续优化的两个关键指标。除了基础软硬件和系统关键环节的极端优化外，灵活的资源调度和按需可扩展性是优化成本的关键。

资金安全:这是金融体系和常规体系的一个关键区别。为了确保资金处理绝对没有错误，需要交易和数据具有很强的一致性，在任何故障场景下都不会丢失好的数据，具有准实时交易资金检查能力，在异常场景下具有精细融合和快速恢复能力。

数据质量:数据质量是金融服务质量的基础。数据采集、生成、流通、存储、计算、使用等环节很多。为了确保经过这么多环节后的数据仍然准确、完整、及时，系统需要在整个环节进行数据质量控制和治理的能力。

金融交易系统可以走分布式路线吗？基于分布式思想和技术如何实现以上六个关键目标？接下来结合蚂蚁金服的实践，就这个问题分享一下我们的看法。

分布式金融交易体系结构和技术

1.强大且一致的微服务:微交易架构。微服务是一种广泛使用的分布式体系结构。通过将系统分解为单一责任、高内聚、松耦合、独立部署、自主运行的“微”服务，可以大大提高系统的灵活性和可扩展性。然而，由于每个微服务都是一个独立的数据和计算单元，当一个具有严格一致性要求的事务在多个节点上分布和执行时，如何确保数据和服务处理在财务层面上实现强一致性成为一个难题。虽然支持分布式事务的数据库或数据中间件可以保证数据分发的一致性，但不能解决服务分发时的一致性问题。由于分布式事务锁定资源的时间长、粒度大，也制约了系统的可扩展性和高可用性。

为了解决这个问题，我们提出了一种微事务架构，使微服务具有很强的一致性。在这种体系结构中，事务操作中涉及的微服务具有事务属性。一个微交易提供三个操作TCC(Try-Confirm-Cancel)，其中Try操作负责业务检查和资源预留，Confirm操作负责实际操作，Cancel操作负责释放预留资源。一个完整的事务由微事务中的一系列Try操作组成。如果所有的Try操作都成功，那么微事务框架将最终统一Confirm，否则取消，从而实现类似于经典两阶段提交协议(2PC)的强一致性。然而，与2PC不同的是，微交易体系结构追求高效率和可扩展性。TCC的三个操作都是基于本地交易的短交易。试运行只保留必要的业务资源。比如一笔交易涉及10元钱，只预留账户中的10元钱，而不是锁定整个账户。提交TCC协议时，没有单独的准备阶段，这可以最大限度地降低提交协议的成本。

自2008年初推出以来，微交易架构已应用于蚂蚁金服的各种金融业务场景，并经历了之前所有推广巅峰的测试，证明了该架构和技术的可行性。

2.金融级分布式数据库:OceanBase。目前主要的商用数据库本质上都是单机系统，其容量、性能和可靠性都依赖于单个或少数高性能服务器和高可靠性存储的组合，成本高，难以扩展。虽然使用微事务架构可以将数据操作的压力拆分到多个数据库中，解决了横向可扩展性的问题，但是数据库本身的性能、成本和可靠性仍然是一个难点。因此，阿里巴巴和蚂蚁金服从2010年开始开发专门的金融级分布式数据库OceanBase。OceanBase在以下几个方面对传统数据库架构进行了突破。

高性能:数据库的一个显著特点是总量比较大，但是每天变化的数据(添加、删除、修改)只是数据总量的一小部分。因此，OceanBase将数据分为基线数据和修改增量。基线数据是数据库在某个时间点的快照，存储在每台OceanBase服务器的硬盘上。修改增量是快照点后的添加、删除和修改数据，相对较小，通常存储在每个OceanBase服务器的内存中。这样，添加、删除、修改等操作基本都在内存中进行，从而获得接近内存数据库的事务性能。

强一致性:经典的主数据库+备用数据库很难同时具备高可用性和强一致性。为了解决这个问题，OceanBase使用多个数据副本(>:=3)投票协议。对于每个写事务，OceanBase只会在事务日志(重做日志)到达一半以上的服务器后才回答客户。这样，当少数服务器(例如3个中的1个或5个中的2个)出现异常时，剩余的服务器中至少有一个具有事务日志，这确保了数据库不会因为少数服务器的故障而丢失数据。

高可用性:关键业务的数据库必须达到99.999%的可用性，服务器、机房或网络的故障不能使数据库不可用。OceanBase通常由分布在多个机房(3个或更多)的集群组成，每个集群都有完整的数据，一个集群作为主库提供读写服务，另一个集群作为备份库接收主库的事务日志和回放日志。当主库失败时，剩余的集群将立即自动启动投票来选择新的主库。新的主库将获取其他集群可能存在的最新事务日志并回放，完成后向外界提供服务。

目前，OceanBase已经稳定支持支付宝核心交易、支付、账户，支持网商银行核心系统。经过多次“双十一”测试，形成了跨机房、跨区域部署的高可用架构，在日常运营、应急演练、容灾切换等方面发挥了重要作用。

3.异地多活动与容灾:单元化架构。“两地三中心”是金融系统中广泛使用的跨数据中心扩展和跨区域容灾部署模式，但也存在一些问题:在扩展能力方面，由于跨区域备份中心不承载核心业务，无法解决核心业务跨区域扩展的问题；成本方面，容灾系统仅用于容灾，资源利用率低，成本高；容灾方面，由于容灾系统的冷备份，容灾期间可用性低，切换风险高。

所以蚂蚁金服并没有选择“两地三中心”的部署模式，而是实现了异地多活动、容灾的模式。远程多活动和灾难恢复架构的基础是统一系统。每个单元都可以看作是一个缩小的系统，具有从接入网关、应用服务到数据存储的全部功能。各单位负责一定比例的数据和用户访问，具有以下关键特征。

自包含:例如，当用户给账户充值时，所有涉及的计算和数据都在一个单元中完成。

松耦合:跨单元之间只能进行服务调用，不能直接访问数据库或其他存储。对于一些必须跨单元的事务，如属于两个不同单元的用户之间的转移事务，跨单元服务调用的数量应尽可能少，在业务和用户体验允许的情况下，应尽可能进行异步处理。这样，即使两个单元之间的距离是几千公里，也可以容忍跨单元访问延迟。

故障独立性:一个单元中的故障不会传播到其他单元。

容灾:各单位互相备份，保证每个单位在同一个城市和不同的地方都有单位可以在故障时接管。单元间数据的备份方式主要基于OceanBase提供的多站点多中心强一致性方案。

通过单元化架构，可以将一个大规模系统划分为多个相对独立的小规模系统，每个单元化系统可以部署到任何地区的任何数据中心，从而实现灵活的异地多数据中心部署模式。系统的主要扩展模式变成了单位的增减，但一个单位的规模和复杂度保持不变，降低了系统的复杂度。单元之间的故障隔离减少了软件和硬件故障的影响。“实时”单元和跨单元快速切换的能力使同一城市不同位置的灾难恢复更加简单高效。

目前蚂蚁金服的核心系统已经分布在上海、深圳、杭州等城市的多个数据中心，核心交易流程分布在各个数据中心，可以调度和切换。通过异地多活动，系统可以在全国范围内随意扩展，充分利用服务器资源，提高系统应对区域性灾害的能力。

4.按需扩展:弹性混合云架构。每年支付宝系统都要应对“双十一”、“新年红包”等活动极高的交易量。尽管统一架构使我们能够应对高峰，减少高峰期间的资源投入，但系统需要具备按需扩展的能力。

我们解决这个问题的办法是，在事件发生之前，在云计算平台上快速申请资源，新建单元，部署应用和数据库。然后，流量和数据被“弹出”到新单元，系统容量迅速增加。当活动结束时，流量和数据被“反弹”以释放云计算平台上的资源。这样可以大大降低资源采购和运营的成本。

灵活的操作需要流量、数据和资源之间的协调操作，尤其是有状态数据的灵活操作是最困难的，既需要中断业务，又要保证数据的一致性。这些操作如果由运维人员手动执行，将会非常复杂和低效，需要架构、中间件和管控系统的支持。

灵活的混合云架构和技术在实践中有以下要点:通过统一的资源调度，灵活应用和分配计算、存储和网络资源，创建单元，快速部署数据库、中间件和应用程序；通过中间件，应用和基础设施完全解耦，无论流量、数据、资源如何分布，应用系统都不需要改变；通过分布式架构、数据规范和中间件支持，保证所有请求、服务、数据和消息都具有全局唯一的ID和一致的ID编码规则。根据ID，可以从接入网关、服务中间件、消息中间件和数据中间件中正确路由服务请求和数据访问。通过统一管控平台，将高层的柔性操作转化为各个组件的部署配置指令，统一调度执行，使得操作协调、准确、高效。

基于弹性混合云架构，支付宝在2015年“双十一”期间，有10%的支付流量运行在阿里巴巴云计算平台上。在2016年的“双十一”上，我们计划在阿里巴巴云计算平台上运行50%的高峰支付流量，这将大大优化成本。

未来展望和展望

蚂蚁金服的实践证明，分布式架构在金融中间件、数据库和云计算平台的支持下，完全能够胜任复杂、苛刻的金融交易，并给出了可供参考的技术架构和实现路线。

未来，蚂蚁金服将继续深化和开拓金融级分布式架构和技术。在这个领域，我们为自己提出了两个新的重要命题。

第一，如何处理每秒1亿的事务。在物联网时代，无处不在的交易终端和无数新的交易场景将继续带来金融交易量的指数级增长。什么样的架构和技术才能应对物联网时代的海量交易，需要做好攻击和突破的准备。

第二，金融级分布式架构和技术将转变为“包容性”云计算服务，为千千数千家金融服务机构提供服务。为了实现这一目标，蚂蚁金服和阿里巴巴云共同提出“马云计划”，共同打造新一代金融云平台，未来将服务全球5万家金融机构，打造全球普惠金融。

本文转载自微信官方账号的金融电子化

-结束-

欢迎关注《互联网架构师》。我们分享互联网技术干货上最有价值的文章，帮助你成为一个有思想的全栈架构师。我们只谈互联网，谈建筑，不谈别的！打造最有价值的建筑师圈和社区。

这个微信官方账号覆盖了中国主要首席建筑师、高级建筑师、CTO、技术总监、技术负责人。分享最有价值的建筑理念和内容。打造中国互联网圈最有价值的建筑师圈。

龙按下二维码，迅速跟上我们

如果你想加入一个小组讨论和学习，请点击右下角的“加入小组学习”菜单加入小组。