最近几年全链路压测无疑成为了一个热门话题，在各个技术峰会上都可以看到它的身影。一些大型的互联网公司，比如阿里巴巴、京东、滴滴等，都已将全链路压测应用到了生产环境。
笔者曾有幸深度参与到阿里巴巴全链路压测体系的建设，以及与阿里内部其他技术团队、物流、社交电商、品牌企业等 CTO 或者 CIO 技术交流之后，关于如何保障企业数字化过程中的性能稳定方面，有了一个共识：全链路压测是建立 IT 性能管理体系的抓手和必选项。
1.什么样的公司需要全链路压测？
既然全链路压测功能这么强大，那如何确定自己的公司是否需要做全链路压测呢？
如果你的企业遇到过以下问题之一，就可以考虑引入全链路压测：
(1) 压力测试一直在做，但是每到大促活动，各种问题依然频繁发生；
(2) 需求正常迭代完成，并测试通过，上线后又出现各种各样的系统故障 ；
(3) 无法正确评估需要的机器资源，只能“重要的多给点，不重要的少给点”的经验之谈；
(4) 性能团队尽职尽责，但是性能问题依然层出不穷；
(5) 每次压测完的报告，看似内容详尽，但很多无法针对性的查出问题并给出解决方案。
也可以从场景层面来考虑是否需要做全链路压测：
1.1 新系统上线场景：
准确探知系统承载能力，防止刚上线被用户流量冲垮。
新系统上线一般会遇到以下两个问题：
(1) 新系统能够支持多大的并发流量访问，是否需要增加机器来满足用户流量
(2) 新系统性能是否满足预期，是否影响用户体验
这两个问题如果没有很好的解决会造成严重的影响，举个例子：某知名电商双十一推出一款网红产品的秒杀业务，想通过秒杀来吸引一波流量，结果双十一当天功能刚上线就系统宕机，消费者各种投诉、网上各种舆论，至此这家电商到现在在没搞过此类秒杀业务。
1.2 峰值业务稳定场景：
流量激增情况下，比如像双十一这样的大促，系统如果没有做好相关的准备，很容易被用户流量冲垮，导致公司业务受损，目前业内普遍通过全链路压测提前模拟流量激增场景，来增强系统的承载能力。
1.3 系统容量规划场景：
成本优化，对系统进行精细化的容量规划。无论是新系统上线还是大促场景，都会遇到容量规划的问题，目前容量规划更多是结合平常系统性能表现以及预计用户流量按照经验去规划，但这种规划一般无法做到精准容量评估，一种是评估多了，造成机器浪费，一种是评估少了造成线上故障，对业务造成影响。
1.4 系统可用性探测场景：
探测系统的可用性，提升系统的整体服务能力和吞吐量。全链路压测另外一个典型用场景就是通过模拟真实的用户流量压力，去探知系统的性能瓶颈，从而提升系统的整体服务能力和吞吐量，提升用户体验。
2.全链路压测可以给企业带来什么价值
2.1 保障重大活动的系统稳定性
避免公司业务和声誉因为技术故障受到损失，为技术团队赢得业务团队的尊重。
2.2 精准的容量评估
帮助公司用最低的成本满足业务的性能要求
2.3 重大项目重构切换前的性能验证
避免上线切换后持续的性能故障，快速渡过不稳定期。
系统重构是 IT 部门场景的技术更新的方法，每次上线都需要经历一段阵痛期，期间性能问题、业务故障频发，用户投诉频繁。
通过全链路压测可以在正式切换前完全解决性能问题；配合自动化的用例梳理和人工验证，可以极大程度降低业务故障。两者配合使用，可以快速的渡过不稳定期，提升用户体验。
2.4 端到端的全链路巡检，第一时间发现故障并快递定位问题
目前常见的监控体系都是通过一些间接的指标来判断是否有故障发生（比如通过 CPU 利用率、内存使用率、应用的错误日志数量、业务单量和基线的对比等等方式），间接的方式会产生大量的误报，造成告警麻痹症，真的故障发生后不一定能第一时间引起重视。
通过全链路压测提供的数据隔离功能，可以在线上通过压测流量验证真实的业务接口是否能正常工作。这种方式可以直接在用户发现业务故障前，相关人员第一时间知晓。配合链路的监测分析功能，快速定位问题应用所在。
该方法在客户真实环境中比传统监控方法平均提前 7 分钟发现故障，告警正确率是传统告警方式的几十倍。
2.5 建立公司的性能运营体系，将运动式的性能优化演化为自发的日常性能优化
很多公司都有运动式或者故障驱动的性能优化经历，比如马上要双十一，总监牵头开始性能优化；有人管的时候性能表现很好，一旦没人牵头做性能优化的事情，又会有很多性能问题被暴露出来。这样的方式通过优化效率很低，投入还大。
2.6 通过全链路压测的方式，配合目标制定、绩效和工单系统。
自动化的全链路压测可以日常化的排查性能瓶颈，通过工单将问题直达负责人，极大的提升性能优化的效率，将性能问题控制在萌芽状态。
3.全链路压测如何做容量规划
容量规划的工作，一般是由企业内资深的专家承担，这是一个复杂有难度的工作，需要熟悉系统、强技术能力、了解容量规划的方法等。
但企业即使有这样的人，也无法保障生产环境机器容量规划一定合理，主要原因是现在的系统业务和技术架构的复杂度已经远远超出了大脑能够掌控的范围，无法进行有效的容量评估。
既然无法进行有效的容量评估，那我们有没有什么新的工具和思路来解决这个问题呢？
数列科技的全链路压测产品解决这个问题的思路为：
(1) 通过系统当前的单机容量、依赖关系数据、业务的期望容量等数据，经过容量评估模型计算初始的容量
(2) 设置业务期望容量，通过全链路压测的方式验证容量是否合理
(3) 调整不合理的链路节点容量
(4) 重复 2、3 步骤，直至用最小成本可以达成业务期望容量
除此以外，基于产品化的全链路压测，可以进一步做到高频的日常容量评估和管理：
(1) 对资源不足的应用尽早增加资源避免用户体验较差的情况发生
(2) 对资源过剩的应用尽早削减机器，降低硬件和维护成本
另外目前市面上还有一些基于 AI 算法模型搭建的容量评估方案，比如数列科技的解决方案核心思路是将日常 IT 系统中各种性能数据进行收集归类，聚合分析然后建立对应的容量规划模型，之后就可以根据模型去做容量规划，然后使用全链路压测去验证，这样效果更佳。
4.如何确定业务核心链路的边界
如何确定业务核心链路一直是全链路压测前期准备工作的核心，这里需要注意的是：核心链路是指在精力有限的情况下，必须要保障好的链路，意味着需要投入更多的硬件资源、更多的工程师、出现问题是需要优先处理的。
核心链路不仅要考虑到技术层面，还需要使用自动的架构梳理能力来确定，因为人为梳理费时费力还容易出错。将详细的依赖数据清洗合并完成后，技术和对应的业务部门共同标记核心的业务功能点，再根据核心功能点和系统的依赖数据来确定最终的核心链路。
一般有符合以下三种情况的，可以考虑确定为核心链路：
(1) 链路出现问题会对企业业务造成重大影响的链路，比如对业务造成损害、品牌损害等
(2) 链路出现问题会对用户（如消费者）造成重大影响的链路，比如电商购物 APP
(3) 跟公司阶段考核（如 KPI）挂钩的业务链路，比如订单团队肯定要保障订单链路的稳定。
另外核心链路其实一直都在变化的，主要体现在：
(1) 系统功能一直在增加、修改，对应的系统依赖也必然变化，所以核心链路的边界也是变化的
(2) 核心链路是跟随业务场景变化的，比如在双十一前几年购物地址列表不是核心链路，因为大家双十一的购物习惯是给自己家买；这两年大家喜欢在双十一期间给父母和朋友买商品，于是切换购物地址就需要加入核心业务功能中。
5.如何构建全链路压测模型？
由于使用了影子库/表的方式，即使直接使用生产环境压测也并不代表能获得与真实业务完全一致的压测环境，里面还涉及到对压测数据模型的建立，要保证压测流量和正式流量保持 “一致”，影子库/表与生产环境保持“一致”，这里的“一致”包含几个方面：
5.1 数据量一致
通常是数据库，搜索索引等数据量的变化会导致响应时间变化的中间件，如果使用影子库来替代正式库，那么需要全量拷贝一份正式库的全量数据来保证压测结果，一些无法直接使用正式库数据的情况。
诸如新业务上线/正式库数据增减变化大/业务增长迅猛需要增加数据量等情况，则需要根据目标数据量以及业务特征构造压测数据来准备数据脚本。一些只读的链路涉及的库/表，可以根据压测时间/压测目的/压测量等因素评估是否可以直接使用正式库作为压测库。
5.2 数据分布一致
数据在使用的时候会有频繁访问/操作的热点数据，几乎不会用到的历史归档数据。两者在 mq/缓存/数据库的分布比例会影响接口的读写操作性能，需要根据生产的实际情况构建压测数据模型。
5.3 数据操作一致
对于缓存，定时处理的一些数据，构造数据的时候要注意数据失效/刷新/定时处理的批次和每批数据处理量的大小。
6.如何构造压测流量？
全链路压测需要最大程度的模拟正式业务环境下的流量，我们需要考虑到几个问题，比如请求数据如何构造，以及请求数据的多样化等。
举个例子，我们压测【下单】链路，需要尽可能模拟真实用户的下单情况，比如流量要与真实用户分布类似来自全国各地，以及购买各式各样的商品，还有访问下单的不同渠道，有时候甚至需要考虑用户的终端设备等。
目前数列科技 ForceCop 在构造压测流量主要有两种方式：
6.1 第一种人工构造
压测并发量不大的时候，比如并发只有几百，这种情况建议通过编写 sql 从数据库中导出一批线上数据，然后对这批数据进行清洗，去除敏感信息，比如客户地址、客户账号等信息，然后根据数据去准备压测脚本。
当压测并发量很大，比如并发上万，此时建议通过将数据同步到大数据平台，通过 MapReduce 任务的方式去清洗、导出数据。
可能有人会问为什么选择从线上环境导出压测数据呢？
因为真实业务数据代表的是真实发生的业务，数据之间的关系也已经生成，通过这种方式构造的压测数据能够最真实地还原业务场景并且构造数据的效率也能够大大提升。
6.2 第二种录制回放
录制回放就是收集某个时间段的正常业务数据，然后通过清洗敏感信息，最后加上压测标记去运行，达到最高程度的模拟正式业务场景，确保数据的真实性、多元化，以及场景覆盖的完整性。
7.压测如何构建监控体系？
全链路压测监控体系是由基础监控，应用监控、业务监控三部分构成。
7.1 基础监控
是指压测产品或者压测应用系统的集群基础性能监控，比如 CPU 性能、磁盘性能、网络性能等。
7.2 应用监控
是指从应用层对应用的性能、进行实时监控、分析，比如端到端链路调用节点性能情况。
7.3 业务监控
是指在站在业务角度的监控，它是由一些列业务指标构成，这些业务指标有特定的业务含义，比如 5 分钟内交易订单成功率持续为 0。
整个全链路压测过程中，开发人员在压力发起之后紧盯基础监控、应用监控、业务监控大盘，任何监控如有异常，第一时间执行对应的紧急预案，确保压测正常运行。
8.如何将全链路压测做到常态化？
全链路压测三要素，组织+产品+流程机制，三者缺一不可。
组织方面需要成立专门的压测项目组，核心成员主要包括相关业务负责人、压测应用技术负责人、运维、测试等。产品方面目前市面上有很多商用产品，但基本上产品模块包含压力发起模块、压测执行模块、压测监控模块。
压测发起模块主要核心功能是数据构造和压力发起，压测执行模块核心功能是数据隔离和压测执行，如果只是在测试环境去搞压测可以忽略数据隔离，但要在生产环境压测一定要注意数据隔离，目前市面上商用压测产品很多，但能做到安全数据隔离的产品很少。
压测监控模块主要包含压测产品自身性能监控和压测链路/应用性能监控，压测监控目前市面上很多这样的监控产品。
开源的比如 skywalking，pingpoint 在很多公司使用的还不错，基本上满足压测需求了，但如果要更加深度的监控信息，可以去选择一些商用产品。只有常驻的团队+稳定的产品+合理的流程制度才能将全链路压测做到常态化。
流程机制可以理解为全链路压测的实施 SOP，每个角色在压测的各个阶段的需要履行各自的职责，下面给大家看一下数列科技的解决方案大致流程如下图：
9.安全方面，如何保障数据的隔离性？
先来说说为什么需要做数据隔离，如果不做隔离会有什么风险？答案是数据不隔离会导致数据统计出错，还有对线上业务造成严重的影响。
那也有小伙伴会说，数据物理不隔离，业务系统兼容下不就可以了吗？
但其实业务系统兼容压测数据也是一种数据隔离，我们称之为“压测数据逻辑隔离“，IT 系统要实现这种逻辑隔离，基本上每一个接口都要针对压测数据进行工作量巨大的兼容改造，并且后续发布新接口或者修改老接口也需要持续兼容改造。
否则一旦某环节出现问题就会对系统造成重大隐患。因此我们在生产环境做压测，一定要做数据隔离，下面是我们数列科技的压测产品大体结构如下图：
ForceCop 的实现思路主要为以下三个步骤：
9.1 流量染色
构造压测流量时，将压测标记加入到压测流量中进行流量染色，比如页面发起的 http 请求，我们会在 http 请求的消息头里面加入压测标记。
9.2 压测标记传递
当压测流量流经业务链路时，会经过很多事先被植入过压测探针的应用。当压测流量经过这些应用时，会被应用里的探针识别出来，并且会携带这些压测标记继续传递下去。
比如压测流量经过 Dubbo 服务时，探针会把压测标记放到 Dubbo 的上下文中。
9.3 压测数据存储
压测流量最终会持久化到数据库、缓存、消息中间件等，当压测探针识别到压测流量要持久化，就会将压测流量持久化到对应的影子区域。
比如数据库会持久化到影子库或者影子表中、消息会写到影子 topic 中。
10.压测中如何调用部分链路或第三方外部链路的服务？
在全链路压测过程中会遇到很多场景，其中部分链路与第三方外部链路的场景比较典型，以我们数列科技实践过的案例得出以下结论：
10.1 部分链路压测
部分链路压测是指整条链路中因为特殊原因某一个应用不能参与压测，比如遇到负责这个应用的团队忙于业务需求，暂时无法参与压测，遇到这类型情况怎么去落地压测呢，我们一般会采用挡板+后期压测的套餐来解决。
挡板其实就是常说的 mock 功能，如下图所示，【应用 2】因为特殊原因不能参与压测，但【应用 1】和【应用 3】不能因为【应用 2】不参与就不能压测，在调用【应用 2】处增加挡板就可以顺利保证其他应用正常压测，未来【应用 2】可以做压测时，去掉挡板，统一进行压测就 ok 了。
10.2 外调链路压测
外调链路压测是指压测链路中涉及到调用其他供应商提供的系统，比如第三方支付或者一些短信服务之类的，如果第三方愿意配合，我们就按照正常压测去进行就 ok，但一般情况下第三方不太愿意配合，遇到这类型场景，我们怎么解决呢？
这类型场景我们会采用挡板的套餐来解决，将调用第三方的接口 mock 掉，模拟第三方的耗时以及返回结果来确保压测能够正常进行，比如像支付宝这样的支付服务，支付宝肯定不会配合我们去做压测，我们只能通过挡板去模拟压测。
