性能常识压测怎么做？如何自动化？盘点各大公司全链路压测方案与实践

TesterHome小助手 · 2024年05月07日 · 1900 次阅读

本文综合盘点各大公司团队的全链路压测技术方案和实践路径，供大家参考。

一、什么是全链路压测？

全链路压测指的是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。常用于复杂业务链路中，基于全链路压力测试发现服务端性能问题。

一般来说，全链路压测：

基于实际的生产业务场景、系统环境，基于真实数据模拟海量的用户请求对整个业务链进行压力测试，并持续调优的过程；
全链路的核心为：业务场景、数据链路、压力模型和环境拓扑；
全链路压测不仅仅是一种测试手段，更确切来说其是一种测试过程，该过程涉及自动化测试/性能测试/高可用测试技术以外，还覆盖性能分析调优以及扩缩容解决方案等等。

全链路压测与传统压测的区别：

哪些场景适合全链路压测：

定时定期进行线上运营活动；
业务链路以及数据链路调用错综复杂，各子系统之间调用关系密切，均为业务核心调用链路；
真实业务流量与历史流量对比预估有量的增长；
业务需求频繁迭代，业务链路性能波动较大；
测试环境数据、系统版本等无法统一，且资源配置与线上差异较大。

行业内全链路压测方案对比：

方案一：流量混布, 存储隔离, 线上施压

对线上服务压测，压测前根据容量预估和压测目标，对线上服务进行扩容和 cpu、mem 等相关配置的变更。

压测产生的数据与线上真实数据做隔离，采用影子库表的方式，防止污染线上真实存储。

需构造压测数据和压测流量，通过压测标记来区分流量属性。

方案二：对数据本身做标记, 逻辑隔离，线上施压

对线上服务施压，与方案一的区别在于数据隔离上，不是通过影子库表，而是在原表上增加标记，做逻辑隔离。

业务需要做适配工作来识别流量属性。

方案三：镜像环境 OR 线下压测

此方案在线下进行压测，部署线下测试环境或镜像环境。

线下环境稳定性不高，硬件资源和压测数据线上线下差异大，压测结果参考价值有限。

二、全链路压测的自动化

货拉拉技术团队的实现思路：

全链路压测自动化的探索与实践（点击看全文）

在构思初始方案时，我们在行业内寻找并比对类似的解决方案，但是发现相关资料较少。由于全链路压测和压测自动化都需要与公司业务和内部平台频繁交互，我们在考虑改造全链路压测自动化时，决定结合公司业务特点和现有全链路压测流程以及内部平台特性进行改造。

为实现全链路压测的自动化，主要目标是把人工操作的重复工作自动化。在确定整体方案后，我们详细梳理了全链路压测前、中、后的常见工作场景，并确认了对应的需求以及平台服务支撑。以下是我们的整体改造思路图。

梳理出改造场景中的重点和难点问题，我们需要着重完成以下功能：

模型建模与模型效果对比：无论是在压测场景和流量的配比，还是在压测后的效果对比中，都需要我们找到一个适合的模型算法，以确认压测场景的模型以及对比压测效果。
压测任务编排：在压测任务中，一些任务有固定的时间顺序或因果关系顺序。这就要求我们需要有一个灵活的任务编排系统，方便自由地编排相关压测任务。
压测任务调度：以货拉拉货运全链路压测为例，每次涉及到超 70 个脚本，300 余台压测机，以及数百万订单的压测目标流量。因此，如何对测试场景、脚本和测试数据以及压测流量进行有效的管理、分发和收集显得尤为重要。
健全的熔断机制：既要检测出系统瓶颈，又要在出现异常时及时停止压测流量，以避免引发更大的生产问题，因此需要一个健全的熔断机制。

B 站技术团队的实现思路：

bilibili 全链路压测改造之全链自动化测试实践（点击看全文）

B 站在全链路压测上的实践（点击看全文）

B 站的全链路压测方案，简单来说主要为流量混部、线上压测和存储隔离三个部分：

流量混部

与线上集群资源共用，在深夜低峰时期进行线上压测
通过流量打标的方式对流量进行区分，压测流量均带有压测标识，支持对 http 请求和 grpc 请求打标进行全链路压测
服务接入压测 sdk，对压测流量进行识别、拦截和处理

线上压测

通过公司的压测平台，进行压测任务和场景设计、压测数据构造以及压测结果分析等，具体压测平台的设计及原理在 B 站压测实践一文 中有详细介绍。

存储隔离

我们采用存储隔离的手段，对 db 创建影子表，redis 创建影子 key，mq 创建影子 topic，将压测流量完全隔离
搭建全链路压测配置控制台，管理压测规则，主要涉及对已接入全链路压测的服务的以下几点配置： △ 需要压测的接口 △ 压测接口依赖的下游接口的透传/镜像/Mock 规则 △ 数据库表的透传/镜像/写丢弃规则 △ 缓存的透传/镜像规则 △ 消息队列的透传/拦截/镜像规则

直播的全链路压测架构图如下，可以看到整体链路，由压测平台施压，被压测的服务接入压测 sdk，获取到由压测规则控制台下发的压测配置信息，根据配置信息对接收到的压测流量做处理，如配置了镜像规则的数据表，压测数据写入影子表，对配置了镜像规则的 redis,压测的缓存数据写入影子 key 等等。

针对此链路上如此多的服务改造点（SQL 改造、redis 改造、databus 改造、job 改造、context 改造、go channel 改造、sync/pipeline 改造...），如何能又快又好又全面的测试覆盖，是我们设计全链自动化测试方案的初衷，我们将其主要分为三个阶段。

第一阶段，我们对各个新增节点分别做了测试保障，如 mirror sdk、压测配置控制台等，保正底层基础能力的正确性。

第二阶段，当基础建设已完成，进入到了业务接入及全流程验证阶段。业务是不停迭代的，其中随着基架的不断演进，业务所涉及的服务也包含了部分历史债，当此套框架真正接入业务后，我们往往在业务实际使用中会发现很多不适配的地方，包括框架设计不够健壮或者业务的使用姿势不规范等原因，需要修复或兼容。这个阶段的测试也是最繁琐、测试量最大、重复性很高的地方，为此全链自动化测试全面应用于此阶段，来提升效率及业务覆盖度。

第三阶段，主要应对于未来的拓展，随着全链路压测覆盖的业务越来越多，当” 常态化 “的全链路压测计划提上日程，重复的工作和人力成本随之增加。此时测试工具更需要平台化及可视化，为压测前、压测中、压测后各个阶段的重复工作提供有效的自动化支持。