3.2 全链路压测
相对于全链路压测而言，本书前面介绍的测试应该称作单点单链路性能测试。也就是说，之前讲解的性能测试中，每一个性能测试都是针对某一个业务场景的单链路测试，测试过程的所有并发用户都使用一个业务流入口，而全链路压测会涉及多个核心业务、多个访问入口。
3.2.1 全链路压测的本质
全链路压测是一个解决方案，并不仅仅是一项技术。全链路压测最早是阿里巴巴为了保障类似于“双十一”这样的大型促销活动（简称大促）的稳定性而提出的一种验证手段。为了理解全链路压测，要先细分一下不同性能测试场景中的压力测试方法。
1．单点单链路压测
单点单链路压测是非常原始、传统的压力测试场景构造方法。假设有对拉勾教育系统进行性能测试的需求，那么测试工程师会先站在用户访问的角度，找出访问量比较大的业务流程，然后为每一个业务设计压力测试场景，并进行测试，如图3-17所示。
图3-17 需要性能测试的业务流
当接到性能测试任务时，首先会选取访问量较高的两个流程，然后分析访问量，通过访问入口的Nginx得到各个流程中访问量的峰值，并使用该峰值进行压力测试。假设购买课程流程的峰值为5000，学习流程的峰值为3000，则设计的压力测试场景分别如图3-18和图3-19所示。
图3-18 购课流程的压力测试场景
其中，CSTX_LA0001测试用例中，单击“加入学习”按钮后，线上流程中跳出支付控件页面，而测试环境中直接使用MOCK服务替换掉真实支付环节。从上面的设计中可以看出，每一个业务流程都是通过单一入口、相同的并发量完成课程购买流程与学习流程的性能测试的。
图3-19 学习业务的压力测试场景
2．混合场景压测
单点单链路压力测试场景设计是传统性能测试中的主要工作内容，但是除此之外还存在多点单链路压测，只是这里不称多点单链路，而称作混合场景。
还以购课流程为例进行介绍，假设通过链路跟踪对购买课程中5000人并发访问的数据做进一步的分析，发现这5000人中有1800人在访问首页，1200人完成了登录，1000人在选课页面浏览课程列表，800人在访问课程详情页，200人完成了购买。性能测试的混合场景压测按此比例进行设计并测试即可，如图3-20所示。
图3-20 混合场景压测
3.2.2 全链路压测是技术驱动的测试
上面讲的两种方法都无法满足电商在大促时段的并发访问模型。在电商大促开始的时刻，大量流量会涌入系统，要验证系统是否能够承受住如此大的访问流量，需要对系统的全部服务层、数据层、缓存、消息队列、中间件等做整体验证。在大流量的突发性访问之下，任何一个环节的薄弱点都可能成为压死骆驼的最后一根稻草。这促使了全链路压测的出现，它通过最真实地模拟大促类访问时段的流量访问，验证系统的可靠性。换句话说，全链路压测就是一次大促访问行为的模拟演练。要推行全链路压测，就要先完成内部的技术支持。
要为全链路压测做好准备，就必须完成下面两方面的任务。
全链路压测平台的准备：要有能够完成压力测试场景的配置、流量的生产、数据的颜色设置、系统风险的预警等功能的技术平台，以按照实际访问业务流和实际场景为系统制造压力。
系统的改造：全链路压测是在生产环境中进行的，不能让压力测试影响真实用户，所以需要对系统进行技术改造，以完成流量隔离，使系统能够区分是压测的流量还是真实用户的流量。
这些工作主要分为三大部分：一是压测管理，二是隔离，三是风险预警。
1．压测管理
一般全链路压测是以客户入口为起点的，所以目前全链路压测的流量计算从截获一段时间内实际用户的访问流量开始。
对于线上数据，首先要脱敏。将一段时间内的线上数据脱敏后存储到本地的数据存储服务中，这样当需要要做压测时就对截获的流量进行一些处理。这些处理主要用于为流量添加一些标记，通过这些标记让系统可以快速识别出哪些流量是压测产生的，哪些是真实产生的。
打标的常规做法就是在某一不重要的部分加入一个特别标记，例如，对于HTTP，一般在访问头信息中加入一个特别标记，这主要借助HTTP的自定义头实现。自定义专用消息头可通过“X-”前缀添加，RCF6648中已不再建议使用自定义头，原因在于未来非标准头字段被标准化时容易引起一些疑惑。
因此，在全链路测试中，我们仍然可以使用自定义头来完成压测流量的标记，这个处理也称作流量颜色。被上色后的流量按照已经设定好的压测场景，通过不同地域、不同机房下发到系统中之后，就完成了压力的改造和测试工作。
2．隔离
隔离指数据隔离和服务隔离。因为在压测过程中会对生产系统中绝大部分的服务产生访问行为，所以就会有大量的数据要存入数据层中，但是这些测试数据不希望污染生产数据持久化层。因此，要有隔离方法，能够实现数据隔离及某些特殊服务的隔离。
在全链路压测方案中，数据隔离是通过建立影子数据层来实现的。这种影子数据层的建立主要有两种方法：一种是使用独立的数据层服务，另一种是使用打标的数据存储。
独立的数据层服务就是建立一套和生产一模一样的数据层服务。在进行系统技术改造时，在业务层和数据层之间添加一层代理，将有压测标记的业务数据存入影子数据服务中，将没有标记的业务数据存入生产数据服务中，这样就在代理中完成了数据的分流处理。这种方式比较适合数据库、Elasticsearch等。
针对不同的存储类型，在全链路压测的落地实践中推荐使用不同的影子库搭建方式，例如，数据存储在MySQL中，在同一个MySQL实例、不同的Schema中创建一套和线上相同的库表结构，并且把线上数据导入进来。如果数据存放在Redis中，为压测流量产生的数据添加统一的前缀，并存储在同一份存储中。
还有一些数据会存储在Elasticsearch中，这部分数据也可以存放在另外一个单独的索引表中。数据打标指将有压测标记的流量数据以统一加上某一个前缀的形式存入与生产数据相同的数据层服务中，以方便区分是压测数据还是生产数据，这种方案比较适合Redis、HBase等数据层的服务。
服务隔离这里其实是指MOCK服务，MOCK服务是解耦服务的一种，与很多其他服务统称为测试替身（TestDouble）。
全链路压测中的“全”字的意义并非指整个系统，不能一味地确定那个“全”字的覆盖范围，在现实情况中有很多请求必须使用测试替身服务，否则会对真实用户或系统产生影响。例如，浏览商品并下单、购买时，若不能付费，就必须调用MOCK服务完成业务流，而且合作的支付方公司也不会同意直接把压力施加到他们公司的服务上，就算合作方同意，那做一次测试又要花多少费用呢？
需要服务隔离的另一种情况就是访问数据影响结果的功能，例如，功能模块的埋点收集服务，如果全链路压测过程中增加了某些模块的访问次数，而这些模块的访问次数会通过埋点返回分析系统中，那么全链路压测过程中就要利用测试替身服务替换埋点服务，从而避免压测过程为分析服务引入大量的噪声。
还有一种情况就是一次性服务，即系统中有相同主键不能重复处理的流程。例如，对于抽奖系统，如果在全链路压测中使用用户的账号抽完了奖，那么真实用户访问时就没有资格再次参加了，这就影响了真实用户的反馈，所以抽奖服务也要使用测试替身完成对应服务的解耦。
3．风险预警
全链路压测最后必不可少的是风险预警。全链路压测是在真实生产环境中运行的，虽然测试人员会在系统的低谷期进行测试，但是仍有真实用户在使用系统，所以在实施全链路压测时，一定要有一套完善的监控和预警机制。在测试过程中如果监控指标超过安全水位，应立即报警，以便快速对压测进行调整。
全链路压测最近几年名声大噪，电商平台中的购物节运营策略是针对系统中超大规模的瞬时并发访问制定的。全链路压测是一个由研发人员、测试人员、运维人员群策群力的实践方案，并不是某一个工具、某一个角色能独立完成的。最重要的一点就是并不是每一个业务形态都需要全链路压测，要站在正确的业务视角选择正确的测试技术。
