本文关于性能测试能力提升-全链路压测，实施全链路压测的关键点有哪些？

一、背景

什么时候开始考虑做全链路压测

全链路压测方法

二、什么时候开始考虑做全链路压测？

1、业务发展速度快：单纯扩容应用的服务器可能提升不上去了，因为要受限于其他的模块，比如，DB，公共组件，中间件等。

2、链路的复杂程度在扩张：随着业务的发展，我们的接口会越来越多，业务线跟其他业务线的交互也越来越多，已无法单纯的根据自己系统的处理能力来评估接口的服务能力。

3、对单机压测结果越来越没有自信：一般而言，我们都会压一下我们自己的模块，但是身为模块的owner，自己越来越清楚，单机的压测不代表真实的场景，内心会越来越虚。

三、全链路压测方法

3.1 梳理核心链路的流程和边界

进行全链路压测前，必须梳理核心链路的流程和边界。梳理核心链路比较快，比如：
登录》搜索》加购》结算》下单

难点在于梳理清楚链路的边界：
1、搜索要关注商品
2、加购要关注促销、优惠券
3、结算要关注时效、运费、风控
4、下单后要通知营销发券、积分
5、分支系统能不能压测：
分支业务是第三方的
分支业务不重要，可以降级
分支业务本身就不能压测

3.2 提供底层支持

为确保全链路压测不产生脏数据，不影响正常业务，需要提供底层支持，需要重点考虑处理以下事项：

1、全链路透传压测标志

必须有一种在全链路透传压测标志的能力，并且必须基于一次请求，也就是同一个traceId。

需要透传的路径大概有：HTTP，RPC(DUBBO)，MQ，线程池等。

2、影子表

参与压测的业务，要逐个排查自己依赖的数据库，然后创建影子表，影子表必须跟正常表的结构保持一致。

可以在每次压测时候手动创建，也可以推动DBA自动创建。

创建好影子表后，如果当前流量是压测流量，那么写入和读取都走影子表

3、日志-影子目录

为了防止压测流程的日志对正常日志造成干扰，需要改造日志组件，将压测流量产生的日志落入到影子目录。影子目录可以有日志组件自动创建。

4、MQ支持是否消费压测流量

需要对MQ系统进行改造，一方面使其可以透传压测流量，另一方面，需要支持配置是否消费压测的MQ消息。

5、缓存/大数据隔离

缓存层，大数据层对压测流量的处理也要考虑隔离。缓存可以使用不同的集群；大数据可以直接不收集压测的数据。

3.3 全链路的压测数据mock

1、用户数据要提前做好认证等准备工作。

2、Mock数据要尽可能跟真实数据保持一致。

3、Mock数据有些限制需要放开, 适合压测反复使用。

4、千万不要污染正常数据：认真梳理数据处理的每一个环节，确保mock数据的处理结果不会写入到正常库里面。

3.4 做好压测流量的降级预案

1、当业务特别的复杂的时候，要确认好，第三方依赖能不能接收压测流量。

2、只要依赖第三方的服务，我们都要接入压测流量降级的开关，防止对第三方服务的污染。

3.5 梳理监控体系

每个业务梳理自己的监控，确保压测时候能够准确，及时的发现问题:

• 核心接口和核心依赖的流量和耗时监控

• 中间件组件，缓存，数据库的监控报警

• 服务器硬件的指标监控报警

3.6 线下做好预演

真实的压测之前，肯定要进行预演，主要确认：

• 压测流程是否写入到了正确的目的地，例如，写入到影子表，影子目录，压测cache等

• 压测流量的降级是否完备和有效

• 进一步确保监控都已到位

3.7 尽量模拟现实

压测的方案要尽可能的模拟现实：

• 各个业务确认，尽量跟线上真实的用户行为保持一致

3.8 逐步平滑加压

压测的时候，阶梯式平稳加压，及时监控指标，不要一开始就高并发

3.9 各业务线推进

除了要花时间梳理流程和思考如何处理数据之外，最难的就是整个链路跨多个业务，甚至部门，需要跟进每个业务线的进度，确保大家能够在给定的时间点进行联调以及进行压测。人力的组织和协调上，是一大难题，通常需要至少总监级别的人来整体规划、推动。

四、总结

综上所述，可以看出全链路压测是一项技术含量高，人力耗时大的工程，需要各个条线的研发、测试、运维、DBA共同配合协作才能完成的事项，并且需要针对各个应用、中间层、数据库做一系列的改造。因此更适合公司业务体量已经比较大的大公司开展，由于体量大，链路影响才不那么可控，才更需要整体链路拉通整体实施压测，投入产出比也才能接受，而且也具备能真正做好全链路压测的实力。

反之，如果是体量不那么大的公司，真没必要跟风去做什么全链路压测，投入产出比太低，最后也不一定能做好。各个应用分别针对业务流量高的接口做好单接口的压测，加上同一个应用的多个接口混合压测，整体上就足以保障业务的正常性能需要，根据自身情况选择最适合自己的方式即可。

实施全链路压测的关键点有哪些？全链路压测流程详解

随着移动互联网、云计算、物联网等技术的不断发展，应用架构也变得更加离散和复杂，一个应用的高稳定性不仅需要自身系统的稳健，同时也更加依赖网络、第三方服务的质量，而这些外部的"不确定"因素让稳定性变得更加"不可控"。在这种"不可控"的复杂环境中，如何保障高并发条件下的应用性能稳定性，需要解决以下问题：

1、高流量下的系统稳定性不足，如易崩溃、卡顿等问题；

2、新代码上线的性能基线比对，如RT、CPU load、数据库性能比对等；

3、不知道该如何合理配置机器配置和数量，多配或少配等问题；

4、系统日常运行不稳定，时不时宕机、服务不可用等问题；

5、代码变化频繁，几经易手后，架构混乱、难梳理等问题；

6、对于运行的情况不清楚，不知道当前性能健康程度如何的问题；

接下来介绍一下普遍的全链路压测的流程，从准备阶段到开展部署实施到最后的上线。

压测前：

压测范围：明确压测目标、梳理压测链路;

业务系统改造：业务系统接入压测探针进行压测改造;

压测方案：制定整个压测计划、压测数据构造、压测流程、紧急预案、监控指标等;

压测管理：压测相关配置，如：压测任务、施压配置、SLA配置、压测指标配置等;

压测验证：验证压测是否按照预期正常运行;

压测中：

压测实施：执行压测任务、观察压测中运行状态等;

压测监控：关注基础监控、业务监控等;

紧急处理 ：压测中遇到的紧急问题处理如：数据污染、压测标识丢失、集群告警等;

压测后：

压测报告：压测后产生的压测性能分析报告;

压测数据清理：将压测数据还原到压测之前，为下次压测作准备;

压测复盘：复盘整个压测过程中的问题，提升压测效率;

对于目前的绝大部分企业来说，选择有实力的第三方的服务公司已经是当下最优的选择，这里面存在人员成本、专业程度以及效率质量等多方面问题，可以说越专业的服务公司就有着越高的技术能力，更有着丰富的技术实践经验和对客户需求的深刻理解。

以上就是小编为大家整理的性能测试能力提升-全链路压测，实施全链路压测的关键点有哪些的相关内容。

国内(北京、上海、广州、深圳、成都、重庆、杭州、西安、武汉、苏州、郑州、南京、天津、长沙、东莞、宁波、佛山、合肥、青岛)睿象云软件分析、比较及推荐