全链路压测，你想要的全在这里

dream_back

已于 2022-09-08 14:26:58 修改

阅读量1.1k

点赞数

分类专栏： jemter性能测试文章标签：全链路压测系统架构业务模型数据准备单链路压测

于 2022-09-07 11:20:06 首次发布

本文链接：https://blog.csdn.net/dream_back/article/details/126739967

版权

jemter性能测试专栏收录该内容

30 篇文章 6 订阅

订阅专栏

步骤一：确定压测目标

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

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

步骤二：梳理系统架构

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

本文示例的系统架构图如下：
在这里插入图片描述
组件，组件分类，组件潜在瓶颈如下
1.SLB：负载均衡

容量不足
建连失败

2.ApiGateway：API网关

容量不足
线程等待
触发限流

3.UserService：微服务

容量不足
线程池资源耗尽
日志资源耗尽
触发限流
GC

4.Redis：KV缓存

容量不足
触发限流
缓存击穿
缓存热点
连接池耗尽
大对象

5.MySQL：数据库

容量不足
触发限流
连接池耗尽
慢SQL

6.Kafka：消息队列

容量不足
消息堆积
磁盘写达到100%

7.SmsService：第三方依赖

第三方可能会拒绝参与压测

步骤三：梳理业务模型

压测的业务模型对压测结果的准确性至关重要。全链路压测的链路代表要压测的业务范围，同一条链路需要构造海量的参数集合代表不同用户的不同行为，系统的基础数据、系统预热情况等代表系统的状态。链路范围、链路的访问量级、链路的参数集合、基础数据、预热情况一起构成了压测的业务模型。

通常从以下维度梳理业务模型：

1.用户行为维度

确定业务接口的范围、接口的目标量级、接口的参数集合、压力曲线等。
根据业务特性确定压测数据的分布。例如用户的规模和地域、商品的种类和数量、是否制造热点商家和商品等。

2.系统状态维度

根据业务和场景的特性，确定各组件（例如缓存）的状态。例如拉新场景，缓存命中率非常低，而日常高峰场景，缓存命中率非常高，需要根据不同的场景来准备不同的缓存预热策略。
根据业务和场景的特性，确定基础数据的量级和范围。例如拉新场景，需要考虑老用户召回的情况，而日常高峰场景，一般准备与活跃用户相当量级的基础数据。

总之，业务模型与业务强相关，压测的业务模型对压测结果的准确性至关重要。

步骤四：准备压测脚本

根据业务场景编写压测脚本，也可以直接复用已有脚本

步骤五：改造升级环境

在生产环境进行全链路压测，最核心的是线上写操作不能污染正常的业务数据。因此，需要针对存储做影子库表，即正常业务库表的镜像，让压测流量的数据流转到影子库表，正常业务流量流转到正常业务库表，在逻辑上隔离两种流量，使之互不影响。
在这里插入图片描述
生产环境压测的三大前提：

压测标记不丢失
压测流量在任何环节能够被正确的识别出来。在流量入口层带上压测标，中间件识别并继续往下传递压测标，保证整条链路上压测标不丢失，通过这种方式使得下游的应用和存储也能接收到压测标。
压测流程不中断
压测流量能够正常的调用下去，整个流程不被阻断，返回符合预期的业务结果。业务的应用层，要支持全链路也需要进行对应的改造。应用层在识别到压测标时，需要绕过参数校验、安全校验等校验逻辑，例如手机号格式校验、用户状态校验、以及一些其它特殊业务校验逻辑。
压测数据不污染
压测数据不对线上正常的业务造成数据污染。全链路场景往往包含多个读写场景，为了隔离压测数据，存储中间件识别到压测标之后，将数据写入影子库表，与真实的数据区分开。为了更加真实的模拟真实场景，影子库表中的基础数据（例如买家、卖家、商品、店铺等）是由真实数据加上固定偏移量构造而成，迁移过程中会进行采样、过滤、脱敏等操作保证数据安全，一般在数据量级上和真实数据保持一致。

PTS探针已经具备以上三大能力，仅需在应用上部署好探针、配置好规则即可，无需改动业务代码。

本文示例的架构图升级方案如下：
在这里插入图片描述

步骤六：正常流量联调

通常通过执行功能回归用例完成联调，是需要将正常回归流量打上流量标（例如在请求中添加Header x-pts-test=2），这样在查找调用链路时可以精准定位。该环节主要关注点如下：

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

步骤七：准备压测数据

1.确认影子库表范围。
影子库表的范围就是压测链路涉及到的应用使用到的库表。在梳理过程中，需要包括库名、表名、数据量级、核心业务字段（例如商品ID、用户ID等），表与表之间字段的关联性（外键、JSON字段中的引用等均包括在内）。

2.确认偏移字段、脱敏字段。
偏移字段：字段偏移可以极大的保证业务数据的安全。偏移字段一般选择用户ID、商品ID等关联字段，如果有用到Sequence类的分布式ID组件，也需要进行偏移。根据业务的实际增长选择不同的偏移量，一般会选择10年以上都不会用到的值作为偏移量。

说明脱敏字段：业务上认为是敏感数据的用户数据，例如手机号、密码、用户名等，不同安全级别的字段会有不同的脱敏方式，根据业务要求脱敏即可。常见的脱敏方式包括遮盖掩码、加盐哈希、高斯噪音等。需要确保脱敏之后的字段值在业务流程上是能走通的，如果在压测联调过程中出现校验失败，可以使用Mock规则绕过校验。

3.新建影子库表。

说明该步骤一般由DBA完成，根据影子库表范围创建库表结构。

4.执行数据迁移。

说明该步骤一般由DBA完成，迁移工具一般选择DataX，在业务低峰时段从备库迁移到影子库表，建议根据实际情况配置限流。迁移的数据量一般与线上数据保持数据量级上一致即可。

5.准备接口参数数据。
基于基础数据和压测模型构造业务接口的参数集合。根据各压测平台的不同，支持的格式、配置方式也各有不同，一般都支持CSV文件格式，根据各平台要求构造即可。

压测业务模型对压测结果的准确性至关重要，而压测数据准备是业务模型落地的核心环节。压测数据主要包括基础数据和链路数据两种。

基础数据：包括业务运行所需的库表和数据，例如：买家、卖家、商品、优惠等，基础数据的规模一般需要与实际业务数据在量级上保持一致。
链路数据：包括需要压测的接口和多样化的接口参数集合，接口请求的参数集合是基于基础数据生成的。例如：商品详情页的接口为https://xxx.com/item?itemId=xxx，参数集合为具体的商品ID的集合。

基础数据的准备方式通常有直接构造和数据迁移两种：

直接构造：直接根据业务规则构造出来，一般用在少量数据的准备，例如联调阶段的数据构造。
数据迁移：对线上数据做清洗、采样、偏移后迁移到影子库表，数据完备性好，仿真度高，省时省力。建议使用DataX进行数据迁移

数据准备环节，最核心的原则是需要保证镜像、影子库表的软硬件配置与正常库表一致，同时配置简单易行。这样可以保证在压测的时候充分暴露线上的数据库表的真实问题。

选择数据隔离策略有以下方式：

影子表隔离：在生产库建立业务表同结构的影子表，影子表名通常会在正常表名的基础上加上固定的前后缀。表级别的隔离在设计上允许复用一部分只读表，但是梳理难度有所增加。
影子库隔离：在用一个实例上创建与源数据库同配置的影子库，影子库名通常会在正常库名的基础上加上固定的前后缀，表名保持不变。库级别的隔离是数据源的隔离，隔离相对比较彻底、安全。
影子Key隔离：一般用在KV缓存、存储组件上（例如Redis），探针会拦截对KV缓存、存储组件的所有操作，根据流量标自动修改Key和过期时间，达到隔离数据和数据清理的目的。

他存储组件的隔离原理基本上与上述三种思路上一致，您可以根据自身业务和架构特性，自行选择最佳的隔离方式。