高并发系统设计学习笔记(三十) 全链路压力测试平台_高并发系统架构设计之服务治理篇30:压力测试-CSDN博客

本文链接：https://blog.csdn.net/panjianlongWUHAN/article/details/119671594

一、压力测试

压力测试的通常的错误之处

1.压力测试时最好使用线上的数据和线上的环境，你无法确定自己搭建的测试环境与正式环境的差异，是否会影响到压力测试的结果。

2.压力测试时不能使用模拟的请求而是要使用线上的流量。你可以通过拷贝流量的方式，把线上流量拷贝一份到压力测试环境。比如，你在获取商品信息的时候，线上的流量会获取不同商品的数据，这些商品的数据有的命中了缓存，有的没有命中缓存。如果使用同一个商品ID来做压力测试，那么只有第一次请求没有命中缓存，而在请求之后会将数据库中的数据回种到缓存，后续的请求就一定会命中缓存了，这种压力测试的数据就不具备参考性了。

3.不要从一台服务器发起流量，这样很容易达到这台服务器性能瓶颈，从而导致压力测试的QPS上不去，最终影响压力测试的结果。而且，为了尽量真实地模拟用户请求，我们倾向于把流量产生的机器放在离用户更近的位置，比如放在CDN节点上。如果没有这个条件，那么可以放在不同的机房中，这样可以尽量保证压力测试结果的真实性。

在压力测试的过程中，我们不能只针对某一个核心模块来做压测，而需要将接入层、所有后端服务、数据库、缓存、消息队列、中间件以及依赖的第三方服务系统及其资源，都纳入压力测试的目标之中。因为，一旦用户的访问行为增加，包含上述组件服务的整个链路都会受到不确定的大流量的冲击。因此，它们都需要依赖压力测试来发现可能存在的性能瓶颈，这种针对整个调用链路执行的压力测试也称为“全链路压测”。通常做一次全链路压力测试，需要联合DBA、运维、依赖服务方、中间件架构等多个团队，一起协同进行，无论是人力成本还是沟通协调的成本都比较高。

二、如何搭建全链路压测平台

搭建全链路压测平台，主要有两个关键点

流量的隔离，由于压力测试是在正式环境进行，所以需要区分压力测试流量和正式流量，这样可以针对压力测试的流量做单独的处理。
风险的控制。也就是尽量避免压力测试对于正常访问用户的影响

一般来说全链路压测平台需要包含以下几个模块

流量构造和产生模块；
压测数据隔离模块；
系统健康度检查和压测流量干预模块

1.压测数据的产生

我们可以使用多种方式来实现流量的拷贝。

直接拷贝负载均衡服务器的访问日志，数据就以文本的方式写入到流量数据工厂中。
通过一些开源的工具来实现流量的拷贝，推荐一款轻型的流量拷贝工具GoReplay

还需要对压测流量染色，也就是增加压测标记。在实际项目中，我会在HTTP的请求头中增加一个标记项，比如说叫做is stress test，在流量拷贝之后，批量在请求中增加这个标记项，再写入到数据流量工厂中。

2.数据如何隔离

实现压测流量和正式流量的隔离，这样一来就会尽量避免压测对线上系统的影响。我们会针对某些不能压测的服务或者组件，做Mock或者特殊的处理。

在压测的时候，肯定会增加这些行为数据，比如原本一天商品页面的浏览行为是一亿次，而压测之后变成了十亿次，这样就会对业务报表产生影响，影响后续的产品方向的决策。因此，我们对于这些压测产生的用户行为做特殊处理，不再记录到大数据日志中。我们需要Mock这些推荐服务，让不带有压测标记的请求经过推荐服务，而让带有压测标记的请求经过Mock服务。

我们会把压测流量产生的数据写入到影子库，也就是和线上数据存储完全隔离的一份存储系统中。针对不同的存储类型，我们会使用不同的影子库的搭建方式。

如果数据存储在MySQL中，我们可以在同一个MySQL实例，不同的Schema中创建一套和线上相同的库表结构，并且把线上的数据也导入进来。
而如果数据是放在Redis中，我们对压测流量产生的数据，增加一个统一的前缀，存储在同一份存储中。
还有一些数据会存储在Elasticsearch中，针对这部分数据，我们可以放在另外一个单独的索引表中。