分布式压测

前言

---

 

谈下为啥这期聊到分布式压测，之前在搞全链路灰度的时候，涉及到「流量打标」在很多技术方案都会应用这项技术，所以自然我就关注了这个方案。

那么今天我们就聊下分布式压测～

what is 分布式压测

---

谈到「压测」，我们自然想到jmeter、高并发、qps，没错，其实上为了压到系统能否承受的极限，从而合理的保护系统。但是这个一般出现在Toc业务，因为流量打满状态，比如说秒杀，抢购，我前司微商城qps最高在上w,算是很可以了。

如果我们只压一个系统，或者一个接口，显而易见，是片面的，无法体现整个流程或者体系的稳定性，这时分布式压测就横空出世了。就是在整个链路，然后大批量模拟流量，这样才能接近真实的情况。

谈谈how to do

---

分为几部分来搞：数据构建、数据隔离（中间件改造）、服务自我保护措施

数据构建

你要压测，需要构建一个请求，那么就需要对应api、参数、header、请求方式等等，其次是基础数据得完善，不能说你拿线上的数据去请求测试环境的吧。

基础数据这个好搞，copy一份对吧，定时同步。主要是接口录入需要大量的时间，这里谈下自动化测试，我看过有些公司也会尝试做自动化测试，但是我发现一个问题，测试同学需要录入很多api，参数，返回数据进行断言，那是相当蛋疼的一件事，妥妥的工具人🔧。

我忘记在哪篇文章提到「流量录制」，这让我想起之前面阿里的时候，有个面试官他们组就是搞这些插件的，通过「jvm-standbox」，这个我还没深入了解，大家可以自行学习下，我后面找一期跟大家聊聊这个。

如果流量录制代替人工录入，减少很多工作量。

压测流量的发起

很多系统都会有鉴权的，没有的话告诉我，我去压下你们接口，哈哈。

那么我们如何去搞定登陆的问题，我们看下字节怎么做的

会有一套特殊的鉴权的构造压测数据。

压测流量染色，标识在链路透传

在之前全链路灰度的时候，讲过这个，压测流量的话，我更偏向压测机带上压测游标，主动进行染色，然后网关改成内部染色标识，放到request header头，在整个链路里面传递～

数据隔离

为了跟正常数据分隔开来，这里我们就有把数据隔离搞起来，常见的「影子表、影子库、redis（影子key）、mq（影子topic）」，谈到这里就涉及「中间件改造」了，我们可以采用agent来改写，如果流量带上压测标识，将数据源改为影子数据源。

由于这个只是吹水，就没有上代码，像mysql改下datasource，redis 改写set方法，mq改写生产者推过去的topic，不然就是消费者拿到这个带有压测标识的消息，做特殊处理。

还有特殊点：第三方api

压测流量不如污染第三方的，所以对于第三方接口需要采用mock的方法。

 

服务自我保护措施

我们去看很多中间件的实现，都会带上开关，为了服务的自我保护机制，比如说方案有问题，你把线上机器压爆了，正所谓程序跟人只要有个能跑就行，哈哈。

其实也是个暗箱操作，出现问题，咔嚓关掉，你不说我不说，大家都不知道，然后偷偷改bug，当然博主不会这么干，哈哈。

监控

这也是最基础，也是很重要量化的工具，我们需要根据压测出来的数据，来看下哪里服务有瓶颈，需要对接口进行优化，还是说做限流，最大程度保护服务，当初前司大促的时候买了400台机器，只能说有钱果然牛逼～

这就完了？还有细节

---

很多技术方案聊起来都很简单，但是真正去落地的时候会有很多技术细节，我们展开说说。

1. 影子表怎么构建，怎样更加合理

2. 压测账号怎么设计，因为有些流量是跟账号绑定的，比如说张三就有100w，这算是基础数据的一部分

3. 压测流量怎么标识，我觉得是主动带上压测游标

4. 中间件改造怎样比较合适，mq 不同topic意味着你还要监听两个topic，有些文章说不处理压测mq，意味着某个流程中断了，需要去mock。也有方案说是不同broke，也是一种方案。

总结

---

到这里，大家也对分布式压测有个大概了解了，很多大厂都会采用该技术方案来保障线上环境的稳定，包括数列科技开源的Takin框架。