全链路压测被誉为大促备战的“核武器”，如果之前有关注过阿里双11相关的技术总结，对“全链路压测”一定不会陌生，这个词的出场率几乎100%，从对双11稳定性的价值来看，用“核武器”来形容全链路压测毫不为过。
1. 背景
时间：2016年10月29日凌晨；地点：阿里西溪园区1号楼7楼“光明顶”；事件：200多人聚在一起，精神抖擞，摩拳擦掌。这阵势，是要去约群架吗？别紧张，他们只是在进行一次双11的模拟演习—全链路压测。
历年的双11备战过程当中，最大的困难在于评估从用户登录到完成购买的整个链条中，核心页面和交易支付的实际承载能力。自2009年第一次双11以来，每年双11的业务规模增长迅速，0点的峰值流量带给我们的不确定性越来越大。2010年，我们上线了容量规划平台从单个点的维度解决了容量规划的问题，然而在进行单点容量规划的时候，有一个前提条件：下游依赖的服务状态是非常好的。实际情况并非如此，双11 当天0点到来的时候，从CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路上都面临着巨大流量，这个时候应用的服务状态除了受自身影响，还会受到依赖环境影响，并且影响面会继续传递到上游，哪怕一个环节出现一点误差，误差在上下游经过几层累积后会造成什么影响谁都无法确定。所以除了进行事先的容量规划，我们还需要建立起一套验证机制，来验证我们各个环节的准备都是符合预期的。验证的最佳方法就是让事件提前发生，如果我们的系统能够提前经历几次“双11”，容量的不确定性问题也就解决了。全链路压测的诞生解决了容量的确定性问题！
2. 全链路压测1.0从无到有
提前对双11进行模拟听起来就不简单，毕竟双11的规模和复杂性都是空前的，要将双11提前模拟出来，难度可想而知：
1、 跟双11相关的业务系统上百个，并且牵涉到整条链路上所有的基础设施和中间件，如何确保压测流量能够通畅无阻，没有死角？
2、 压测的数据怎么构造（亿万级的商品和用户），数据模型如何与双11贴近？
3、 全链路压测直接在线上的真实环境进行双11模拟，怎么样来保障对线上无影响？
4、 双11是一个上亿用户参与的盛大活动，所带来的巨大流量要怎么样制作出来？
2013年8月中旬，当时高可用架构团队的负责人叔同接下了这个巨大的挑战：打造一套全链路压测平台。平台需要在2013年的双11之前完成开发上线，错过了这个时间点，我们就必需再等一年，从立项到双11，留给我们的时间只有短短两个多月，时间非常紧，我们需要在这么短的时间里完成一系列历史级的挑战。2013年阿里巴巴开始搬到我们新的西溪园区，其它同学都是搬到新工位，全链路压测项目组直接搬到了项目室，进行闭关攻坚。
1） 业务改造升级
2013年的核心交易链路就有几十条，牵涉到多个BU的几百号研发同学，这些业务链路绝大部分是没法直接压测的，需要进行相应的业务改造和中间件的升级。推动几百号人在短时间之内完成业务的改造在很多公司几乎是不可能完成的，何况还牵涉到中间件的升级，中间件的升级一般情况都会有一个相对比较长的周期，有不少业务系统的中间件版本都非常古老（5年前的版本），需要在确保无风险直接升级到最新版本。
在业务端我们需要对逐条链路进行一一梳理，从请求进来的系统到请求的最后一个环节（复杂的业务经过了几十个系统），每一个有阻压测流量往下走的地方都进行特殊的逻辑改造。改造的业务点牵涉100多个，包括登陆验证码、安全策略、业务流程校验等等。在基础设施和中间件上，我们需要让业务系统的代码尽可能的不需要修改、通用的技术通过基础设施和中间件来屏蔽掉，比如压测流量的标识怎么样在整个请求的生命周期中一直流转下去、怎么样来对非法的请求请求拦截处理。
参与全链路压测改造的每一个同学体现了良好的协作精神和执行力，为了同一个目标齐头并进、相互补位，原本认为几乎不可能的事情，最终在一个月内完成了相应的业务改造和中间件升级。
2）数据构造
数据构造有两个核心点：1、参与双11的买家、卖家、商品数量都非常庞大，需要构造同数量级的业务数据；2、需要确保业务数据的模型尽可能贴近双11当日 0点的真实场景，否则全链路压测结果的误差会比较大，参考的价值将会大打折扣。我们为此专门搭建了全链路压测的数据构造平台，对业务模型进行系统化的管理，同时完成海量业务数据的自动化构造。
数据构造平台以线上数据为基础，借助数据dump工具进行数据的抽取，并对关键数据进行相应的处理（脱敏、订正等）后进入到基础数据池供备用。基础数据池是压测数据的超集，具体压测数据的构造基于基础数据集进行数据的再加工。
除了需要有足够量级的数据以外，我们还要解决的另一个问题是数据的模型应该是怎么样的。借助BI工具结合预测算法对数据进行筛选建模，并结合每一年双11的业务玩法进行修订，产出一份最终的业务模型。业务模型的因子牵涉几百个业务指标，包含买家数、买家类型、卖家数、卖家类型、优惠种类、优惠比例、购物车商品数、bc比例、无线pc比例，业务的量级等等。
3）数据隔离
全链路压测要不要做数据隔离、怎么样来做数据隔离在项目立项阶段经过了非常多的讨论甚至争吵。在最开始的时候，我们想做逻辑隔离，直接把测试数据和正常数据写到一起，通过特殊的标识能够区分开，这个方案很快就放弃了：线上的数据的安全性和完整性不能被破坏。接下来我们提出了另一个方案，在所有写数据的地方做mock，并不真正的写进去，这个方案不会对线上产生污染，评估的时候也还是放弃了：mock对压测结果的准确性会产生干扰，而我们需要一个最贴近实际行为的压测结果。
经过反复的讨论，最终我们找到了一个既不污染线上、又能保障压测结果准确性的方案：所有写数据的地方对压测流量进行识别，判断一旦是压测流量的写，就写到隔离的位置，包括存储、缓存、搜索引擎等等。
4）流量构造
双11是一场剁手党的狂欢，0点的峰值流量是平时高峰的几百倍，每秒钟几百万次的请求如何构造同样成为我们的大难题。我们分别尝试通过浏览器引擎或者一些开源压测工具的方式来模拟用户请求，经过实际测试，要制作出双11规模的用户流量，流量器引擎和开源压测工具需要准备几十万台服务器的规模，成本是无法接受的，并且在集群控制、请求定制上存在不少限制。既然没有现成的工具可以使用，我们只好选择自己研发一套全链路压测的流量平台。
全链路压测的流量平台是一个典型的master＋slave结构，master作为压测管控台管理着上千个slave节点；slave节点作为压测引擎，负责具体的请求发送。Master作为整个压测平台的大脑，负责的整个平台的运转控制、命令发送、数据收集、决策等。slave节点部署在全球各地的cdn节点上，从而模拟从全球各地过来的用户请求。整套全链路压测的流量平台在压测过程当中平稳输出1000w＋／s的用户请求、同时保持过亿的无线用户长链接。
5）正式上线
在2个多月的时间里，项目组的成员披星戴月，有一半的时间在通宵，另外一半的时间凌晨3点以后下班。10月底的杭州，天气逐渐转冷，又是一个深夜，项目组的1位同学提交完代码像往常一样骑着电动车载着另外一个同学下班回家，路上一阵寒风吹来，骑车的同学直打哆嗦，想腾出一只手来拉拉衣袖，一个方向没控制好，砰的一声，两人从车上飞了出去，其中一位同学摔成了骨裂。正在大家为项目的进度担忧时，这位受伤的同学瘸着个腿又回到了项目室。
2013年的10月17日凌晨的1号楼，全链路第一次登台亮相，这一天对整个全链路压测项目组的人都意义非凡，辛苦了2个多月的“大杀招”终于要派上用场了！当压测开始的按钮被点下去，大家都全神贯注盯着各种系统等着流量上来，1分钟、2分钟过去了，我们的业务系统却丝毫没有流量进来。忙活了一晚上，第一次亮相狼狈收场，当时全场有200多号人，每一次让大家准备好却没有流量发出去的时候，面对着全场200多双眼睛，压测项目组每一个同学的手都是抖的。好在第一次的失败让我们吸取了充分的经验，又经过好几个昼夜的奋战，第二次的压测比第一次进步了很多，到了第三次就已经能完全达到我们的使用预期了。
3. 全链路压测2.0平台升级
全链路压测诞生之后为系统稳定性带来的改变立竿见影，2013年经过了几次全链路压测，双11 当天0点的表现比以往任何一年都平顺。全链路压测也在集团一炮而红，越来越多的业务希望能接入进来。
1）平台化
海量的业务接入给全链路压测平台带来全新的挑战：当时的全链路压测操作都需要压测项目组的同学来进行操控。随着越来越多的业务接入到全链路压测平台，压测项目组很快就成为了瓶颈，压测平台的能力急需升级，2015年，全链路压测“平台化”项目启动，我们着手将全链路压测朝着平台化的目标推进和实施，做到压测能力开放、业务方自主压测，让更多业务方能够享受到全链路压测的优势和便利。全链路压测平台化项目的上线大幅提升全链路压测平台的服务能力：2015年大促备战的3个月内，压测平台总共受理近600多个压测需求（比14年提升20倍），执行压测任务3000多次（比14年提升30倍）。
2）日常化
全链路压测的压测流量和正式流量经过的路径都是一致的，如果链路中某一个节点被压挂或者触发限流势必会影响线上用户的正常访问。为了减少影响，全链路压测一般都安排在凌晨，通宵达旦，非常辛苦！为了减少熬夜，提升压测幸福度，我们启动了白天压测的项目：将线上运行的机器动态隔离出一部分机器放到隔离环境中，这部分机器上只有压测流量可以访问，白天在隔离环境的机器上进行压测。隔离环境与线上环境几乎一样，从流量入口、中间件、应用后端实现完整隔离。隔离环境完全打通了配置中心、服务注册中心、消息中心、地址服务器等基础设施，不需要业务系统做任何改造即可完成，并且是直接从线上机器按照特定规则选择到隔离环境中，机型配置跟线上基本一致，使用完毕之后直接恢复到线上集群中，不会影响线上集群的容量。大促备战期间，我们可以白天在隔离环境中进行小目标小范围的全链路压测，用极小的代价提前发现问题。由于隔离环境场景相对于其他线下环境更加真实、操作快捷、不占用额外机器资源的特性，在预案演练、破坏性测试、线上问题排查、故障演练等其他场合也获得了比较广泛的应用。
4. 全链路压测3.0生态建设
2016年在三地五单元混合云部署架构下，电商一半以上的资源是部署在云上。在庞大的电商系统背景下，如何能够在最短的时间内完成一个单元的搭建和容量准备成为摆在我们面前的一道难题，而全靠“经验之谈”和人工介入是不可能完成的任务。2016年初，“大促容量弹性交付产品”立项，旨在减少甚至释放活动场景的容量交付中人工投入，并将大促容量交付的运维能力沉淀到系统中，使全链路容量具备“自动化”调整的能力。我们提出了大促自动化备战的想法，将大促容量准备的各个环节进行系统层面的打通，从业务因子埋点、监控体系、模型预测、压测数据构造、压测流量发送、压测结果分析、压测报表进行自动化的串联，大幅缩减了我们在大促容量准备阶段的人员投入和时间周期。围绕全链路压测的核心基础设施，全链路压测的周边生态逐步建立起来，打通建站、容量、监控等配套技术体系。
全链路压测在保障系统稳定性的同时，也为业务稳定性的保障提供了强有力的支持，在2016年我们落地了全链路功能测试、大促功能预演等一系列项目：创造性地在隔离环境提前将系统时间设置到双11 的0点。通过在这个提前的双11环境购买一遍双11的商品，进行充分的业务验证，最大限地度降低我们在双11当天的业务问题（将会在后面的章节中详细介绍）。
5. 总结
每年双11前夕，全链路压测都要组织好几次，不断地通过压测发现问题进行迭代优化、全方位验证业务的稳定性，我们的业务系统也只有在经过了全链路压测的验证之后才有信心迎接双11 那天0点的到来。全链路压测将大促稳定性保证提升到新的高度，是双11、双12等大促备战最重要的核武器，并且随着业务的发展不断进化，持续发挥着不可替代的作用。