当业务越发复杂、系统规模越来越大，以及外围资源依赖得越来越多时，系统中可能存在的各种不确定性因素也会随之被放大，甚至一个细微的错误都有可能导致交易系统出现雪崩。因此压测成为开发人员在大促前夕检测系统短板、瓶颈最有效的手段，为相应的风险点制定出有效的预案，才能够避免大促时不被那些不确定性因素所带来的影响打个措手不及。
验证系统所能够承受的最大负载是否接近于预期，是否经得住大流量的冲击，绝非是一件易事。有过分布式系统开发经验的同学都应该非常清楚，简单对某个接口、子系统进行压测，并不能够准确探测出系统整体的容量水位，这是由分布式系统与生俱来的复杂性决定的，并且对环境、目标都有着极为严苛的要求。近些年，全链路压测似乎备受追捧，基本上各大互联网企业，比如：阿里、京东等都会在大促前夕利用自研的“军演系统”在线上进行压测实战演练，其目的就是确保大促来临时核心链路的整体稳定。本章笔者会重点为大家介绍，笔者所在企业是如何在大促前夕对线上环境实施全链路压测，以及如何做到有指导的在大促前进行容量规划和性能优化，让系统坚如磐石。
1.1 为什么要在线上实施全链路压测
在为大家介绍本章主题之前，请大家首先冷静思考下，大促前夕我们需要考虑哪些事情？或者说有哪些事情是必须要做的，尽可能做到心中有数，不打无准备之仗。笔者总结了大促前夕最基本，同时也是最棘手的2项备战任务：
● 评估机器扩容数量，
● 验证系统整体容量是否能够有效支撑所预估的流量峰值。
大多数互联网电商平台在刚开始的时候，由于流量不大、机器数量不多、以及经验上的匮乏，评估需要扩容多少台机器来应对突增的活动流量，往往采用的做法都是非常“简单粗暴”的，那就是不管三七二十一，脑子一拍，以平时的机器数量为基数横向扩容十几倍、几十倍。但随着用户规模的线性上升，这种评估方式必然是不可取的。
首先，大促产生的流量峰值必然是平时的几十倍，乃至上百倍，待库存消耗完后，流量会急剧回落至正常水平，换句话说，峰值的持续时间并不会太长，对于一个稍微有点规模的电商企业来说，日常运维的服务器数量都会维持在近千台左右，如果还是按照这种方式来评估活动时所需的机器数量，必然会造成许多不必要的资源浪费（一些外围系统只需要少量扩容，因为压力主要都集中在核心链路上）
其次，存储系统的伸缩成本是非常“昂贵”的，并且很多服务的扩容数还受限于底层连接资源，因此务必需要采取一种更为合理的评估方式。那么应对大促时的机器数量究竟应该如何评估呢？简单来说，我们首先应该梳理清楚整个业务系统中哪些才是真正的核心链路，然后得出单机的最大容量，并根据活动的GMV（成交额）来推算出理论上需要扩容的机器数量。在此大家需要注意，推算出来的理论值，还需要进行充分的验证，接口的短板效应绝对不是靠评估出来的，只有当系统整体的负载处于较大压力时才会暴露，比如：慢速SQL、连接资源耗尽等。
根据活动的GMV推算出理论上需要扩容的机器数量后，最好的验证方式就是压测，因为只有在系统经历过实际压测后，我们才能够清除系统整体的真实容量水位，接口的短板效应也只有在压测后才能进行有效规避。
笔者所在企业的全链路压测之路走得还是比较艰辛的，从最初纠结用什么压测工具开始，到单链路压测、中间件压测，以及存储系统压测等一步步摸索，并借鉴其他友商的经验和方案，直至现在，我们才最终在黑暗中摸索出了一条属于我们自己的全链路压测之路。2017
年的“双11”前夕，整个研发、运维团队处于紧急战备状态，从9月份开始，我们利用自研的“军演系统”Titan总共发起了超过10次线上全链路压测，除探测出系统的真实容量水位外，还挖掘出业务系统的性能瓶颈近 30处，成功做到了有指导地在大促前进行容量规划和性能优化，让系统坚如磐石。当用户规模较小时，开发和测试同学随便在线下环境做一把功能测试，只需要确保系统具备可靠性（检验系统是否能够无差错地执行预期的操作）即可，但随着用户规模的线性上升，流量会越来越大，这时再光依靠常规的功能测试已无法满足，流量上来了，就必须重视系统性能了，毕竟谁也不希望自己的系统被流量无情击垮而导致低可用性。
因此到了这个阶段，大多数企业都会选择在线下对各个子系统、中间件、存储系统实施压测，明确其吞吐量，但是因差异性问题，这样的压测结果数据，与线上还是有较大差距的，毕竟绝大多数企业的压测环境并不会按照线上环境的机器数量1：1扩容部署，所以线下环境的压测结果数据基本上仅供参考，并不能够作为线上环境的指导数据，只有直接在线上环境实施压测才是唯一的明道。这里为大家分享一下早先笔者所经历的一次真实线上事故，某次大促备战前夕，由基础架构团队牵头给出系统所有核心链路的限流阈值，但是负责线下压测的相关同学，由于没有仔细核对线上环境和线下环境订单服务的 MySQL 数据源配置（线上环境maxWait参数设置不合理），且过于乐观地评估出订单服务的容量水位，可想而知，给出的限流阈值必然会带来灾难性后果；果不其然，活动开始后没多久，监控系统开始频繁告警，DBA 首先按捺不住了，从监控系统中明显可以发现某些订单子库的连接资源几乎消耗殆尽，而订单服务中获取不到连接资源的线程长时间“hang”住，部分订单服务完全瘫痪，上下游逐层影响，最终产生雪崩，导致部分用户无法顺利完成交易。正是吸取了这次事故的惨痛教训，更加坚定了我们要在线上环境实施全链路压测的决心。
直接在线上环境实施压测是一件非常危险和困难的事情，决不能出现一丝失误。大多数情况下，我们的业务系统都是有用户在正常进行访问的，尤其是高峰期时绝不能因为压测流量导致系统故障从而影响用户下单，更不能够污染线上数据。试想一下，某个用户的订单信息中，突然多出来10台iPhone X，你是送还是不送？或者余额突然变少了，都是用户绝对不能够容忍的，并且线上环境往往还会伴随着各种定时任务，统计的时候如果把压测数据也计算进收益中，运营部门的老大估计会请研发同学喝茶。
尽管困难重重，但是要探测出线上系统的真实容量水位，只有此路通罗马。因此系统需要做到能够智能化到准确无误地区分出哪些数据是真实用户流量，哪些是压测流量，笔者会在后续小节中为大家重点介绍线上实施全链路压测的 4 个关键核心点：
● 业务系统、中间件如何配合改造升级；
● 如何将压测数据引流到隔离环境中；
● 压测数据如何构造；
● 超大规模的压测流量如何发起。
那么究竟什么才是全链路压测呢？在笔者回答这个问题之前，大家首先需要明确一点：系统中任何一个接口都不会独立存在，假设A接口可以压测出1w/s的QPS，那么当A接口和B接口同时施压时，A接口的QPS势必会下降，原因其实很简单，因为受限于一些共享资源；简单来说，全链路压测其实指的就是在特定的业务场景下，将相关的链路完整地串联起来同时施压，尽可能模拟出真实的用户行为，当系统整站流量都被打上来的时候，必定会暴露出性能瓶颈，才能够探测出系统整体的真实容量水位，以及有指导地在大促前进行容量规划和性能优化，这便是线上实施全链路压测的真正目的。
1.2 业务系统如何区分压测流量
在为大家介绍业务系统如何区分压测流量之前，我们首先来谈论一个研发同学都比较关注和敏感的话题，业务系统是否需要配合进行相应的改造升级，明确告诉大家，一定程度上会，因为对于线上所有的写接口来说，基本上是没有办法直接进行压测的，并且全链路压测任务并不会在业务初期就推动，一般都会选择在业务中后期才实施，尤其是当业务越来越复杂的时候，改造的难度和成本就会越大。但是企业的基础架构团队应该意识到，绝大多数的改造工作都应该是在中间件、组件中完成，尽量避免对业务系统产生较大侵入，应该尽可能为研发同学提供便捷，让其更专注于自身业务逻辑。我们在实施全链路压测改造的时候，通过对业务进行逐一梳理，发现涉及的业务改造点居然达上百个之多，基本上业务系统的核心链路全部都需要配套进行改造。从最初的方案探讨到改造完成，基础架构团队基本上投入了全部的兵力，且涉及相关业务改造的研发同学更是不胜枚举，总共花费了接近半年的时间（毕竟研发同学不可能完全专注于压测改造，每天还需要处理线上问题，以及忙于实现各种应接
图2-1 线上全链路压测总体设计
不暇的业务需求），才最终完成了对相应业务系统、中间件，以及组件的改造升级任务。
1.2.1 压测流量打标方案
线上业务系统如果想要准确区分出真实用户流量和压测流量，那么就必然需要对压测数据进行特殊标记，并且这个压测标记还要能够顺利在一次请求涉及的所有后端服务调用的上下文中进行传递，当最终数据落盘或者调用第三方接口的时候，才能够做到不影响和污染线上数据，如图2-1所示。
对压测数据进行打标的方式有许多种，本书笔者列举了 2 种最常见的方式，如下所示：
● 在URL上进行打标；
● 在HTTP的header中进行打标。
假设在URL上进行打标，如下所示：
当在URL上添加打标参数（st=true）并向后端业务系统成功发起请求后，如果业务系统检测到请求中已包含压测标记，那么就会把压测标记在一次请求的整个生命周期中一直流转下去。除可以选择在 URL 上进行流量打标外，在 HTTP 请求的header中打标似乎也是一个不错的选择。当然，具体选择哪一种流量打标方式，大家还需要结合自身业务场景而定。
1.2.2 在链路上下文信息中传递压测标记
在上一个小节中，笔者为大家介绍了如何对压测流量进行打标，以便有判断依据能够让业务系统区分出哪些是真实用户流量，哪些是我们的压测流量，当真正在线上进行压测时才不至于把压测流量误当做正常流量从而污染线上数据。对压测流量进行打标的方式非常简单，无论是直接在URL上进行打标，还是选择在header中进行打标都是可行的，判断一次请求是否是压测流量则需要在接入层就开始处理，如果检测为压测流量，当调用下游服务时，就需要能够顺利把压测标记在一次请求的整个生命周期中一直流转下去。
大家思考下，流量区分和压测标记传递等任务应该如何在业务系统中实施配套改造升级呢？或许有的同学认为这并非是一件难事，只需要在业务代码中稍微调整下，加上几个条件判断语句即可。尽管这种方式理论上可行，但是几乎没有任何一家互联网企业会选择采用这种方式来适配全链路压测改造，抛开成本问题不谈，最棘手的问题就是连负责相关业务的研发同学都没有完全的把握能够确保所改造的代码逻辑不存在任何遗漏，要知道核心链路所牵涉的业务改造点可谓多不胜数，一旦压测标记在向下传递的过程中出现了中断，这将会导致非常严重的后果，整个研发团队都难辞其咎。
笔者之前曾经说过，对于线上所有的写接口来说，基本上是没有办法做到直接进行压测的，所以实施全链路压测，业务系统必然需要配合相应的改造升级，但这并不代表需要业务系统经历“伤筋动骨”的改造方式，既然此路不通，那么还有什么更好的办法吗？为了避免高侵入性问题所带来的困扰，业界通常采用的做法是直接在中间件、组件中动手脚，将流量区分和压测标记传递的任务交由具体的中间件、组件来负责，业务系统中唯一需要配合改动的就是对所依赖的相关中间件、组件版本进行升级即可。
既然是通过改造升级中间件、组件来处理流量区分和压测标记传递等任务，那么究竟应该改造哪些具体的中间件会比较适合呢？既然一次请求中涉及的所有后端服务调用都能够被完整地串联起来，那么在分布式调用跟踪系统中进行相应的全链路压测改造升级就显得顺理成章。
简单来说，我们采用的做法是，当对业务系统发起一次HTTP请求调用时，嵌套在分布式调用跟踪系统中负责流量区分的拦截器会优先对请求进行拦截，然后尝试从URL或者HTTP的header中获取出压测标记，如果确认为压测流量，就将压测标记放进当前线程的ThreadLocal中，待调用下游服务时，再从中获取出压测标记并放入Dubbo的RpcInvocation中，逐层向下传递即可。全链路压测改造任务不可能一帆风顺，业务代码中存在的一些不确定性因素很有可能会在改造过程中随时向你投递一些“彩蛋”。我们在一条核心链路改造完成的一次联调过程中发现压测标记向下传递的过程中产生了中断，经过排查后发现，业务代码中存在通过直接创建线程的方式异步发起RPC请求，这样一来，子线程便无法获取到父线程设置在ThreadLocal中的压测标记等信息。
在此大家需要注意，程序中如果直接使用 new Thread（）的方式创建线程并发起异步 RPC 请求，应该使用ThreadLocal 的派生类 InheritableThreadLocal，如果采用线程池的方式，那么可以使用阿里的TransmittableThreadLocal 来替代JDK原生的ThreadLocal，并设置相关环境变量，如下所示：
1.2.3 外部第三方接口走Mock
诸如短信、物流，以及支付等一些外部第三方接口，实际上并不在压测范围之内，如果我们不对这些外部接口进行统一的梳理和屏蔽，那么在线上实际的压测过程中，将会产生一些不必要的影响。以短信接口为例，这种按量付费的外部接口，完全没有必要对其下血本进行“狂轰乱炸”，而且我们大部分时间根本不会关心这些短信内容。本书中笔者所提及的外部接口调用屏蔽方式，其实指的就是将压测流量引流到Mock服务上，避免直接与外部第三方接口产生实际交互。
先来说一下我们最初的做法。当业务系统需要调用外部接口时，嵌套在分布式调用跟踪系统中的 MockFilter 会对其进行拦截，如果检测为压测流量，则匹配目标接口是否是外部接口，匹配规则可以直接在配置中心内添加黑名单设置，如果满足匹配，就直接调用Mock服
务，Mock的具体返回结果同样也可以在配置中心内设置，如果压测流量较大，运维同学仍然需要扩容较多的Mock服务来支撑压测请求，由此可见 Mock 服务的运维成本相对还是相对较高的，因此我们不得不对此方案进行改进，不再单独部署相关的Mock服务，而是直接将Mock 逻辑封装在MockFilter内，除可以避免网络损耗提升压测质量外，更重要的是，有效控制住了成本开销。如图2-2所示。
图2-2 Mock调用流程设计
1.2.4 压测数据的隔离方案
之前笔者曾经提及，直接在线上环境实施写压测是一件非常危险和困难的事情，除会对当前正在访问系统的用户产生影响外，还可能存在污染线上数据的风险。前者可以通过低峰期解决，也就是选择在一个对用户影响较小的时间区间内进行，而后者则成为摆在架构师面前的难题，同时也是业务系统配合改造升级的重点和难点。
我们当初在设计压测数据的隔离方案时，考虑了物理隔离和逻辑隔离2种方案，前者的优点很明显，但缺点就是增加了运维成本，加重了企业的负担。我们线上存储系统的规模是比较庞大的，如果全部都按照1：1的方式扩容出一套影子库出来，这几乎不现实，而且在非压
测时段这些扩容出来的资源纯粹就是一种浪费。因此，出于我们自身的业务特点，以及成本问题等多方面的综合因素考虑，最终选择了采用逻辑隔离方案来解决线上数据污染问题。
对于那些真正需要落盘的数据，以MySQL为例，我们选择了在同一套生产库实例下新建一个影子库来存储压测数据，避免定时任务在统计的时候把压测数据也计算其中。而对于那些中间数据，比如写入Red is、消息队列中的每一条压测数据，都会统一加上特定的压测标识，并设置较短的存活时间，让其自动失效。在此大家需要注意，由于压测流量请求的是线上存储系统，因此底层连接资源的占用、释放等问题需要重点关注，千万不能在压测已经结束了，仍然还影响正常的用户访问。在解决这类问题时，我们的思路是，服务启动时避免触发数据源的“init-method”属性，当真正执行压测时再建立会话连接，而且“minEvictableIdleTimeMillis”、“timeBetweenEvictionRunsMi llis”，以及“minIdle”等属性也需要合理设置，最终要保证的就是快速释放压测资源所占用的线上资源。
大家思考下，DAL 层应该如何将压测数据正确路由到影子库上？一般而言，这一块的改造工作最好是优先选择在数据库的Proxy层上进行，通过改造分库分表中间件来解决路由问题。其次，大家还可以通过扩展Spring的AbstractRoutingDataSource类来实现一个特定的动态数据源，并重写其determineCurrentLookupKey（）方法，在该方法中嵌入路由逻辑，如果检测为压测数据，就返回影子库的数据源，反之就返回线上数据源。
1.3 如何发起大规模的压测流量
在前面几个小节中，笔者为大家介绍了什么是全链路压测，以及为什么需要在线上环境实施全链路压测，并着重介绍了业务系统及相应的中间件、组件应该如何改造升级来适配全链路写接口压测。那么接下来，我们再来看看如何模拟出超大规模的压测流量来对线上系统实施全链路压测。
在单链路压测场景下，可选择的压测工具可谓是不胜枚举，比如：Apache JMeter、Apache AB，以及Gatling等都是开发、测试同学非常熟悉和常用的。但这类压测工具实际上都是通过单机部署，使用多线程或多进程方式模拟出并发用户数来进行施压的，以Apache AB为例，瞬间能够发起的压测流量实在有限，根本无法模拟出贴近真实线上环境的峰值流量。
实际上，笔者所在企业在最初的时候，全链路压测的构思还并不成熟，只是希望能有一种压测工具能够支持集群打量，所以后来我们也调研过nGrinder，相比较而言，nGrinder确实可以在一定程度上满足分布式压测需求，支持部署多Agent的方式提升压测流量，但是介于它的Controller存在瓶颈，能够管理的Agent数量实在有限，以及对场景化需求的支持过于薄弱，因此我们最终决定开始自研适用于我们自身业务场景的全链路压测军演系统Titan。
1.3.1 数据构造平台
毋庸置疑，压测数据可以说是整个全链路压测体系中的核心，这关系到影子库中的测试数据应该如何构造，以及下发给压测引擎的请求参数文件应该如何组装。早期笔者在研发Titan时，并没有构建数据构造平台（即数据工厂），每次压测摸底前夕，测试同学几乎都是以纯手工的方式来组装目标场景所需的一系列压测参数，再保存在文件中的。显而易见，这样的效率非常低下，不仅需要花费大量的时间成本和人力成本，最悲剧的还是某些特殊参数还未使用却失效过期，一旦出现这样的情况，又需要花费测试同学大量的时间和精力去重新组装，着实令人头痛。依稀记得在某次大促压测前夕，我们有几十个待压场景，预计是在凌晨零点开始施压，结果从下午的5点开始，直至半夜11点压测参数都还未完全组装完成，其痛苦程度不亚于抄送一遍奥斯特洛夫斯基的《钢铁是怎样炼成的》；
除需要手工组装压测参数外，影子库中的测试数据（比如：测试店铺、测试商品等）也同样需要手动一条条刷进去。在经历了那段苦不堪言且不愿回首的石器时代，我们终于在2018年的“双11”备战期间实现了“四个现代化”，走上自动化道路，数据构
造平台孕育而生，如图2-3所示。
图2-3 数据构造平台设计
数据构造平台的3个核心任务：
● Dump线上数据，经历脱敏、修正等阶段后导入数据池；
● 负责将测试数据落盘影子库；
● 根据目标场景导出相应的请求参数文件。
我们的压测数据来源是直接Dump的线上库、Nginx等数据源，在把这些真实用户数据导入数据池之前，会先把这些数据中包含的一些敏感数据（比如：电话、地址等）进行脱敏、修正，最后才会把这些加工后的数据导入数据池中以供备用。当需要执行压测时，再根据具体的目标场景，将测试数据刷进影子库，以及下发给执行引擎所需的压测参数文件。
1.3.2 自研全链路压测军演系统的一些经验分享
如果现有的技术或框架不能有效满足业务需要，才需要从“拿来主义”的消费者角色转变为自行研发的生产者角色。毕竟在融合了高度开放、分享的互联网当下，真正需要我们从零开始自研的框架或中间件真的不多了，因为当下你能够遇见的问题，别人早已经历过且提供相应的解决方案，所以在非必要的情况下，将时间投入业务系统的重构上，不断减少系统的“熵”似乎更有意义；反之放手去做，但务必牢记，一定不能脱离业务。据笔者了解，饿了么技术团队的全链路压测体系中，压测引擎并非是自研的，而是使用的JMeter集群。总之，只要能够满足业务需要，选择往往就是正确的。
如图2-4所示，
图2-4 Titan 2.x整体架构
Titan的整体架构主要由5部分构成，Manager作为管理控制台，主要负责链路和场景的管理；TaskService 负责压测任务的编排，以及压测流量的下发；Agent作为施压节点，其任务就是对业务系统实施压测；Detector作为水位检测器，用于采集相关业务系统的监控指标数据，以及RT和业务失败率，以便在压测流量达到临界水位时自动干预压测流量的下发；DataCollect 用于收集各个 Agent 节点的压测数据合并上报。压测编排和任务下发都是由TaskService负责，由于笔者所在企业使用的RPC框架为Dubbo，所以TaskService和Agent之间的通信也是基于Dubbo的RPC调用。
假设我们需要对某个目标场景实施压测，TaskSer vice首先会执行任务编排（比如：任务ID分配、任务内容分配，以及空闲Agent调度等）；待任务编排结束后，TaskService会更改目标Age nt所在注册中心内的当前状态信息，当Agent感知变化后，会主动向Ta skService 拉取任务，TaskService 节点越多，压测前的预热工作就会处理得越快。压测参数的下发则是由数据构造平台来负责，由于数据构造平台在上一小节笔者已经为大家详细介绍过了，所以就不再继续阐述了。
压测引擎或许是大家最关心的一个话题。Titan的压测引擎并没有什么特别之处，针对HTTP接口，我们最初采用的是Apache HttpCompon ents包下的同步HttpClient，基于多线程模拟并发用户数的方式来对线上业务系统施压，这一点和JMeter、Apache AB等常规压测工具的做法类似。但存在一个问题：假设总并发用户数被设置为10W，当下游接口的处理速度较快时，接入层每秒接收的请求数会远高于此。我们在实际的压测过程中发现，并发用户数虽然只有10W，但压测时，峰值QPS达到了近100w/s，影响了我们对流量的评估。因此，在重构Titan 2.x版本时，我们选择了采用Java11的异步HttpClient来发起HTTP请求，不再采用多线程模拟多并发用户的方式发起流量，并在 Agent 端做好了相应的流量管控，抛开上/下行带宽等因素，可以做到期望流量与实际流量基本持平。
在此我简单对Java 11提供的HttpClient的基本使用做一个介绍。HttpClient的使用非常简单，除支持同步和异步两种编程模型外，还支持HTTP/2协议，甚至开发人员还能够以Reactive Stream的方式来处理请求/响应的主体。HttpClient的使用示例，如下所示：
当压测流量超出系统安全水位时，监控系统一定是红灯常亮，告警短信、邮件不断，为了避免线上业务系统发生雪崩，运维同学往往会要求流量达到临界水位时停止继续施压，但通过观察监控来手动停止压测流量的下发往往存在一定的滞后性，这就好比载货行驶的大货车，突然急刹车往往也会因为惯性作用而导致车辆继续滑行很长一段时间。如图 2-5 所示，为了确保线上系统不会被压测流量击垮，我们将Titan 和立体监控进行了联动，并加入了水位检测器，一旦压测流
图2-5 安全水位检测机制
量超出线上业务系统的安全水位时，便会迅速自动干预压测流量的下
发。
早在2017年的上半年，笔者曾尝试在GitHub上开源过Titan的1.x 版本，实际上，当时的版本还并不完善（比如：管理界面丑陋、压测引擎不稳定，统计结果不准确等问题），在吸取了社区诸多好的建议后，我们的架构团队开始大刀阔斧地对Titan进行重构升级，使之简单易用、稳定高效。目前，Titan 2.x版本已经脱胎换骨，整个平台都已经越来越完善，关于新版本的Titan在后续将会有开源计划。
1.4 本章小结
本章笔者着重为大家介绍了企业为什么需要实施全链路压测，以及在实施全链路压测过程中业务系统、中间件，以及相应的组件应该如何配套改造升级，如何有效避免压测流量污染线上数据。在本章的最后，笔者还为大家分享了自研军演系统的一些经验，希望大家能有所裨益。