测试学习——全链路压测

article/2025/11/5 21:24:12

参考资料：全链路压测平台（Quake）在美团中的实践

全链路压测简介 - 性能测试 PTS - 阿里云

聊聊全链路压测 - 老_张 - 博客园

基于实际的生产业务场景和系统环境，模拟海量的用户请求和数据，对整个业务链路进行各种场景的测试验证，持续发现并进行瓶颈调优，保障系统稳定性的一个技术工程。总的来说，全链路压测基于真实的用户场景，实际线上环境，按照既定流量，对各个业务链路进行压力测试的过程。

全链路压测的原因

传统的压测只会涉及到核心服务，无法覆盖到所有的环节，而传统的压测通常会忽略掉一些基础服务如Nginx、Redis 缓存、数据库、磁盘、网络等，所以这些基础服务问题在单服务压测中往往不能被暴露出来。

全链路压测和传统压测的区别

压测类型	传统压测	全链路压测
压测方式	Jmeter、Locust、Loadrunner	压测集群、流量引擎、录制回放开源：Takin 阿里：Amazon，PTS 美团：Quake 京东：ForceBOT 高德：TestPG 字节：Rhino
承接方式	需求响应式，被动	发现系统所有链路存在的瓶颈点，主动
压测环境	测试环境/性能环境	生产环境
环境特点	环境不稳定/配置低/压测结果参考性不高	环境稳定/完全真实环境/压测结果真实可靠
压测场景	单机单接口、单机单链路、单机混合链路	包含覆盖范围内的所有核心链路及场景
压测过程	可观测性较低，延时较高	实时可视化观测
测试结果	数据维度小，无法提供太多数据便于分析	提供多维度细粒度的数据，便于快速定位问题优化
投入成本	需要搭建单独的压测环境	完全线上生产环境进行，无须单独搭建环

全链路压测的过程

一、确定压测目标

压测目标主要包括压测范围、策略、目的，往往与业务、技术目标息息相关。例如：

压测范围：用户注册加登录，为大规模拉新做准备。
压测策略：高仿真生产环境压测，提前经历真实的业务高峰。
压测目的：探测业务吞吐极限，验证架构能力、探测性能瓶颈。

二、梳理系统架构

梳理清楚端到端的请求链路、技术架构、分层结构、模块划分，以及RPC、消息、缓存、数据库等中间件的使用情况，分析潜在的瓶颈点，并针对性的增加监控指标、制定应急预案。

组件	分类	潜在的瓶颈、问题
SLB	负载均衡	容量不足建连失败
ApiGateway	API网关	容量不足线程等待触发限流
UserService	微服务	容量不足线程池资源耗尽日志资源耗尽触发限流 GC
SecurityService	微服务	容量不足线程池资源耗尽日志资源耗尽触发限流消费延迟 GC
Redis	KV缓存	容量不足触发限流缓存击穿缓存热点连接池耗尽大对象
MySQL	数据库	容量不足触发限流连接池耗尽慢SQL
Kafka	消息队列	容量不足消息堆积磁盘写达到100%
SmsService	第三方依赖	第三方可能会拒绝参与压测

三、梳理业务模型

全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块。全链路压测的链路代表要压测的业务范围，同一条链路需要构造海量的参数集合代表不同用户的不同行为，系统的基础数据、系统预热情况等代表系统的状态。链路范围、链路的访问量级、链路的参数集合、基础数据、预热情况一起构成了压测的业务模型。

四、准备压测脚本、改造升级环境

根据业务场景编写压测脚本并对生产环境进行隔离。

生产环境压测的三大前提：

压测标记不丢失

压测流量在任何环节能够被正确的识别出来。
压测流程不中断
压测流量能够正常的调用下去，整个流程不被阻断，返回符合预期的业务结果。
压测数据不污染
压测数据不对线上正常的业务造成数据污染。全链路场景往往包含多个读写场景，为了隔离压测数据，存储中间件识别到压测标之后，将数据写入影子库表，与真实的数据区分开。

五、正常流量联调

通常通过执行功能回归用例完成联调，是需要将正常回归流量打上流量标，这样在查找调用链路时可以精准定位。

验证探针对正常业务逻辑无影响，用例的测试结果均符合预期
验证探针对依赖组件的适配情况，无遗漏的RPC调用、采集的数据准确无误；调用链完整性是全链路压测数据安全的核心。
将探针采集的调用链数据进行聚合（建议500+以上），抹平不同参数、不同逻辑分支带来的调用链差异性。使用聚合后的依赖拓扑图辅助梳理组件依赖可以极大程度的避免组件遗漏。
根据正常流量联调的结果，需要梳理出影子库表的范围、第三方服务的依赖情况。