二维码支付已经成了国内移动支付主流。谁都可以拿出手机,轻松地扫码,买一瓶矿泉水,或者一份早点。扫码支付的整个过程看似简单,其实背后有需要极高的服务能力支持。
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(金融);不会做自己的金融产品,将向金融机构全面开放平台。
蚂蚁重新聚焦定位后,未来我们也许会看到更多的金融机构、消费者能够享受这样的能力。