天猫 11·11：蚂蚁金服如何用小团队支撑数亿人买买买？

又到了一年一度的“天猫双 11”，外行看热闹（剁手），内行看门道（技术）。每年“天猫双 11”都会创造不少与“交易量”相关的世界纪录，而这些世界纪录的背后则有改变世界的技术作支撑。

由 InfoQ 举办的 ArchSummit 全球架构师峰会即将于 12 月 8-11 日北京举行，大会与阿里巴巴合作策划了双 11 架构专场，并邀请了顶级技术专家担任出品人，设置了“新一代 DevOps”、“人工智能与业务应用”、“架构升级与优化”等 17 个热门话题，目前大会日程已出，欢迎前来讨论交流。

下面这张图，记录了支付宝历年双11 的峰值交易数据。

从2010 年的每秒300 笔，到2016 年的每秒12 万笔，交易笔数提升的背后，是蚂蚁金服技术能力被“逼”着快速升级。

从人肉云计算到智能化云平台

曾经支付宝距离数据库崩溃仅剩4 秒

支付宝刚起步时，技术远没有今天那么受重视，原因很简单，不需要、没必要。在创业之初，2004 年时，支付宝还是淘宝中的一个结算部门，淘宝的会计人员用两台电脑和一张Excel 表就能进行结算。那时每天的交易金额是三位数，全天交易笔数只有十几笔，如果分摊到每秒钟，则约等于零。

2009 年是淘宝第一次搞双 11 大促，那时双 11 还不像现在这样广为人知，所以 2009 年的交易量并不大。在此之前，支付宝也刚完成二代架构的升级改造。在二代架构做完之后，支付宝的技术团队感觉能解决的技术问题都已经解决了，很多人认为未来系统也许就可以这样发展下去。因此在 2010 年双 11 大促之前，支付宝的系统规划是按照每年增长 100% 余量预估的。

但谁也没有预料到人们买买买的疯狂程度，二代架构上线并没有多久就迎来了严峻的考验。双 11 当天零点刚过，支付宝的业务量快速攀升，每秒交易量直接飙到平时峰值的三倍——每秒 500 笔，而且居高不下。这时大家才意识到，系统容量并不足以支撑当天的交易量。

情急之下，支付宝技术团队开始不停地“搬资源”、“砍业务”，东拼西揍地保障系统不崩溃，这一窘迫的过程事后又被大家戏称为“人肉云计算”。直到当天的 23 时 59 分 30 秒，眼看 2010 年双 11 大促就要结束了，突然核心账务系统报警。千钧一发之际，技术团队紧急将内部对账用的会计系统应用杀掉（可以在双 11 过去之后再用交易数据恢复），将资源释放出来，这次双 11 才算有惊无险地度过，而这时距离数据库崩溃仅剩 4 秒。

“双 11”逼出来支付宝的三代架构

从 2005 年开始，支付宝的技术架构经历了“烟囱型”、“面向服务型”、 “云平台型”三个时期。支付宝的三代架构可以说是和双 11 彼此成就的。

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

第一代“烟囱型”架构能够满足小团队开发、业务快速试错的需求，但是这个架构无法支持大团队的分布式开发。与此同时，它的部署也是集中的，核心系统就是一个集群，数据库也只有一个。随着业务量的上升，这样的数据库和集群很快就会达到极限。为了满足业务扩展的需要，分布式架构改造被提上了日程。

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

2007 年初，分布式系统技术逐渐成熟，特别是大规模 SOA 系统中的分布式事务处理标准逐渐明晰，支付宝随之启动了分布式改造工作。从 2007 年开始，支付宝陆续花费了三年左右对整个系统进行分布化，将原来的大系统拆成了一个个分布式的“服务”。由此，支付宝夯实了分布式事务的基础设施，所有的业务都可以分开来做，系统具备了可伸缩性，如果遇到业务峰值，就可以增加资源。当然，这时增加资源还需要人工搬运。但支付宝的第二代架构已经为第三代架构“云支付”打下了基础，因为如果使用云计算，系统首先要分布，只有这样才能用很多小型机器、云资源作为支撑。

二代架构改造完成之后，淘宝开始了每年一度的双 11 大促。对于支付宝技术来说，2010 年是一个拐点，这一年，交易数据的峰值比此前翻了三倍，也正是这一年惊险的双 11 让技术团队意识到，业界现有技术和传统架构已经无法满足支付宝的发展需求。

支付宝技术团队尝试了一种新的对策——分布式“异地多活”架构。蚂蚁金服副总裁胡喜将其比喻为“拆掉了高端中央收银台，换成了分散在商场各个角落的无数小型计算器”，每台计算器虽然不如单一中央收银台厉害，但个个都能记点帐，同时支付宝为分散在各处的计算器设计了相互关联的逻辑关系，使它们互为补充、互相备份，从全局上保证运算可靠，因而任何单个计算器的故障，都不会影响整个系统的正常运行。这是这种架构中最核心的云计算能力。

从二代架构过渡到三代架构，支付宝又花了三年时间。在此期间，支付宝开始自主研发中间件、数据库、大数据平台。第三代云支付架构完成了两方面的改造：一方面是在底层使用云计算技术；另一方面是在上层把服务变成云服务，如此一来，建立在这个架构之上的业务增长就不会受到限制。

正是这个云计算架构，支撑了近几年淘宝大促的交易，也使后来的“天猫双 11”能够平稳地进行。

2016 年双 11 蚂蚁金服在技术保障上有两个亮点，一是整个支付核心链路，包括交易、支付、会员、账务都运行在自研数据库 OceanBase 上；另一个是蚂蚁自主研发的弹性架构，能够利用全国多个城市的云计算资源，从而支撑 12 万笔／秒的支付峰值（2015 年的 1.4 倍）。

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

2017 年支付技术保障新亮点

1. 离在线混合部署

今年蚂蚁金服推出了离在线混合部署，使用的服务器资源有 25% 是自有的，55% 在云上，20% 是离线资源。今年天猫双 11 交易高峰期，一部分交易将首次跑在临时“征用”来的存放和处理分析离线数据的服务器上。

说是临时“征用”，但绝不仅仅是“征来就用”那么简单。因为处理离线数据（即处理每天数据分析报告以及当日账表）和处理在线交易（即处理支付宝用户在线的海量实时交易）是完全不同的任务，这也决定了处理离线数据和处理在线交易的服务器的配置相差悬殊。

如何在交易高峰期，以秒级的速度将在线服务器的各种软件、应用转移到离线服务器中？这背后起到关键作用的，是容器技术和统一资源调度的能力。容器技术相当于标准化改造，有了这个标准化改造的能力，各种配置不一、可以暂时放下手中的活伸出援手的服务器，都可以在各种大促场景派上用场，帮助疏通与分流。据估算，离在线混部技术能为 2017 年天猫双 11 减少近两千台服务器的投入。

2. 超级会计师 OceanBase

2016 年天猫双 11，12 万笔每秒交易峰值的背后，是“超级会计师”OceanBase 在发挥关键作用。

OceanBase 是一个海量数据库，可以存放千亿条以上的记录，单台普通的服务器每秒可以处理百万笔事务，平均一次花的时间仅在毫秒级别。

但意外的发生：服务器机房所在城市断电、连接机房的光纤被挖断、再好的机器也有出故障的时候……所以，金融机构普遍采用两地三中心来部署机房。

为了达到更高的可靠性，OceanBase 今年开始把数据同时放到三个城市，做五份数据备份，进一步降低了出错的可能性。

三地五中心，不仅仅是多了一个城市两个机房，蚂蚁金服还尝试使用一个新的选举协议：在出意外情况时，谁得到大多数投票，谁就当选主库。主库不再是固定的，每个被选举出的主库都是临时的，且它做的决定必须得到半数以上的同意才能实施。举个例子，一个主库刚被选举出来，它所在城市的光纤突然被挖断了，它会立即被票出去，做不成老大了，它做的决定也会全部被宣布无效；同时，一个新的主库会被票选出来，保证线上交易的顺利进行。

采用三地五中心的方案后，主库突发故障或者任何一个甚至两个机房同时断电、断网，业务都能在极短时间内自动恢复，不需要任何形式的人工对账。

3. 金融级图数据库 GeaBase

除了 OceanBase，蚂蚁技术团队还自主研发了一个叫 GeaBase（以下简称 GB）的金融级图数据库，它通过特有的数据组织方式和分布式并行计算算法，可以在几十毫秒内彻查目标对象的多跳资金转移关系、设备关联关系等组成的复杂网络，从而迅速锁定目标关联、识别欺诈。

GeaBase 是蚂蚁金服风控系统背后的关键技术支撑之一。刷单党、花呗套现党、羊毛党、欺诈等行为，都依靠 GeaBase 来识别。胡喜介绍道：“风控从最早偏向于规则架构，到后来规则加模型架构，现在向 AI 转，这也是双 11 相关的关键能力，背后承载的是我们在分布式金融交易之外的金融级实时决策能力。”

“未问先答”的新客服，开启主动服务模式

双 11 大促当天，随着交易量暴增，使用中遇到问题的用户数量也会大幅增加。不知道在你的想象中，支付宝会有多少客服小二？

记者走访了一圈蚂蚁金服 Z 空间大楼，这里的淘宝小二只有 600 人左右，算上成都团队和外包团队，也不过小数千人。而且，蚂蚁金服智能客服负责人子孟说道：“淘宝天猫平台业务量逐年增长，但是我们客服人数没有增加，反而还减少了。”

而这背后，是蚂蚁金服客服技术的进步史。

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

客服 1.0：查询问答

在这个阶段，更多是查询类的事情，把很多回答的内容做成一个类目树让大家查询，不管在热线电话还是在 PC 端、APP 端，多数情况下需要大家逐层挖掘。比如我们拨打客服电话经常遇到的“xx 请按 1，xx 请按 2……人工服务请按 0”，要找到精确的问题分类或人工客服，不得不先听一段无比冗长的录音，导致查询效率底下，难以找到准确的答案。

客服 2.0：快捷应答

这一阶段是互联网企业通常会采用的手段，包括蚂蚁金服在很多场景下也会切换到这个手段，就是快捷应答。它包含两个点：一是更多在 APP 端、PC 端用问答机器人解决用户问题，通过用户问题可以快速识别问题分类，并指向某一个具体答案或者人工服务；二是在传统的电话过程当中，减少按键输入，更多使用语音交互方式。

客服 3.0：未问先答

很多时候客服的角色是相对滞后的，要等用户找上门来提出问题，甚至反复不断提出要求才能够回应，我们认为极致服务应该把事情做到事前，在用户可能遇到问题的时候提前化解他的障碍和疑问。

前一阶段积累了很多数据和用户行为的数据，我们现在希望推出的叫做“未问先答”服务。

在所有服务渠道中，我们不断依据用户的实时行为数据，经过学习和分析，在用户没有开口的时候就知道他可能想问什么问题，更快速地解决问题，这是“未问先答”这样一个技术在整个服务中的角色。

“未问先答”服务使用效果如下（整理自真实录音）：

智能客服：欢迎致电蚂蚁金服，为给您提供自助或人工服务，请简单描述一下您的问题，请讲。

用户：我想问一下那个余额宝里面的那个一万块的话一天是多少利息？

机器客服：您是要咨询余额宝的收益如何计算，对吗？

用户：对！

机器客服：您的解决方案已经发送，你可以登录手机支付宝在首页进行查询，请问还有其他问题吗，没有问题请挂机，如需人工服务请按 1。

“未问先答”还有其他玩法，比如用户在支付宝里反复操作、研究一个功能，但是多次操作后还没有成功，那么智能客服就会自动弹出，询问是否遇到困难，然后给出方案帮助客户解决。

“未问先答”的技术原理

“未问先答”如神算子一般的预测能力背后，离不开数据采集、算法加工和持续反馈学习。

1. 大量用户行为数据是一切的基础。蚂蚁金服为实现“未问先答”而采集的数据主要有以下几种：一是通过客服加工过的有规则的精准因子，即这个用户具备什么样的特征，意味着什么样的问题；二是大量用户在支付宝操作、点击、页面跳转行为轨迹的特征；三是客户在服务渠道上咨询过什么问题、求助过几次；四是用户在支付宝、服务端描述过的，和他的需求相关的文本信息。
2. 通过深度神经网络算法加工数据。不同数据加工方式不一样，比如轨迹类数据使用 RNN 模型，从而能更好地表现建模时间的先后顺序；对于用户画像和人工设计的精准因子会使用全连接的神经网络；对于文本数据则使用注意力模型。本质上就是在海量特征和标类问题之间进行匹配，精度相对比较高。
3. 持续不断的反馈学习。一次性做完可能很容易，但是结果通常不会一次就达到理想水平，因此需要利用反馈数据进行自学习优化。正负反馈都能进一步优化模型的训练，整个过程是数据闭环和自学习的过程，蚂蚁金服三月份就上线了这一模型，但是运转了约半年以后这个模型才相对成熟，甚至很多数据采集其实很多年前就开始了，但也经过了 1-2 年的沉淀才真正将数据投入应用。

今年，智能客服的“未问先答”技术首次运用于双 11。在人工智能的帮助下，新客服系统能预判用户可能碰到的问题，从被动型服务（等待用户来提问）转为主动型服务（提前预知用户可能存在的问题并提供解决方案），进而提高服务效率和用户体验。

AI Everywhere

沟通会上，胡喜回忆起三四年前的双 11，感慨万千。他说道：“以前的双 11，技术保障团队差不多三四百人，从年初开始准备，这些人很多事情都不做，就是要支持双 11，一次双 11 做完以后非常累。”而今年，智能化系统已经可以辅助人工进行系统容量预估和自动扩容。

除了容量预测和智能客服，人工智能也被应用到了双 11 的故障监控中。所有系统运行数据输入相应的机器，由机器进行训练，训练后生成模型，系统运行时模型输出的值是否合理不再由人来判断，而是由机器自动判断，从而快速发现系统异常。

胡喜表示，今年是 AI 的实验期，对于金融系统来说最大的挑战是可靠性和安全性，如何在保证系统智能化的同时提升系统的可靠性和安全性，一直是蚂蚁金服追求的方向。“今年蚂蚁金服已经把 AI 能力先应用在一些点上，比如故障预测、容量预测等，明年我们还会推出一个内部叫做免疫系统的平台，专门做故障自动发现和恢复的事情。”

胡喜感叹：“2017 年‘大考’，All in 支付技术保障只需要一个弹性化的小团队，而无需占用大量人力。这意味着‘天猫双 11’越来越常态化。翻看几年前双 11 的老照片，照片里满公司的帐篷、睡袋，感觉已经是很久远的事情了。”

这背后，是技术在变得越来越智能化。