首页 > 其他分享 >聊聊全链路压测

聊聊全链路压测

时间:2022-11-24 19:36:37浏览次数:55  
标签:异步 服务 压测 业务 聊聊 链路 数据

https://www.cnblogs.com/imyalost/p/8439910.html

主要罗列的是问题点,以及对应的一些解决方案,仅供参考。。。

相关链接:

阿里全链路压测

有赞全链路压测

京东全链路压测

饿了么全链路压测

滴滴全链路压测解决之道

美团全链路压测自动化实践

逻辑思维在全链路压测方面的实践

 

一、什么是全链路压测

基于实际的生产业务场景、系统环境,模拟海量的用户请求和数据对整个业务链进行压力测试,并持续调优的过程。

 

二、全链路压测解决什么问题

针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈,让技术更好的服务业务,创造更多的价值。

 

三、面对的问题点以及解决方案

1、业务模型梳理

首先应该明确的是:全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分,确认流量高峰针对的是哪些业务场景和模块,

针对性的进行扩容准备,而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍,这样会造成不必要的成本投入。

 

2、数据模型构建

数据构建和准备,应该考虑这几点问题:

①、数据的真实性和可用性

可以从生产环境完全移植一份当量的数据包,作为压测的基础数据,然后基于基础数据,通过分析历史数据增长趋势,预估当前可能的数据量;

②、数据脱敏

基于生产环境的全链路压测,必须考虑的一点是不能产生脏数据,以免对生产造成影响,影响用户体验等,因此在数据准备时需要进行数据脱敏;

③、数据隔离

同样,为了避免造成脏数据写入,可以考虑通过压测数据隔离处理,落入影子库,mock对象等手段,来防止数据污染;

 

3、压测工具选型

全链路压测应对的都是海量的用户请求冲击,可以使用分布式压测的手段来进行用户请求模拟,目前有很多的开源工具可以提供分布式压测的方式,比如jmeter、Ngrinder、locust等。

可以基于这些压测工具进行二次开发,由Contorller机器负责请求分发,agent机器进行压测,然后测试结果上传Contorller机器。

考虑到压测量较大的情况下回传测试结果会对agent本身造成一定资源占用,可以考虑异步上传,甚至事务补偿机制。

 

4、压测环境搭建

全链路压测都是基于生产环境,解决了业务模型和数据以及压测工具选型开发,就要考虑系统扩容和风险规避了,比如压测不能影响实际的生产业务运行,还有资源申请等。

重新搭建一套完全匹配生产环境的压测环境,成本太高,且需求频次较低,投入成本太大。

 

5、系统容量规划

前面提到了业务拆分和流量预估,在系统容量规划阶段,首先应该对单个接口单个服务进行基准测试,调整配置参数,得到一个基准线,然后进行分布式集群部署,通过nginx负载均衡。

至于扩容,要考虑到服务扩容和DB资源扩容,以及服务扩容带来的递减效应。

至于大流量冲击情况下,可以考虑队列等待、容器锁、长连接回调、事务降级等方式来解决。

 

6、测试集群部署

能做全链路压测的业务系统,基本都是分布式系统架构,服务集群部署和负载均衡,就是需要实现和考虑的技术点。

需要解决的问题有:

①、服务间通信问题

一般通信方式有两种:同步和异步。

同步调用:

REST(JAX-RS,Spring Boot)

RPC(Thrift, Dubbo)

异步调用:

(Kafka, Notify, MetaQ)

同步调用一致性强,但是要考虑性能和调用失败的事务处理。

异步调用的话,可以降低服务间的耦合,提升性能体验,但是一致性是需要解决的(分布式架构有个CAP理论,感兴趣的可以查询相关资料看看)。

②、负载均衡问题

需要将大流量冲击均匀的分发给集群上的每台机器,目前比较优秀的负载均衡服务器是nginx,但nginx的部署貌似也存在一些问题,我们公司之前就遇到过订单重复问题。

③、容灾问题

需要确保的一点是:当服务中的某台或者某部分服务宕机,可以及时的进行服务转发,而不至于连锁反应下整个系统链路的服务挂掉(可以参考我之前的博客:容灾测试)。

 

7、数据收集监控

压测数据收集,需要由agent机回送给Contorller机器,但数据量过大会占用一定的资源,可以考虑异步实现测试结果回送。

至于监控,现在有很多优秀的专业监控工具,比如Nmon、Zabbix,全链路监控工具Zipkin、PinPoint以及携程开源的全链路监控工具CAT。

或者可以针对需要,二次开发JVM自带的一些监控工具,做到实时全方位监控。

 

上面的内容,主要还是一些知识点整理和个人的一些思考,权当参考,如有错误或者更好的建议,可以在评论区指正,不胜感激!

标签:异步,服务,压测,业务,聊聊,链路,数据
From: https://www.cnblogs.com/ceshi2016/p/16922970.html

相关文章

  • ONE 2.0应用场景解读 | 如何通过时序拓扑直观还原故障传导链路?
    近年来,随着数字化转型的不断推进,电子商务发展迅速,推动人们的购物行为随之发生转变,在线购物已成为人们的主要购物方式之一。相关数据表明,超过九成的中国网民使用过在线购物平......
  • 聊聊连接池和线程
    https://www.cnblogs.com/imyalost/p/7189455.html一、连接池1、什么是连接池?我们为什么需要它?连接池允许多个客户端使用缓存起来的连接对象,这些对象可以连接数据库,它们......
  • jmeter jdbc MySQL压测
    一、添加MySQL驱动下载MySQL驱动,安装  然后再测试计划添加MySQL驱动jar包    二、添加jdbc配置       三、添加jdbc请求     ......
  • JMeter阶梯式加压测试插件-Stepping Thread Group解析
    在日常性能测试过程中,有时需要对被测对象不断的增加压力,直至达到某个值后,并持续运行一段时间。这里将借助jmeterSteppingThreadGroup插件模拟这种情况。本文介绍在......
  • 聊聊Spring中的数据绑定DataBinder
    数据绑定 这个概念在任何一个成型的框架中都是特别重要的(尤其是web框架),它能让框架更多的自动化,更好容错性以及更高的编码效率。它提供的能力是:把字符串形式的参数转换成服......
  • 聊聊如何让办公网络直连Kubernetes集群PodIP/ClusterIP/Service DNS等
    想象一下,如果您日常使用的研发测试Kubernetes集群,能够有以下效果:在办公网络下直接访问PodIP在办公网络下直接访问ServiceClusterIP在办公网络下直接访问集群内部域......
  • Dubbo-聊聊Dubbo协议
    前言Dubbo源码阅读分享系列文章,欢迎大家关注点赞SPI实现部分Dubbo-SPI机制Dubbo-Adaptive实现原理Dubbo-Activate实现原理DubboSPI-Wrapper注册中心Dubbo-聊聊注册......
  • 【Logback+Spring-Aop】实现全面生态化的全链路日志追踪系统服务插件「SpringAOP 整合
    承接前文针对于上一篇【Logback+Spring-Aop】实现全面生态化的全链路日志追踪系统服务插件「Logback-MDC篇」的功能开发指南之后,相信你对于Sl4fj以及Log4j整个生态体系的功......
  • 一起聊聊 Kotlin 协程
    正文大家好,我是朱涛,最近刚刚通过Google的认证,成为了Android以及Kotlin领域的谷歌开发者专家(GoogleDeveloperExpert)。这周我在GDG(GoogleDeveloperGroup)和字......
  • 聊聊Go里面的闭包
    以前写Java的时候,听到前端同学谈论闭包,觉得甚是新奇,后面自己写了一小段时间JS,虽只学到皮毛,也大概了解到闭包的概念,现在工作常用语言是Go,很多优雅的代码中总是有闭包的......