设计一个线上压测系统能让我们学习到多少东西?13个问题看你能否搞定

举报
breakDawn 发表于 2022/10/23 23:13:56 2022/10/23
【摘要】 Q: 为什么需要线上压测?A:需要在某些活动、大促前,评估机器扩容数量,验证系统能否有效支撑流量峰值。线下测试环境的机器资源有限, 无法完全模拟现网。 同时很多配置可能配置不相同,如果没对上导致机器数量估计错误,可能引发重大故事。所以必须要在线上做压测。 Q: 全链路压测和接口压测的区别?A:在特定的业务场景下, 将相关的链路完整地串联起来同时施压, 尽可能模拟出真实的用户行为。接口A做...

Q: 为什么需要线上压测?

A:

  1. 需要在某些活动、大促前,评估机器扩容数量,验证系统能否有效支撑流量峰值。
  2. 线下测试环境的机器资源有限, 无法完全模拟现网。 同时很多配置可能配置不相同,如果没对上导致机器数量估计错误,可能引发重大故事。所以必须要在线上做压测。

Q: 全链路压测和接口压测的区别?

A:
在特定的业务场景下, 将相关的链路完整地串联起来同时施压, 尽可能模拟出真实的用户行为。
接口A做接口压测,可能是1w/s的QPS, 但是A和B同时压测,可能因为数据库连接等共享资源,导致实际QPS下降。


Q: 业务系统如何区分压测流量?即判断哪些是压测的请求,哪些是正常的请求?

A:

  1. url上加上打标参数, 例如 http://xx?st=true
  2. hearder中打标

Q: 这个压测打标的改造和适配要中间所有服务参与吗? 改造成本会不会有点大?

A:
不需要全部参与。

如果设计过链路跟踪系统, 则每个服务都有中间件团队提供的拦截器, 因此直接通过公共拦截器来做压测标记的识别。


Q: 识别到压测标记后, 如何保证往下游发请求时,仍然是压测标记的形式?

即发请求的时候已经不是同一段拦截器的代码了。 但是也要保证尽可能不改动原有的业务逻辑代码。

A:
如果处理请求和发下游请求是在一个线程中完成的, 那么可以使用threadLocal。
即拦截到请求时, 将压测标记set进threadLocal中。
发送下游请求的代码中,如果能从threadLocal中拿到压测标记,则改造url,设置进往下发的请求中


Q: 如果我不在同一个线程中处理和发请求, 怎么办?

即我的业务代码中 做了new Thread或者ExectorPool.submit提交异步请求, 这时候业务逻辑里肯定不会涉及到threadLocal的代码, 而此时压测标记就会丢失了。

threadLocal可以用 InheriableThreadLocal, 这样如果在线程中new新的线程,则标记可以被传递下来。
如果是线程池创建异步请求, 可以用阿里的TransmittableThreadLocal。


Q: 如果我的压测链路中 包含了外部服务的接口怎么办? 例如第三方支付、第三方短信等。

A:
链路跟踪系统中发请求的filter中, 新增MockFilter, 如果判断是压测请求, 则直接返回mock逻辑(不建议部署mock服务, 因为部署mock服务的话,服务器成本又得考虑,不如直接封装到mockFilter代码中)


Q: 会对数据库产生影响的压测请求怎么办?

如果直接落库,可能会影响正常用户的请求访问, 也可能污染线上数据。
A:
为每个生产库 生成一个影子库, 专门用来存储压测数据。

然后做过分库分表的话, 肯定有数据库的proxy,在proxy里都往压测库插入和读写。
如果没有,就扩展Spring的AbstactRoutngDataSource类, 实现一个动态的数据源,让里面可以根据压测标记进行切换。


Q: redis、kafka等中间件对压测有什么特殊处理?

A:
除了添加统一特点的压测标记(中间件和业务不是强相关,所以可以进行特定改造)
还要注意缓存的存活时间要设置短一点。


Q: 压测结束时,如何避免对数据库继续产生影响?

A:
注意不要触发 数据源的init-method方法, 当真正执行压测的时候再建议会话连接。
各种超期时间也要注意设置, 尽快接触压测对组件的影响。


Q: 压测数据怎么构造?一个个手动拼数据参数,然后让测试同学发送吗?

A:
不行,如果业务有改动,参数很容易对不上,同时组装过程耗时也会非常久。

建议从线上直接dump最近的请求数据,这样可保证参数没有变化。
同时做一些脱敏和修正处理。


Q: 怎么完整设计这个压测系统的架构?包含哪些角色

A:
该问题参考《超大流量分布式系统架构解决方案》一书中给出的方案,也可以有其他方案。

  1. 压测manager服务, 提供给压测控制者查看和使用的。可以读取mysql数据库获取压测结果情况,或者进行调度指令的下发等。
  2. taskService服务,用于处理调度指令,执行定时调度、即时调度等行为。
  3. Agent 压测请求发送客户端。根据taskService的指令进行发送
  4. DataFactoy,给agent提供脱敏、修改后的压测数据。
  5. MQ, 接收agent压测请求的结果,堆积到队列里提供给DataCollect消费。
  6. DataCollect, 压测结果消费者, 将结果写入到数据库MYSQL。
  7. 注册中心,用于管理和注册上面这些服务。
  8. Detecotr, 流量检测和干预器,可以根据情况即时调整agent的发送速率。

image.png


Q: 怎么模拟实际用户的请求发送? 因为实际场景应该是多个不同ip的用户访问进来才对。

A:

  • apache HttpComponents的httpclient包
  • Java11的异步httpclient, 支持HTTP/2, 支持用reactive stream。
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。