阿里巴巴双１１技术团队：负责双１１所有产品的开发，保障系统稳定性和用户体验，覆盖了几乎阿里所有事业部的技术团队，由天猫、手淘、业务平台、淘宝、蚂蚁、聚划算、中间件、搜索、菜鸟、阿里云、安全、基础架构、商家事业部、AliExpress、飞猪、阿里健康、数据平台、村淘、阿里妈妈、集团客服、钉钉、阿里通信、优酷等二十多个BU共同组成的技术团队。

　　“双１１”，诞生于杭州，成长于阿里，风行于互联网，成就于新经济，贡献于全世界。

　　从2009年淘宝商城起，双１１已历经八年。每年的双１１既是当年的结束，又是走向未来的起点。技术的突破创新，商业模式的更替交互，推动着双１１迈步向前。

　　本书是由阿里巴巴集团官方出品、全面阐述双１１八年以来在技术和商业上演进和创新历程的书籍。内容涵盖在双１１背景下阿里技术架构八年来的演进，如何确保稳定性这条双１１生命线的安全和可靠，技术和商业交织发展的历程，无线和互动的持续创新与突破，以及对商家的赋能和生态的促进与繁荣。

　　本书主要面向广大互联网技术和商业从业者，内容包括基础设施、云计算、大数据、AR/VR、人工智能、物联网等技术领域的剖析，以及在电商、金融、客服、物流等商业层面的洞察；同时，本书也可以作为了解科技与商业发展的一个窗口，供科研人员和高校在校师生参考。

　　本书也包含丰富的双１１发展历程中的故事性片段，生动有趣，可读性强，读者可以在由衷感叹双１１背后艰辛的演进历程之余，更为透彻地体会到阿里人在技术和商业创新上坚韧不拔、矢志不渝的精神。

　　高管推荐：

　　本书以双１１为着眼点，从技术的角度，展示了阿里巴巴的演进、变革与发展，系统地阐述了阿里巴巴重要阶段的技术进步历程。进无止境，我们希望将我们的经验分享给更多人，并希望与大家一起共同探索未来。

　　——张勇，阿里巴巴集团CEO

　　我力荐这本书，它是对“双１１”技术演进客观、翔实的还原。

　　——行癫，阿里巴巴集团CTO

　　2.2 全链路压测，大促备战的核武器

　　全链路压测被誉为大促备战的“核武器”。如果之前关注过阿里双11相关的技术总结，对全链路压测一定不会陌生，这个词的出场率几乎是100%，从对双11稳定性的价值来看，用“核武器”来形容全链路压测毫不为过。

　　2.2.1 背景

　　历年的双11备战过程中，最大的困难在于评估从用户登录到完成购买的整个链条中，核心页面和交易支付的实际承载能力。自2009年第一次双11以来，每年双11的业务规模增长迅速，零点的峰值流量带给我们的不确定性越来越大。2010年，我们上线了容量规划平台从单个点的维度解决了容量规划的问题，然而在进行单点容量规划的时候，有一个前提条件：下游依赖的服务状态是非常好的。实际情况并非如此，双11 零点到来时，从CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路都面临着巨大流量，这时应用的服务状态除了受自身影响，还会受到环境影响，并且影响面会继续传递到上游，哪怕一个环节出现一点误差，误差在上下游经过几层累积后会造成什么影响谁都无法确定。所以除了事先进行容量规划，还需要建立起一套验证机制，来验证我们各个环节的准备都是符合预期的。验证的最佳方法就是让事件提前发生，如果我们的系统能够提前经历几次双11，容量的不确定性问题也就解决了。全链路压测的诞生就解决了容量的确定性问题！

　　2.2.2 全链路压测1.0从无到有

　　提前对双11进行模拟听起来就不简单，毕竟双11的规模和复杂性都是空前的，要将双11提前模拟出来，难度可想而知：

　　? 跟双11相关的业务系统有上百个，并且牵涉整条链路上所有的基础设施和中间件，如何确保压测流量能够通畅无阻，没有死角？

　　? 压测的数据怎么构造（亿万级的商品和用户），数据模型如何与双11贴近？

　　? 全链路压测直接在线上的真实环境进行双11模拟，怎样来保证对线上无影响？

　　? 双11是一个上亿用户参与的盛大活动，所带来的巨大流量要怎样制作出来？

　　2013年8月中旬，当时高可用架构团队的负责人叔同（叔同：高可用架构&运维产

　　品&基础产品团队负责人、资深技术专家）接下了这个巨大的挑战：打造一套全链路压测平台。平台需要在2013年双11之前上线，错过了这个时间点，我们就必须再等一年。从立项到双11，留给我们的时间只有短短两个多月，时间非常紧，我们需要在这么短的时间里应对一系列历史级的挑战。2013年阿里搬到西溪园区，其他同学都是搬到新工位，全链路压测项目组直接搬到了项目室，进行闭关攻坚。

　　业务改造升级

　　2013年核心交易链路就有几十条，牵涉多个BU的几百位研发人员，这些业务链路绝大部分是没法直接压测的，需要进行相应的业务改造和中间件的升级。推动几百号人在短时间之内完成业务的改造在很多公司几乎是不可能完成的，何况还牵涉中间件的升级，中间件的升级一般会有一个相对比较长的周期，有不少业务系统的中间件版本都非常古老（5年前的版本），需要确保无风险直接升级到最新版本。

　　在业务端我们需要逐条链路进行一一梳理，从请求进来的系统到请求的最后一个环节（复杂的业务会经过几十个系统），每一个有阻压测流量往下走的地方都进行特殊的逻辑改造。改造的业务点牵涉100多个，包括登录验证码、安全策略、业务流程校验等。在基础设施和中间件上，我们需要让业务系统的代码尽可能不需要修改，通用的技术通过基础设施和中间件来屏蔽掉，比如压测流量的标识怎样在整个请求的生命周期中一直流转下去，怎样来对非法的请求进行拦截处理。

　　参与全链路压测改造的技术人员体现了良好的协作精神和执行力，为了同一个目标齐头并进、相互补位，原本认为几乎不可能的事情，最终在一个月内完成了相应的业务改造和中间件升级。

　　数据构造

　　数据构造有两个核心点：

　　? 双11的买家、卖家、商品数量都非常庞大，需要构造同数量级的业务数据；

　　? 需要确保业务数据的模型尽可能贴近双11零点的真实场景，否则全链路压测结果的误差会比较大，参考的价值将会大打折扣。

　　为此我们专门搭建了全链路压测的数据构造平台，对业务模型进行系统化的管理，同时完成海量业务数据的自动化构造，如图2-5所示。

　　数据构造平台以线上数据为基础，借助数据dump（dump：在特定时刻，将储存装置或储存装置之某部分的内容记录在另一储存装置中）工具进行数据的抽取，并对关键数据进行相应的处理（脱敏、订正等）后进入基础数据池备用。基础数据池是压测数据的超集，具体压测数据的构造基于基础数据集进行数据的再加工。

　　除了需要有足够量级的数据，我们要解决的另一个问题是数据的模型应该是怎样的。借助BI工具结合预测算法对数据进行筛选建模，并结合每一年双11的业务玩法进行修订，产出一份最终的业务模型。业务模型的因子牵涉几百个业务指标，包含买家数、买家类型、卖家数、卖家类型、优惠种类、优惠比例、购物车商品数、BC比例、移动PC比例、业务的量级等。

　　数据隔离

　　全链路压测要不要做数据隔离、怎样来做数据隔离，在项目立项阶段经过了非常多的讨论甚至争吵。在最开始的时候，我们想做逻辑隔离，直接把测试数据和正常数据写到一起，通过特殊的标识区分开，这个方案很快就被放弃了：线上数据的安全性和完整性不能被破坏。接下来我们提出了另一个方案，在所有写数据的地方做mock（mock：软件开发概念，指模拟），并不真正写进去，这个方案不会对线上产生污染，但评估时还是被放弃了：mock对压测结果的准确性会产生干扰，而我们需要一个最贴近实际行为的压测结果。

　　经过反复讨论，最终我们找到了一个既不污染线上，又能保障压测结果准确性的方案：在所有写数据的地方对压测流量进行识别，判断一旦是压测流量的写，就写到隔离的位置，包括存储、缓存、搜索引擎等。

　　4. 流量构造

　　双11是一场“剁手党”的狂欢，零点的峰值流量是平时高峰的几百倍，每秒几百万次的请求如何构造同样成为大难题。我们尝试通过浏览器引擎或者一些开源压测工具的方式来模拟用户请求，经过实际测试，要制作出双11规模的用户流量，浏览器引擎和开源压测工具需要准备几十万台服务器的规模，成本是无法接受的，并且在集群控制、请求定制上存在不少限制。既然没有现成的工具可以使用，我们只好选择自己研发一套全链路压测流量平台，如图2-6所示。

　　全链路压测的流量平台是一个典型的Master＋Slave结构：Master作为压测管控台管理着上千个Slave节点；Slave节点作为压测引擎，负责具体的请求发送。Master作为整个压测平台的大脑，负责整个平台的运转控制、命令发送、数据收集、决策等。Slave节点部署在全球各地的CDN节点上，从而模拟从全球各地过来的用户请求。整套全链路压测的流量平台在压测过程中平稳输出1000多万/秒的用户请求，同时保持过亿的移动端用户长连接。

　　正式上线

　　在两个多月的时间里，项目组的成员披星戴月，有一半时间在通宵，另外一半时间是凌晨3点以后下班。2013年10月17日凌晨的1号楼，全链路第一次登台亮相（如图2-7所示），这一天对整个全链路压测项目组的人都意义非凡，辛苦了两个多月的“大杀招”终于要派上用场了！当压测开始的按钮被按下去，大家都全神贯注地盯着各种系统等着流量上来，1分钟、2分钟过去了，我们的业务系统却丝毫没有流量进来。忙活了一晚上，第一次亮相狼狈收场，当时全场有200多号人，每一次让大家准备好却没有流量发出去的时候，面对着全场200多双眼睛，压测项目组每一个成员的手都是抖的。好在第一次的失败让我们吸取了充分的经验，又经过好几个昼夜的奋战，第二次的压测比第一次进步了很多，到了第三次就已经能完全达到我们的使用预期了。

　　2.2.3 全链路压测2.0平台升级

　　全链路压测诞生之后为系统稳定性带来的改变立竿见影，2013年经过了几次全链路压测，双11零点的表现比以往任何一年都平顺。全链路压测也在阿里一炮而红，越来越多的业务希望能接入进来。

　　1. 平台化

　　海量的业务接入给全链路压测平台带来全新的挑战：当时的全链路压测操作都需要压测项目组的成员来进行操控。随着越来越多的业务接入全链路压测平台，压测项目组很快就成了瓶颈，压测平台的能力急需升级。2015年，全链路压测“平台化”项目启动，我们着手将全链路压测朝着平台化的目标推进和实施，做到压测能力开放、业务方自主压测，让更多业务方能够享受到全链路压测的优势和便利，如图2-8所示。全链路压测平台化项目的上线大幅提升了全链路压测平台的服务能力：2015年大促备战的3个月内，压测平台总共受理近600多个压测需求（比2014年提升20倍），执行压测任务3000多次（比2014年提升30倍）。

　　2. 日常化

　　全链路压测的压测流量和正式流量经过的路径是一致的，如果链路中某一个节点被压挂或者触发限流，势必会影响线上用户的正常访问。为了减少影响，全链路压测一般都安排在凌晨，通宵达旦，非常辛苦！为了减少熬夜，提升压测幸福度，我们启动了白天压测的项目：将线上运行的机器动态隔离出一部分放到隔离环境中，这部分机器上只有压测流量可以访问，白天在隔离环境的机器上进行压测。隔离环境与线上环境几乎一样，从流量入口、中间件、应用后端实现完整隔离。隔离环境完全打通了配置中心、服务注册中心、消息中心、地址服务器等基础设施，不需要业务系统做任何改造即可完成。并且是直接从线上机器按照特定规则选择到隔离环境中，机型配置跟线上基本一致，使用完毕之后直接恢复到线上集群中，不会影响线上集群的容量。大促备战期间，我们可以白天在隔离环境中进行小目标、小范围的全链路压测，用极小的代价提前发现问题。由于隔离环境场景相对于其他线下环境更加真实、操作快捷、不占用额外机器资源，在预案演练、破坏性测试、线上问题排查、故障演练等其他场合也获得了比较广泛的应用。

　　2.2.4 全链路压测3.0生态建设

　　2016年在三地五单元混合云部署架构下，电商一半以上的资源部署在云上。在庞大的电商系统背景下，如何能够在最短的时间内完成一个单元的搭建和容量准备成为摆在我们面前的一道难题，而全靠“经验之谈”和人工介入是不可能完成的任务。2016年初，“大促容量弹性交付产品”立项，旨在减少甚至释放活动场景的容量交付中的人工投入，并将大促容量交付的运维能力沉淀到系统中，使全链路容量具备“自动化”调整的能力。我们提出了大促自动化备战的想法，将大促容量准备的各个环节进行系统层面的打通，从业务因子埋点、监控体系、模型预测、压测数据构造、压测流量发送、压测结果分析、压测报表进行自动化串联，大幅缩减了在大促容量准备阶段的人员投入和时间周期。围绕全链路压测的核心基础设施，全链路压测的周边生态逐步建立起来，打通建站、容量、监控等配套技术体系，如图2-9所示。

　　全链路压测在保障系统稳定性的同时，也为业务稳定性的保障提供了强有力的支持，2016年我们落地了全链路功能测试、大促功能预演等一系列项目：创造性地在隔离环境提前将系统时间设置到双11的零点。通过在这个提前的双11环境购买一遍双11的商品，进行充分的业务验证，最大限度地降低双11当天的业务问题。

　　2.2.5 总结

　　每年双11前夕，全链路压测都要组织好几次，不断地通过压测发现问题进行迭代优化，全方位验证业务的稳定性，我们的业务系统也只有在经过了全链路压测的验证之后才有信心迎接双11零点的到来。全链路压测将大促稳定性保障提升到新的高度，是双11、双12等大促备战最重要的“核武器”，并且随着业务的发展不断进化，持续发挥着不可替代的作用。

　　……

序一  IX

序二  X

双11大事年表  XII

引言  XIII

第1章 阿里技术架构演进  1

双11是阿里技术发展的强大驱动力，双11业务的快速发展造就了阿里具备高度水平伸缩能力、低成本的电商架构体系。这个架构体系是如何一步一步形成的呢？在形成过程中阿里遇到了哪些问题，做了哪些尝试，最终用什么样的思路、方法和技术解决了问题？

1.1 五彩石，电商架构新起点  3

1.2 异地多活，解除单地域部署限制的新型双11扩容方式  9

1.3混合云，利用阿里云弹性大幅降低双11成本  17

1.4 OceanBase，云时代的关系数据库  23

1.5 手机淘宝，移动互联网电商新时代  30

1.6 蚂蚁技术架构演进  36

第2章 稳定，双11的生命线  43

双11最大的困难在于零点峰值的稳定性保障。面对这种世界级的场景、独一无二的挑战，阿里建设了大量高可用技术产品，形成了全链路一体化的解决方案，用更加逼真和自动化的方式，去评估、优化和保护整个技术链条，最大化地为用户提供稳定可靠的服务。

2.1 容量规划，资源分配的指南针  45

2.2 全链路压测，大促备战的核武器  51

2.3 全链路功能，提前开始的狂欢盛宴  58

2.4 自动化备战，喝着咖啡搞大促  65

2.5 实时业务审计，从系统可用到业务正确  70

2.6 故障演练，系统健壮性的探测仪  75

2.7 系统自我保护，稳定性的最后一道屏障  82

第3章 技术拓展商业边界  89

双11业务驱动技术发展的同时，技术的创新与发展也不断推动着商业模式的升级与变革，实践着技术拓展商业的边界。

3.1 招商报名，活动基础设施建设  91

3.2 会场，小二与商家共同打造的购物清单  99

3.3 搜索，大促场景下智能化演进之路  107

3.4 个性化推荐，大数据和智能时代的新航路  114

3.5 供应链，从飞速增长到精耕细作  120

3.6 蚂蚁花呗，无忧支付的完美体验  127

第4章 移动端的技术创新之路  133

从2010年开始，国内爆发了从PC向移动端技术和业务的持续迁移，移动深刻地改变着人们的衣食住行和人际交往。阿里的双11始于2009年，正好经历了移动互联网崛起的全程，双11在移动端的主要创新有哪些呢？

4.1 Weex，让双11更流畅  135

4.2 互动，让购物变成狂欢  143

4.3 VR&AR，移动端创新体验  153

4.4 奥创&TMF，让双11多端业务腾飞  163

第5章 繁荣生态，赋能商家  171

双11从阿里内部员工的一个点子到全球购物狂欢节，其背后支撑是服务、物流、大数据、云计算、金融服务等，是商家自身业务结构的调整、消费者消费习惯的转变、第三方开发者的大量入驻，以及整个生态的变迁。

5.1 聚石塔，开放的电商云工作台  173

5.2 菜鸟电子面单，大数据改变物流  179

5.3 生意参谋，数据赋能商家的“黑科技”  184

5.4 阿里小蜜，用智能重新定义服务  191

5.5 阿里中间件，让传统企业插上互联网的翅膀  198

5.6 蚂蚁金服，金融机构间协同运维的探索和实践  205

展望  213

索引  216