30人保障双11全球10亿笔交易顺利支付是种什么样的体验？

今年是双11的第8个年头，这个双11的交易笔数、交易额、支付峰值也都创造了新的世界纪录。

全天的支付总笔数10.5亿笔，同比增长48%；支付峰值12万笔/秒，出现在双11凌晨的零时9分39秒；协调全球银行达到交易支付峰值5.4万笔/秒；

一天近10亿笔支付，最高时一秒12万笔，能顺畅进行，背后有着怎样的技术保障？我们找到了蚂蚁金服首席技术架构师胡喜，想让他给介绍下。

本来以为双11他的团队要忙的四脚朝天的，计划下周一再去找他。没想到他说，「今天是我在阿里＋蚂蚁工作9年来最轻松的一个双11」。更没想到的是，今年双11，提供技术保障的同学，只有不到30人。

所以我们今天就去找他聊了。

胡喜，花名阿玺。蚂蚁金服首席技术架构师，基础技术部负责人。2007年加入支付宝，主持支付平台基础技术的架构设计与研发工作，并且参与蚂蚁金服各代核心支付平台的架构设计和系统研发工作。

〇

胡喜说，回想三四年前的双11，我们还要举全公司70～80%的技术同学all in到技术保障中。比如2010年时，几百号技术同学全部坐在电脑前，紧盯电脑看系统，有问题立马就要应急，不行就重启机器，容量不行就加机器，我们笑称这是「人肉云计算」。

临近凌晨，大家都以为终于扛过去了，结果又给我们来一个下马威，最后一个小时高峰突然出现，数据出现了容量问题，那时距离双11结束还有半小时，怎么办？

幸好之前设计账务架构的时候，给自己留了一个降级的能力，我们停止了在同一个库上的会计系统，而会计和账务是通过一部消息进行同步的，会计系统是我们内部做对账使用的，停止会计系统在可控的时间内对业务是没有影响的，因为后续还可以通过可靠消息进行恢复，所以临时做了个决定就把这个系统给杀掉了，然后腾出50%容量就过去了。这才最终让那天有惊无险安然度过。

一

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

在此前一年，我们开始自主研发数据库OceanBase。阿里集团也是从那一年开始，决定不再采购任何一台来自商业设备，也就是王坚博士说的去IOE化。

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

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

这种努力的成果是显著的，在满足支付宝系统同样稳定的前提下，极大的降低了对于成本的投入，现在支付宝单笔交易成本仅人民币两三分左右。

二

2016年双11，在技术保障上有两个亮点，一个是整个支付核心链路：核心的交易、支付、会员、账务今年都运行在OceanBase上。另一个是蚂蚁自主研发的新一代弹性架构，能够利用全国多个城市的云计算资源，今年12万笔／秒的支付峰值，是去年的1.4倍，也毫无压力。

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

说得通俗一点，比如说你家突然来了10个客人，要住一周，为此去买4台洗衣机就太浪费了，一周后就闲置了。我们用了一种比较廉价的方式，采用一种在云上公用的方式，用的时候先把机器资源调度过来（这个所有的前提都是基于数据安全控的技术之上），不用的时候就直接还回去，这样我的成本更可控。

这就相当于你家里还是一台洗衣机，家里一下子来了10个客人，就把衣服送到洗衣店洗，反正洗衣店是大家共享的。

三

从2010年开始，我们给自己定的目标是，每年专为双11提供技术保障投入的成本比前一年都降30～50%左右，到2019年，我们将不再花一分钱投到双11当天的技术保障上，也就是说，双11将完全常态化。

ps，此前，我从没在双11当天购过物，今年终于有点时间，刚抢了件秋衣，擦，秋裤没了。