刷一笔支付宝背后需要多少系统支持？蚂蚁金服技术大牛分享

二维码支付已经成了国内移动支付主流。谁都可以拿出手机，轻松地扫码，买一瓶矿泉水，或者一份早点。扫码支付的整个过程看似简单，其实背后有需要极高的服务能力支持。

2017年朗迪中国峰会期间，蚂蚁金服首席技术架构师胡喜，蚂蚁金服人工智能部技术总监盛子夏，蚂蚁金服基础技术部技术总监杨冰，蚂蚁金服微贷事业部技术总监沈孝栋出现在现场。四位技术大牛各自做了主题演讲，从不同角度讲解了蚂蚁金服技术部门鲜为人知的工作经验。四位从演讲内容不仅有“秀肌肉”和“谈梦想”，也有蚂蚁金服技术积累经验和技术发展历史回顾。

习以为常的扫码支付背后：挑战巨大

把一次扫码支付拆开来看。

每个人在支付宝都有一个ID，ID作为用户唯一的标识符，在请求进入蚂蚁金服的数据系统之前，先识别出用户身份。

为了保证扫码支付正常运营，在做支付处理之前，蚂蚁金服要先做风险决策，判断用户到底是好人还是坏人，并且通过一些规则，来决定此次交易是否正常。例如一部手机上午在北京，下午突然到美国，系统就应该限制交易发生。

在交易过程中，必须关注一致性问题：一边的钱被扣了，另一边的钱是不是真的加上了？如果一笔支付的资金来源是分别从几个账户里扣，能不能保证所有账户要么都成功，要么都失败？

在有些场景下，客户的交易完成后，蚂蚁金服可能还会对商户收取一笔费用，或产生短信通知。这些事情也很重要。

交易完以后，支付宝可能会发优惠券或商家代金券奖励。支付过程中，根据场景、具体的信息，蚂蚁金服需要快速的运营决策。比如在一个CBD区域里，都是比较高端的人士，买的东西价格都是成千上万，这个地域推送一两块钱的优惠券没有意义；但如果是在菜市场，很多都是大爷大妈日常的消费，突然出现一个一百块钱的红包，对商家营销而言又非常浪费。

系统必须在极短的时间内作出决策。假设一次交易在500毫秒内完成，它的过程中风险决策、运营决策，只能消耗更短的时间。

决策的规则要随着市场变化演进，必须支持快速更新，每天更新，甚至是实时更新，就像黑客的攻防演练一样。

支付宝必须稳定，系统如果停十分钟，可能会带来非常大的影响。

用户的钱不能因为各种天灾人祸而出现差错，数据突然消失将会产生不能接受的严重后果。

上述一切服务的成本越低越好。最大的挑战来自庞大的用户量：

蚂蚁金服在全球有大约6亿的实名注册用户。在2010年首次“双十一”活动中，系统的处理规模是每秒钟500笔；到了2016年的“双十一”，这一交易量已经到了每秒钟12万笔，增长超过200倍。今年的双十一交易处理量可能会达到每秒钟30万笔。

除了支付功能之外，蚂蚁金服还涉足其他金融服务。例如余额宝，目前已经拥有1.43万亿的金额体量，超越了中国第五大银行招商银行2016年年末的个人存款余额。

以花呗信用支付产品作为主打的信用生活平台，服务客户超过1亿。借呗产品从2016年初开始进入大众视野，到现在为止累计服务客户1000万。

支付功能涉及到金融服务后，业务会对系统提出更高要求，包括大量的专业报表、分析需求，同时还需要非常实时地对数据进行诊断，在蚂蚁金服的生态中，这意味着需要在“秒”级时间单位里处理EB级规模的数据。

金融级大规模交易难题破解

1.拆分大法

根据蚂蚁金服基础技术部技术总监杨冰的回忆，早期的支付宝只是一个单体的运用，可以被理解为简单的“我的钱包”。随着时间发展，支付宝挂载的功能越来越多。最夸张的时候，整个支付宝系统有52个子模块，随便改动一下都需要涉及大量资源调整，极大地影响了效率。

早期的蚂蚁金服和大多数传统金融机构一样，使用IOE（IBM的小型机、Oracle数据库、EMC存储设备），IOE架构可以轻松解决万级到百万级的数量跃升。但是如果要再往上拓展，就会遇到瓶颈。

为了解决这一系列问题，蚂蚁金服逐渐将支付宝上的各种功能拆开，变成分布式系统。

目前蚂蚁的后台系统，按照金融领域的模型进行了拆分，从服务、数据到IDC三个层面，运用分布式的套路，面对各种数据的要求，设计了读写分离，多点写入的方案，保证了应对巨额吞吐量的能力。

蚂蚁金服现在差不多有将近7~8万台服务器，已经可以在自己的机房里承载大部分日常的流量；面对“双十一”等高峰时期，还可以动用弹性扩展能力，从阿里云的“公有云”上把计算和存储资源补充进来。

为了决定用户的数据应该在哪个机房处理，蚂蚁金服把包括服务注册中心在内的系统做到了每个机房里，在每个机房里都形成了一套独立体系；所有数据的应用服务动作都可以在一个独立单元里完成。这样就可以保证当容量出现问题的时候，能以整个服务为单元进行机房扩容。初步有了系统的机房级伸缩能力。

分布式系统的另一个好处是成本较低，通过多年技术革新，支付宝的交易成本已经从原来的5分钱以上逐渐下降到2016年的2.2分左右。2017上半年，支付宝交易成本进一步降低到1.7分，未来也有望降到1分钱以下。

2.多副本数据

蚂蚁金服的数据不同于传统的数据库的主备理念，而是采用了多副本的设计。

为了平衡好数据安全和数据效率之间的关系。支付宝利用Ocean Base的部署模式，在多地部署了数据库的节点。在每次写入过程中，数据都会被同步到多个层次的多个副本，只要有超过多数的副本成功，它就会成功。

以最基本的三副本为例： 把“789”这个数字存入数据库，在蚂蚁金服的数据库设计中，只要让7这个数字在三个副本里都有出现，8和9这个两数字在某两个副本里出现——最后整个体系能从多数派的副本中整合出“789”的记录，就可以返回写入数据成功。

这样的设计可以大大提高系统的效率，既保证了最大的可用性，又优化了用户的请求响应。如果有某一个数据副本没有同步，则可以通过异步的机制，最终保证数据的一致性。

三个副本都出现问题的概率很低，具有初级的备灾能力。同时，因为上面的可伸缩能力，任何一个副本出现问题，数据库也可以进行随意切换。即便整个城市出现问题，都可以切换到另外一个城市，保证数据不丢。

3.两阶段同步

采用了分布式事务解决方案后，蚂蚁金服通过两阶段提交机制，保证整个过程中的信息最终是一致、高效的。

在蚂蚁金服的系统设计中，面对大量个人用户的请求处理，交易数据的持久化、流程引擎、资金处理等模块都是同步处理；交易收费、商户通知、营销，则是通过异步的消息队列完成。

在不同的处理阶段，会有独立的资源“锁住”的过程，如果大家都成功，整个体系才能驱动第二阶段，往前推进。

支付宝一笔扫码业务看似简单，背后有着全套的技术流程支持。只不过这些技术能力完全整合在支付过程中，用户很少会感觉受到打扰。整个体系是无感知的情况下帮助用户完成支付。

金融创新的背后绕不过基础设施升级。2015年，蚂蚁金服对外提出了互联网推进器计划，希望把技术能力开放出来。蚂蚁金服的CEO井贤栋也曾在公开场合表示，蚂蚁金服是一家Techfin而非Fintech公司。2017年，蚂蚁金服更是高调宣布未来只做Tech（技术），帮金融机构做好Fin（金融）；不会做自己的金融产品，将向金融机构全面开放平台。

蚂蚁重新聚焦定位后，未来我们也许会看到更多的金融机构、消费者能够享受这样的能力。