当前位置:网站首页>【性能测试】全链路压测

【性能测试】全链路压测

2022-07-05 16:27:00 bulabula2022

一、什么是全链路压测

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

像金融系统涉及到部门多,比如笔者曾经做性能测试时接触银行一个理财产品以及金融电商项目涉及关联系统:NDS(核心交易系统,本行金钱交易系统),CII(公安网验证,联网核查身份证信息系统),ESB(银行对外开展的金融业务电商平台),ICS,BPH(它行卡转账系统),SMS(短信系统),BLN(黑名单系统),通联(第三方支付平台,五要素验证),邦盛(第三方反欺诈平台验证),鹏元(第三方征信平台),ANF(东亚反欺诈系统),商汤OCR(人脸识别系统),ICA(银联综合认证,四要素认证),BDP(银行内部大数据平台),网跨平台,清算平台等,

像这么多的关联系统,如果是自己内部系统,可以沟通相关部门配合,搭建个性能压测环境,进行全链路演练。此外,如果外部第三方平台,基本全链路压测时要做个挡板服务器(掉第三方api时设置返回时间再实际范围内随机)模拟第三方,一般第三方服务也不一定配合做压测,即使配合,给的压测服务器也一般,无法作为压测环境

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

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

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

1、业务模型梳理

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

针对性的进行扩容准备,

2、数据模型构建

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

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

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

②、数据脱敏

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

③、数据隔离

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

3、压测工具选型

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

可以基于这些压测工具进行二次开发。考虑到压测量较大的情况下回传测试结果会对agent本身造成一定资源占用,可以考虑异步上传,甚至事务补偿机制。

4、压测环境搭建

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

5、系统容量规划

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

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

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

6、测试集群部署

能做全链路压测的业务系统,基本都是分布式系统架构,服务集群部署和负载均衡。

需要解决的问题有:

①、服务间通信问题

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

同步调用:

REST(JAX-RS,Spring Boot)

RPC(Thrift, Dubbo)

异步调用:

(Kafka, Notify, MetaQ)

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

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

②、负载均衡问题

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

③、容灾问题

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

2、容灾测试遵循的标准

①、模拟极端错误发生,测试业务恢复功能和业务持续性流程;

②、发现平台潜在的隐患,确保出线突发情况时平台能够正常运行;

③、在极端流量冲击下,牺牲一小部分非主要业务功能或者一小部分用户体验,保障整体系统的稳定以及主要功能的正常运行(分流、服务降级);

④、进行测试时,需要同步分析日志(确认当前展示的结果是否是因为容灾测试用例生效而出现的)。

3、容灾测试的要点

①、核心原则:基于业务影响分析,全面提高IT系统的抗风险能力;

②、关注两个重要指标:RTO(恢复时间)和RPO(数据丢失量);

③、做好三件事:数据传输、业务切换、容灾演练和监控;

④、实现操作系统、文件、数据库、应用四项恢复。

7、数据收集监控

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

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

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

原网站

版权声明
本文为[bulabula2022]所创,转载请带上原文链接,感谢
https://blog.csdn.net/baidu_31295661/article/details/125560442