详解双11终极“核武器”：全链路压测如何诞生？

Posted 2021-04-24 阿里技术

本文内容来自阿里巴巴集团双11技术团队撰写的《尽在双11：阿里巴巴技术演进与超越》一书。该书被阿里巴巴集团CTO行癫盛赞为“迄今为止对双11技术演进最客观、最详实的还原”，目前正在全国火热销售中。

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

背  景

历年的双11备战过程中，最大的困难在于评估从用户登录到完成购买的整个链条中，核心页面和交易支付的实际承载能力。自2009年第一次双11以来，每年双11的业务规模增长迅速，零点的峰值流量带给我们的不确定性越来越大。

2010年，我们上线了容量规划平台从单个点的维度解决了容量规划的问题，然而在进行单点容量规划的时候，有一个前提条件：下游依赖的服务状态是非常好的。

实际情况并非如此，双11 零点到来时，从CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路都面临着巨大流量，这时应用的服务状态除了受自身影响，还会受到环境影响，并且影响面会继续传递到上游，哪怕一个环节出现一点误差，误差在上下游经过几层累积后会造成什么影响谁都无法确定。

所以除了事先进行容量规划，还需要建立起一套验证机制，来验证我们各个环节的准备都是符合预期的。验证的最佳方法就是让事件提前发生，如果我们的系统能够提前经历几次双11，容量的不确定性问题也就解决了。全链路压测的诞生就解决了容量的确定性问题！

全链路压测1.0从无到有

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

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

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

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

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

2013年8月中旬，当时高可用架构团队的负责人叔同（高可用架构&运维产品&基础产品团队负责人、资深技术专家）接下了这个巨大的挑战：打造一套全链路压测平台。

平台需要在2013年双11之前上线，错过了这个时间点，我们就必须再等一年。

从立项到双11，留给我们的时间只有短短两个多月，时间非常紧，我们需要在这么短的时间里应对一系列历史级的挑战。2013年阿里搬到西溪园区，其他同学都是搬到新工位，全链路压测项目组直接搬到了项目室，进行闭关攻坚。

1. 业务改造升级

2013年核心交易链路就有几十条，牵涉多个BU的几百位研发人员，这些业务链路绝大部分是没法直接压测的，需要进行相应的业务改造和中间件的升级。

推动几百号人在短时间之内完成业务的改造在很多公司几乎是不可能完成的，何况还牵涉中间件的升级，中间件的升级一般会有一个相对比较长的周期，有不少业务系统的中间件版本都非常古老（5年前的版本），需要确保无风险直接升级到最新版本。

在业务端我们需要逐条链路进行一一梳理，从请求进来的系统到请求的最后一个环节（复杂的业务会经过几十个系统），每一个有阻压测流量往下走的地方都进行特殊的逻辑改造。改造的业务点牵涉100多个，包括登录验证码、安全策略、业务流程校验等。

在基础设施和中间件上，我们需要让业务系统的代码尽可能不需要修改，通用的技术通过基础设施和中间件来屏蔽掉，比如压测流量的标识怎样在整个请求的生命周期中一直流转下去，怎样来对非法的请求进行拦截处理。

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

2. 数据构造

数据构造有两个核心点：

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

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

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

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

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

3. 数据隔离

全链路压测要不要做数据隔离、怎样来做数据隔离，在项目立项阶段经过了非常多的讨论甚至争吵。在最开始的时候，我们想做逻辑隔离，直接把测试数据和正常数据写到一起，通过特殊的标识区分开，这个方案很快就被放弃了：线上数据的安全性和完整性不能被破坏。

接下来我们提出了另一个方案，在所有写数据的地方做mock（mock：软件开发概念，指模拟），并不真正写进去，这个方案不会对线上产生污染，但评估时还是被放弃了：mock对压测结果的准确性会产生干扰，而我们需要一个最贴近实际行为的压测结果。

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

4. 流量构造

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

既然没有现成的工具可以使用，我们只好选择自己研发一套全链路压测流量平台，如图2-6所示。

全链路压测的流量平台是一个典型的Master＋Slave结构：Master作为压测管控台管理着上千个Slave节点；Slave节点作为压测引擎，负责具体的请求发送。Master作为整个压测平台的大脑，负责整个平台的运转控制、命令发送、数据收集、决策等。

Slave节点部署在全球各地的CDN节点上，从而模拟从全球各地过来的用户请求。整套全链路压测的流量平台在压测过程中平稳输出1000多万/秒的用户请求，同时保持过亿的移动端用户长连接。

5. 正式上线

在两个多月的时间里，项目组的成员披星戴月，有一半时间在通宵，另外一半时间是凌晨3点以后下班。2013年10月17日凌晨的1号楼，全链路第一次登台亮相（如图2-7所示），这一天对整个全链路压测项目组的人都意义非凡，辛苦了两个多月的“大杀招”终于要派上用场了！

当压测开始的按钮被按下去，大家都全神贯注地盯着各种系统等着流量上来，1分钟、2分钟过去了，我们的业务系统却丝毫没有流量进来。忙活了一晚上，第一次亮相狼狈收场，当时全场有200多号人，每一次让大家准备好却没有流量发出去的时候，面对着全场200多双眼睛，压测项目组每一个成员的手都是抖的。

好在第一次的失败让我们吸取了充分的经验，又经过好几个昼夜的奋战，第二次的压测比第一次进步了很多，到了第三次就已经能完全达到我们的使用预期了。

全链路压测2.0平台升级

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

1. 平台化

海量的业务接入给全链路压测平台带来全新的挑战：当时的全链路压测操作都需要压测项目组的成员来进行操控。随着越来越多的业务接入全链路压测平台，压测项目组很快就成了瓶颈，压测平台的能力急需升级。

2015年，全链路压测“平台化”项目启动，我们着手将全链路压测朝着平台化的目标推进和实施，做到压测能力开放、业务方自主压测，让更多业务方能够享受到全链路压测的优势和便利，如图2-8所示。

全链路压测平台化项目的上线大幅提升了全链路压测平台的服务能力：2015年大促备战的3个月内，压测平台总共受理近600多个压测需求（比2014年提升20倍），执行压测任务3000多次（比2014年提升30倍）。

2. 日常化

全链路压测的压测流量和正式流量经过的路径是一致的，如果链路中某一个节点被压挂或者触发限流，势必会影响线上用户的正常访问。为了减少影响，全链路压测一般都安排在凌晨，通宵达旦，非常辛苦！

为了减少熬夜，提升压测幸福度，我们启动了白天压测的项目：将线上运行的机器动态隔离出一部分放到隔离环境中，这部分机器上只有压测流量可以访问，白天在隔离环境的机器上进行压测。隔离环境与线上环境几乎一样，从流量入口、中间件、应用后端实现完整隔离。

大促备战期间，我们可以白天在隔离环境中进行小目标、小范围的全链路压测，用极小的代价提前发现问题。由于隔离环境场景相对于其他线下环境更加真实、操作快捷、不占用额外机器资源，在预案演练、破坏性测试、线上问题排查、故障演练等其他场合也获得了比较广泛的应用。

全链路压测3.0生态建设

2016年在三地五单元混合云部署架构下，电商一半以上的资源部署在云上。在庞大的电商系统背景下，如何能够在最短的时间内完成一个单元的搭建和容量准备成为摆在我们面前的一道难题，而全靠“经验之谈”和人工介入是不可能完成的任务。

2016年初，“大促容量弹性交付产品”立项，旨在减少甚至释放活动场景的容量交付中的人工投入，并将大促容量交付的运维能力沉淀到系统中，使全链路容量具备“自动化”调整的能力。

我们提出了大促自动化备战的想法，将大促容量准备的各个环节进行系统层面的打通，从业务因子埋点、监控体系、模型预测、压测数据构造、压测流量发送、压测结果分析、压测报表进行自动化串联，大幅缩减了在大促容量准备阶段的人员投入和时间周期。围绕全链路压测的核心基础设施，全链路压测的周边生态逐步建立起来，打通建站、容量、监控等配套技术体系，如图2-9所示。

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

总 结

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

推荐阅读

长按识别图片二维码▲，关注「阿里技术」，

不错过每一篇前沿技术干货。