“天猫双11”支付技术的前世今生：新商业的变革基础

2017-10-31 09:20

“天猫双11”支付技术的前世今生：从人肉云计算到智能化云平台曾经，支付宝离数据库崩溃只剩四秒不受控制的剁手带来快感，也带给技术男爆炸性的挑战。

1“天猫双11”支付技术的前世今生：从人肉云计算到智能化云平台

曾经，支付宝离数据库崩溃只剩四秒

不受控制的剁手带来快感，也带给技术男爆炸性的挑战。

每年的“天猫双11”都会创造不少世界纪录，这些世界纪录的背后是一个个世界级的挑战。在过去9年的双11，蚂蚁金服都在挑战自我中度过。

支付宝刚起步时，技术远没有今天那么受重视，原因很简单，不需要，没必要。在创业之初，2004年时，支付宝还是淘宝中的一个结算部门，淘宝的会计人员用两台电脑和一张 Excel 表就能进行结算。蚂蚁金服向雷锋网AI金融评论表示，那时每天的交易金额是三位数，全天交易笔数只有十几笔，如果分摊到每秒钟，则接近于零。即便是到了2010 年，支付宝每秒钟交易笔数也只有300笔。

但是，2016 年的“天猫双11”时，支付宝的交易峰值飙到了每秒 12 万笔。

在此之前，支付宝也刚完成二代架构的升级改造。在二代架构做完之后，支付宝的技术团队感觉能解决的技术问题都已经解决了很多人认为未来系统也许就可以这样发展下去。

因此在 2010年双11大促之前支付宝的系统规划是按照每年增长100%余量预估的。即系统永远有一倍的余量，按照当时的估测，大家觉得一倍余量一定够用。退一步说，即使出现问题，也可以等到交易量增长到一定程度时再继续增加资源。

因此，当天突如其来的巨大交易量让支付宝的技术团队措手不及。

回忆起当年，2010年11月11日零点刚过，坐在电脑旁边的程立（现任蚂蚁金服首席技术官）突然发现，支付宝的业务量正在快速攀升，一下子高出了平时最高值的三倍。程立清楚，这时系统只有一倍的余量。

刚开始，程立有些侥幸，他觉得大促刚开始时用户最活跃，等白天时情况会慢慢好转起来。然而直到当天早上六七点，业务量还没有降下来，依然是平时的几倍。

这时，支付宝的技术人员开始着急了，大家意识到，当天的交易量一定会远远超出系统的容量。

情急之下，支付宝技术团队开始不停地 “搬资源”。哪里有富余的计算资源就搬过来应急。如核心交易系统容量不足了，就把一些相对不重要的业务资源拿过来，到后来再不够了，就采用“砍业务”的方法，将那些暂时可以牺牲的业务砍掉，再把资源搬过来。

那天，所有开发人员都坐在电脑前，如临大敌般地处理问题: “到底这个机器是否要重启一下? 这个系统容量不够我要不要调一些机器过来? ”

直到当天的23时59分30秒，眼看2010年双11大促就要结束，突然核心账务系统报警。

“嘀、嘀、嘀” 短促清晰的警报声让在场的每个人都打了一个寒战。

“资源马上耗尽！赶紧杀掉非关键应用!”听到报警声后，负责数据库的同事一边冲过来一边大喊。

程立倒吸一口冷气，他清楚可能产生的后果。那时支付宝的账务数据库还没有做拆分，而所有交易都经过虚拟账户，一旦核心账目系统出现问题，支付宝所有的业务都会停掉，数据库再想恢复就需要经过很长的时间。如果出现这种情况，对淘宝和支付宝都将是灾难性的。

急中生智，技术团队决定临时把会计的应用杀掉。回忆起这个惊险的过程时，程立向雷锋网表示，因为当时支付宝的账务应用和会计应用是在一个数据库中，而会计的应用更多，是在交易之后进行，暂时停用还可以恢复过来，这样便可腾出系统的资源，把账务系统的性能提升50%。

情急之下，负责消息系统的几个同学冲上去，争分夺秒地在每台机器上敲上一行行的代码，紧急杀掉非关键应用，确保核心数据库资源。

当敲完最后一行代码，将一个会计系统的应用杀掉，将资源释放出来，离数据库崩溃只剩下四秒。

尽管过程很惊险，不过，2010 年的天猫双11，支付宝全天成功交易1261万笔，平均每分钟有1万笔成功交易。但经过了这次 “大考” 之后，所有人都在反思，以后每年的双11 大促，业务量的增长只会更快，支付宝的系统怎样才能顶得住呢?

事后复盘，当时支付宝的CTO李静明在和技术团队总结时说，对于 2010 年的双11整个团队都是在做 “人肉的云计算”，而系统接下来的改造方向就是使“人肉的云计算”。真正变成“底层系统的云计算”，这正是支付宝系统的第三代架构“云支付”的开始。

金融业系统架构的突破：构建分布式系统

蚂蚁金服介绍，从 2005 年开始，支付宝的技术架构经历了“烟囱型”、“面向服务型”、 “云平台型”三个时期。而从第二代架构到第三代架构转变，蚂蚁金服又做对了一件事——构建分布式系统。这是今天“云支付”的基础。

当时，分布式系统在互联网界的应用并不罕见，规模较大的互联网公司系统都分布化了。但是对于金融系统而言，分布化是没有先例的，这是因为金融系统要求高稳定性和高安全性，任何改进都要先保证用户账目上的钱分毫不差，在系统数据分离之后，保证系统之间业务处理的一致性就成了核心的问题。

“但是，如果使用云计算，系统首先要分布，只有这样才能用很多小型机器、云资源作为支撑。”

“支付宝的第一代架构就像一个个独立的“烟囱”，没有基础架构可言，做一个业务就竖起一个“烟囱”。“烟囱”之间的关联性不大，每做一个新业务就要将一个烟囱，进行手动改造，而支持主要业务的“大烟囱” 经历了无数次的改动。

应该说第一代“烟囱型”的系统较好地满足了小团队开发、业务快速试错的需求。但是这个架构不能支持大团队的分布式研发。在“烟囱型”的技术架构下，每当开发新的产品和功能时，只能允许所有人在一个系统里去写代码。与此同时，它的部署也是集中的，核心系统就是一个集群，数据库也只有一个。因此，随着业务量的上升，这样的数据库和集群都会达到极限。

所以，据雷锋网了解，从2006 年开始，支付宝的技术团队意识到，“烟囱”架构无法支持支付宝未来业务的发展。如果要继续拓展业务，必须先把架构分布化，建立底层服务架构，让专业模块做专业的事情。

2007年初，随着分布式系统技术的逐渐成熟，特别是大规模 SOA 系统中的分布式事务处理标准逐渐明晰。程立就和同事一起，从 2007 年上半年开始准备将支付宝的系统做分布式的改造，现在看来就是把支付宝的架构改成一个分布式服务和分布式架构。

二代架构在支付宝技术发展过程中是很关键的一步。因为新系统将原来的大系统拆开了，在当时这个项目叫作 “交易服务化”，有“交易服务化” 作为基础，后来支付宝又做了账务三期，做完账务三期之后，核心账务系统也分布化了。从 2007 年开始，支付宝陆续用了三年左右的时间对整个系统进行分布化。核心账务可以分布、核心交易也可以分布、所有的业务都可以分开来做。

结果是，支付宝的系统可以伸缩了，每一个系统都是分布式的，如果遇到业务峰值，就可以增加资源。

幸运的是，当支付宝的二代架构做完后不久，淘宝就开始搞双11 大促了。

但二代架构过渡到三代架构的过程并非一帆风顺。在二代架构完成后，虽然支付宝把系统拆开了，但是如何让新业务长在复杂的分布式系统上是一个非常复杂的问题。在业务很多的情况下，系统会变成一张复杂的网。

后来，支付宝技术团队对业务进行了拆分和梳理。比如，系统里有一个支付服务的平台，它的作用是对外提供支付服务。类似地，各类会员服务的系统、运营服务的系统与营销服务的系统也都陆续搭建。

总的来说，第三代云支付架构能够完成两方面的改造。一方面是在底层使用云计算技术，另一方面是在上层把服务变成云服务。这样建立在其上的业务就可以很快地生长。

据雷锋网AI金融评论了解，从二代架构过渡到三代架构这个过程，支付宝又花了三年时间。用程立的话说，如果这个事情做得晚一点，这几年的 “天猫双11”大促就别想挺过来了。也正是这样的转变，让支付宝技术团队在天猫双11之夜，不用再喝红牛了。

不过，蚂蚁金服对此并不满足，现在已经开始研发第四代架构。

从分布式到异地多活

对于支付宝技术来说，2010年是一个拐点，那一年，峰值比此前番了三番。“如果还是用传统型架构，很难满足我们快速的发展，我们分析了整个业界的架构，支付宝遇到的问题，已经不是任何一个现有业界技术可以解决的，我们必须自己去淌出一条解决之道。”胡喜说道。

“在此前一年，我们开始自主研发数据库OceanBase。我们也试着尝试一种新的对策——分布式‘异地多活’的架构。”

这种分布式的架构有一个最核心的设计前提：用最通用的硬件设备（PC服务器），满足我们最小单元计算的要求；用最缜密的软件逻辑，满足金融交易的最高可靠性要求。

胡喜表示，　

这就像是拆掉了高端中央收银台，换成了分散在商场各个角落的无数小型计算器，每台计算器虽然不如单一中央收银台高端厉害，但个个都能记点帐，更重要的是，有一种统筹全局的力量为分散在各处的计算器设计了相互关联的逻辑关系，它们互为补充，互相备份，从全局上保证了运算可靠，因而任何单个计算器的故障，都不会影响整盘生意。这就是这种架构中最核心的云计算能力。

这种努力的成果是显著的，在满足支付宝系统同样稳定的前提下，极大的降低了对于成本的投入。“从2010年开始，我们给自己定的目标是，每年专为双11提供技术保障投入的成本比前一年都降30～50%左右，到2019年，我们将不再花一分钱投到双11当天的技术保障上，也就是说，双11将完全常态化。”

据胡喜介绍，“弹性架构具备在云计算平台上快速伸缩容量的能力，50%流量基于云计算资源弹性伸缩，快速扩充支付容量，从而优化运维成本。理论上我们可以做到每秒百万级的交易支付能力。”

结论：云计算是金融科技实现金融普惠的基础

“天猫双11”应急技术常态化意味着什么呢？如果说上述的一切升级都是针对于双11的挑战性环境，那么，对于一般性行业来说这些技术改进有什么意义？

“金融科技下一版本模型分为四层模型，最下面就是最基础的能力我们叫做BASIC，B代表的是区块链，A代表的是AI，S代表的是安全，I代表的是IoT，C代表的是云计算，我今天讲的很多都是在云计算领域。Cloud是最基础的能力，我们先具备这个能力，你没有强大的计算资源，其他一切都无法进行。”胡喜向雷锋网AI金融评论表示，“未来，蚂蚁向前走的愿景是普惠金融，需要服务更多的消费者和小微企业，需要的计算能力是非常大的，我们要做的就是通过‘双11’把计算能力逐渐锻炼出来。其他基层分别是风控能力，信用能力，连接能力。”

蚂蚁金服是目前世界上体量最大的科技金融公司之一，每一步探索都有实验性质。从支付的视角看蚂蚁金服2007年到2013年的三代系统架构变迁，我们也看到了云计算时代“云平台型”系统架构的逐步成型；除此之外，从分布式架构、异地多活，也看到了国内金融机构基础设施“去IOE”的转向。

2服务的智能升级

因此，遵循这个逻辑我们也可以回顾一下：去年，蚂蚁金服对于天猫双11突出了风控、精准营销等消费金融方面的实力（请看《备战双11，蚂蚁金服准备了这些“重型武器”》）。与此同时，我们也看见了在过去的一年中，蚂蚁金服逐步开放出来的信用评分服务以及风控服务能力。

也就是说，基础技术的爆炸升级，背后也是服务能力的升级。

智能客服“未问先答”：开启主动型客户服务模式

走访了一圈蚂蚁金服Z空间大楼，这里有平日辛勤的淘宝小二。不过，这个杭州服务团队，只有600人左右规模；算上全国外包团队，不过小数千人。而且，蚂蚁金服智能客服负责人子孟说道：“淘宝天猫平台业务量逐年增长，但是，我们的客服没有增加，反而在减少。”

这背后，也是一个技术的进步史。

子孟介绍道，客服分三个阶段：

1.0 查询问答：类目树

更多是查询类的事情，把很多回答的内容做成一个类目数让大家查询，不管在热线电话还是在PC端、APP端，更多让大家自己去查询，导致了大家效率很低，往往找不到准确的答案。

2.0 快捷应答：终端机器问答快速识别

第二阶段，尤其是互联网企业往往采用第二个手段，包括我们也在很多场景下切换到这个情况，就是在传统的查询回答的基础上，快捷应答。
有两个点：一是更多在APP端、PC端用问答机器人方式解决用户问题，通过用户问题可以快速识别什么问题，快速指向到某一个具体答案或者人工；二是在传统的电话过程当中，传统用很多按键模式，但是新一代服务模式去按键化，减少按键输入，更多用语音交互方式。

3.0 未问先答：机器学习模型识别支付场景，预判问题

很多时候我们客服的角色是相对滞后的，要等用户找上门来提出问题，甚至反复不断提出要求才能够回应，我们认为极致服务应该是把事情做到事前，在用户可能遇到问题的时候提前化解他的障碍和疑问。
所以到了第三阶段，由于前一阶段积累了很多数据和用户行为的数据，我们现在希望推出的叫做“未问先答”服务。
在所有服务渠道中，我们不断依据于用户的实时数据，经过学习和分析，怎样让用户没有开口的时候就知道他可能想问什么问题，更快速的解决问题，这是“未问先答”这样一个技术在整个服务中的角色。我们希望这个是作为客户服务3.0的标志性的新客服产品和能力。

大家可以感受一下：

此外，未问先答还有其他的功能，举个例子，用户在app上反复操作在研究一个功能，但是多步操作后还没有成功，那么客服就会自动跳出来，询问是否在某些方面遇到困难，然后给出方案帮助客户解决。

据介绍，经过这样的提前介入服务，在这个节点上有一半以上用户成功修改银行卡的预留手机，可见，智能化的客服对业务效率的提升效果。子孟介绍称，这样的主动性客户服务，每帮助一个用户消除疑虑，就可以增加产品的剁手率。另一方面，上了“未问先答”后，客服重复来电降低减少一半，通过95188来电咨询的比例也减少了一半。

“客服的改进看起来虽然只是一个细节，但它让客户服务完成从被动型服务到主动型服务的改变。”

为海量交易保驾护航

超级会计师OceanBase

上述贴心聪明的智能小二可能给你增加了足够的剁手快感，而支付宝背后的数据库系统更重要的是安全感。

首先，前面已经有介绍，蚂蚁金服通过开发的OceanBase数据库系统，以及升级系统架构，采用三地五中心、异地多活等形式来提升容灾能力，保障系统稳健。最后的结果是，胡喜介绍称，天猫双11中：核心的交易、支付、会员、账务等支付核心链路今年都运行在OceanBase上；另一个是蚂蚁自主研发的新一代弹性架构，能够利用全国多个城市的云计算资源。“所以，12万笔／秒的支付峰值，是2015年的1.4倍，也毫无压力。”

通俗的说，OceanBase是一个海量数据库，可以存放千亿条以上的记录。它就像一位超级会计师，单台普通的服务器每秒可以处理百万笔事务，平均一次花的时间是毫秒级别。
三地五中心，主库突发故障，或者任何一个甚至两个机房同时断电、断网，或者任何一个城市故障，业务都会在极短时间内自动恢复，不需要任何形式的人工对账。