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

总结：

　　　　　　强一致的微服务

　　　　　　oceanbase里面的投票选举以及多中心多地部署

　　　　　　单元化市异地多活的基础。支付宝是异地多活和容灾结合，而容灾的基础也是单元化。基于单元化进行单元的调度、部署、容灾。

　　　　　　混合云架构

　　　　　　

　　　　

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

2017-01-11 阿里金融云

文 / 蚂蚁金服首席技术官 程立

移动互联网、大数据与云计算作为新的基础设施，催生了新的互联网经济，正在推动各行各业的升级。伴随蚂蚁金服在新金融领域的探索，蚂蚁金服技术团队也在金融技术与架构领域不断开拓。从2005 年每秒处理1笔交易到2016 年“双十一”每秒处理12 万笔交易，从单一的支付到覆盖微贷、理财、保险、信用、银行等，通过十多年的探索与实践，我们形成一套包含金融级分布式交易、分布式大数据分析与决策等在内的完整架构与技术体系。

金融级系统的关键目标

 

如果将建造系统比作盖楼的话，建一个常规的系统要先立稳四根柱子：高可用、安全、性能、成本。但要建一个移动互联网时代的金融级大厦，除了上述四根柱子需要更加牢固，还需要加上两根柱子：资金安全与数据质量。这六根柱子，是我们在架构蚂蚁金服的每一个系统时的首要目标。

具体来说，我们对金融级系统有以下关键目标。

高可用：具备99.99% 以上的高可用性。系统能够容忍各种软硬件设施的故障，可以在服务不中断的情况下进行升级，在严苛的应用场景下保证承诺的服务质量，容忍各种人为失误。对于关键系统，还需要具备异地容灾能力。

安全：具备多层次检测、感知与防御各类安全攻击的能力。系统有能力实时、精细地分析系统行为与数据流发现异常，必要时可以快速调集资源阻断大规模、有组织的攻击。

性能：对于实时交易业务，要求极快的响应时间与极高并发能力。对于批量业务，要求极大的吞吐量。尤其重要的是，系统必须具备很强的可伸缩性与弹性，在需要时可以快速调集资源应对突发的业务量。

成本：在满足高可用、安全与性能的前提下，成本是一个重要约束。我们将单笔交易的平均处理成本（月交易总笔数/ 月成本）、以及峰值交易的处理成本（每提升1000 交易TPS 需要追加的成本）作为两个关键指标去持续优化。除了必须在基础软硬件与系统关键链路上做极致的优化外，灵活的资源调度与按需伸缩能力是优化成本的关键。

资金安全：这是金融级系统与常规系统的一个关键差异。要做到资金处理绝对不出差错，需要交易与数据具备强一致性，需要在任何故障场景数据不丢不错，需要具备准实时的交易资金核对能力，需要在异常场景下有精细化熔断与快速恢复能力。

数据质量：数据质量是金融服务质量的基础。数据从采集、生成、流转、存储、计算、使用需要经历很多环节，要确保经过这么多环节后，数据依然是准确、完整和及时的，需要系统具备全链路的数据质量管控与治理能力。

金融交易系统是否可以走分布式路线？如何基于分布式的思想与技术达到以上6 个关键目标？接下来，我们就以蚂蚁金服的实践为基础，分享对这个问题的观点。

分布式金融交易架构与技术

 

1. 强一致的微服务：微交易架构。微服务是一种广泛应用的分布式架构。通过将系统分解为单一职责、高内聚、松耦合、独立部署、自主运行的“微“服务，可以极大提升系统的灵活性与扩展能力。但由于每一个微服务是自包含的数据与计算单元，当一个有严格一致性要求的交易，被分布在很多节点上执行时，如何保证数据与服务处理达到金融级的强一致性，成为一个难题。尽管可以用支持分布式事务的数据库或数据中间件来保证数据分布时的一致性，但解决不了当服务分布时的一致性问题。由于分布式事务对资源加锁的时间长、粒度大，也制约了系统的可伸缩性与高可用性。

为了解决这个难题，我们提出一种使微服务具备强一致性的微交易架构。在这种架构中，涉及交易操作的微服务具备事务属性。一个微交易提供三种操作TCC（Try-Confirm-Cancel）， 其中Try 操作负责业务检查与资源预留，Confirm 操作负责实际操作，Cancel 操作负责释放预留的资源。一次完整的交易由一系列微交易的Try 操作组成，如果所有的Try 操作都成功，最终由微交易框架来统一Confirm，否则统一Cancel，从而实现了类似经典两阶段提交协议（2PC）的强一致性。但不同于2PC，微交易架构力求高效与可伸缩。TCC 三个操作都是基于本地事务的短事务，Try 操作只预留必须的业务资源，比如一笔交易涉及10 元钱，仅预留账户中的10 元钱，而不是锁定整个账户，TCC 协议在提交时，也没有单独的Prepare 阶段，将提交协议的成本降到最低。

从2008 年初上线至今，微交易架构已经应用到蚂蚁金服的各种金融业务场景，经历过历次大促高峰考验，证明这套架构与技术的可行性。

分布式事务的协调器如果出现问题怎么办？（人工解决？集群解决？）

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

高性能：数据库的一个显著特征是总数量比较大，但每天变化( 增删改) 的数据只是总数据量的很小一部分。因此OceanBase 将数据划分为基线数据和修改增量。基线数据即数据库在某个时间点的一个快照，存放在每台OceanBase 服务器的硬盘中，修改增量即快照点之后的增删改数据，相对比较小，通常存放在每台OceanBase 服务器的内存中。通过这种方式，使得增删改操作基本都在内存中进行，从而获得接近内存数据库的事务处理性能。

强一致：经典的主库+ 备库方式的数据库，很难兼具高可用与强一致能力。为了解决这个问题，OceanBase 使用多数据副本（>=3）投票协议，对于每个写事务，OceanBase只有在事务日志（redo log）到达超过半数服务器后，才应答客户。这样当少数服务器（例如3 台中的1 台，或者5 台中的2 台）异常时，剩下的服务器至少有一台有事务日志，保证了数据库不因为少数服务器故障而导致数据丢失。

高可用：关键业务的数据库必须达到99.999% 的可用性，服务器故障、机房或网络故障都不能导致数据库不可用。OceanBase 通常由分布于多个机房（3 个或以上）的机群组成，每个机群有完整数据，其中一个机群作为主库对外提供读写服务，其余机群作为备库，接收主库的事务日志和回放日志。当主库故障时，剩下的机群会立刻自动发起投票选举，选出新的主库，新主库从其他机群获得可能存在的最新事务日志并回放，完成后对外提供服务。

目前OceanBase 已经稳定支撑了支付宝的核心交易、支付与账务，支撑了网商银行的核心系统，经历了多次“双十一”的考验，形成了跨机房、跨区域部署的高可用架构，并在日常运行、应急演练和容灾切换中发挥了重要作用。

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

因此，蚂蚁金服没有选择“两地三中心”部署模式，而是实现了异地多活与容灾模式。异地多活与容灾架构的基础是对系统进行单元化。每个单元可以认为是一个缩小规模的、包含从接入网关、应用服务到数据存储的全功能系统。每个单元负责一定比例的数据与用户访问，有以下关键特性。

自包含性：比如用户的一次账户充值交易，涉及的所有计算与数据都在一个单元内完成。

松耦合性：跨单元之间只能进行服务调用，不能直接访问数据库或其他存储。对于一些必须跨单元的交易处理，比如分属于两个不同单元的用户之间的转账交易，跨单元的服务调用次数尽可能少，在业务与用户体验允许的情况下尽量异步处理。这样，即使两个单元之间相距上千公里，也可以容忍跨单元的访问时延。

故障独立性：一个单元内的故障，不会传播到其他单元。

容灾性：单元之间相互备份，确保每个单元在同城和异地都有可在故障期间进行接管的单元。数据在单元间的备份方式，我们以OceanBase 提供的多地多中心强一致方案为主。

通过单元化架构，能够将一个大规模系统分拆成许多个相对独立的小规模系统，每一个单元系统可以部署到任何地区的数据中心，从而实现了灵活的异地多数据中心部署模式。系统的主要伸缩模式变成单元的增减，但一个单元内部的规模与复杂性不变，降低了系统的复杂性。单元之间的故障隔离，降低了软硬件故障的影响面。“活”的单元和跨单元的快速切换能力，使同城异地的容灾处理更为简单高效。

目前，蚂蚁金服的核心系统已经分布在上海、深圳、杭州等多个城市的多个数据中心，核心交易流量分布在各个数据中心，并且可以进行调度与切换。通过异地多活，系统可以在全国范围内任意扩展，服务器资源得到了充分利用，提升了系统应对地区级灾难的能力。

4. 按需伸缩：弹性混合云架构。每年，支付宝系统都要应对“双十一”、新春红包等活动的极高交易量。尽管单元化架构让我们具备应对峰值的能力，但要降低高峰期的资源投入，系统还需具备按需伸缩的能力。

我们解决这个问题的方法是，活动前，在云计算平台上快速申请资源，构建新的单元，部署应用与数据库。然后将流量与数据“弹出”到新的单元，快速提升系统容量。当活动结束后，再将流量与数据“弹回”，释放云计算平台上的资源。通过这种方式，可以大大降低资源采购与运行成本。

弹性操作，需要在流量、数据与资源之间协调一致地操作，尤其是有状态的数据的弹性操作最困难，需要不中断业务，也需要保证数据的一致性。这些操作如果依靠运维人员人工执行会十分复杂低效，需要架构、中间件与管控系统的支持。

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

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

未来展望与期待

 

蚂蚁金服的实践证明了在金融级中间件、数据库和云计算平台的支持下，分布式架构可以完全胜任复杂、高要求的金融级交易，并且给出了一种可供参考的技术架构与实施路线。

未来，蚂蚁金服依然会在金融级分布式架构与技术方面深耕与拓荒。在这一领域，我们给自己提出两个新的重大命题。

其一，如何处理每秒1 亿笔交易。万物互联时代，无处不在的交易终端和无数新的交易场景，会继续带来金融交易量的指数型增长。什么样的架构与技术，可以处理万物互联时代的天量交易，是需要未雨绸缪去攻坚与突破的。

其二，将金融级分布式架构与技术变成“普惠”的云计算服务，为千千万万金融服务机构服务。为了实现这个目标，蚂蚁金服和阿里云共同提出了“蚂云计划”，共建新一代的金融云平台，未来服务全球5 万家金融机构，共创全球化的普惠金融。

本文转载自公众号《金融电子化》