再谈全链路压测

本文涉及的产品
性能测试 PTS,5000VUM额度
简介: 以我现在所在的银行业务系统来说,目前的现状大概有这些:业务逻辑太复杂、系统庞大、子系统较多、系统间解耦程度较低、调用链路较长、核心系统环环相扣。

之前的博客,有对业内比较出名的几家互联网大厂的全链路压测方案进行过整理和总结,传送门:聊聊全链路压测-


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


时隔一年多,由于性能测试及相关知识的学习实践,对其有了新的认识,这里,再次聊聊我对全链路测试的理解。。。

 

目前的现状


以我现在所在的银行业务系统来说,目前的现状大概有这些:业务逻辑太复杂、系统庞大、子系统较多、系统间解耦程度较低、调用链路较长、核心系统环环相扣。


在这种情况下,常规的性能测试工作内容,大概如下:


①、只能进行独立系统的压测工作,导致压测任务量较大;

②、强依赖系统较多,第三方调用面临种种限制,只能通过mock方式解决;

③、没有较为独立的性能测试环境,UAT和PAT测试数据差异较大,无法给予上线一个较为准确的

容量评估;

④、项目排期没有预留足够的性能测试时间,导致需要经常加班甚至通宵;

⑤、工程师文件建立较为薄弱,对系统性能的认知和重视度不足,往往让人觉得沮丧;


上面的几种情况,据我了解,在大多数公司都存在类似的情况,这些因素导致面临着越来越高的数据冲击和越来越复杂的业务场景,急需一种手段来保障和提高系统的高性能高可用。

 

面临的挑战


除了上面所说的技术层面的问题,要开展全链路压测,还面临如下的几点挑战:


①、由于全链路压测涉及的系统及场景较多,因此需要跨团队沟通、跨系统协调改造,公司体量越大,这一点难度就越大;


②、全链路压测涉及的系统较多,且不同的系统架构也有所不同,因此需要考虑:机房管理、基础网络、DB管理、持久存储、中间件、应用部署、流量接入、监控与运维保障等多方面


③、全链路压测的目的是找到系统调用链路薄弱环节并优化,这就要求对整个调用链路涉及的系统进行进行准确的容量规划,因此环境和配置,是必须重视的一点;


当然,可能还存在其他问题,比如性能测试团队成员的技术水平是否满足要求、管理层的支持力度等方面,毕竟,这是一项很庞大复杂的软件工程项目!!!


不过全链路压测的优点也很明显,比如:优化联络薄弱环节可以提高系统的可用性,容量规划可以节省成本,提高效率

 

开展前的准备工作


在开展全链路压测之前,我们需要做哪些准备工作?


①、业务梳理:覆盖全部的业务场景,是难度很大且不理智的选择,一般来说只需要筛选出高频使用的功能、核心功能以及基础功能即可;


②、场景梳理:场景梳理也是很重要的一项工作,因为只有确定了被测场景,我们才能设计合理的测试方案和策略,场景覆盖正常操作、异常操作即可;


③、流量模型:“我们往往对高并发一无所知!”因此需要通过监控分析等手段,得到日常流量场景、峰值流量场景下各系统的流量以及配比,进行一定的放大,来作为全链路压测的流量参考模型;


④、数据处理:全链路压测通常在生产环境进行,所以防止数据污染是必须考虑的问题,一般来说都是通过对入口流量进行标记区分、数据隔离、影子库等方式来避免,当然,还需要做好灾备工作;


⑤、实时监控:无论是压测开始前还是测试进行中,都需要及时且可视化的获取到系统的状态变化,方便及时排查定位问题,也避免压测对正常的服务造成干扰;监控的重点,主要是对应服务的TPS、不同百分比的RT、成功率、资源耗用、服务状态、告警等信息;

 

全链路压测平台架构设计


要开展全链路压测,那么一个合理高效可用的压测管理平台,是很有必要的,参考了很多全链路压测的设计思路,我个人的想法中全链路压测平台的架构设计,主要由以下几部分组成:


①、Controller:主要任务为压测任务分配、Agent管理;


②、Agent:负责心跳检测、压测任务拉取、执行压测(多进程多线程方式);


③、Task Service:负责压测任务下发、Agent的横向扩展,以确保压测发起端不成为瓶颈

(可以利用RPC框架来实现);


④、Monitor Service:接收Agent回传的监控和测试数据日志,并转发给消息队列,让Compute Service进行汇总计算展现;


⑤、Compute Service:对压测结果进行计算,并结合Grafana等可视化工具进行界面展示;


⑥、Log Service:日志服务,即无论压测机还是服务应用在测试过程中产生的日志,都统一收集,方便进行问题排查定位;


⑦、Elasticsearch/Influxdb:对压测产生的数据存储;


⑧、Git:压测脚本的版本管理;


⑨、Gitlab:作为数据仓库进行版本管理,Agent主动拉取脚本执行;


⑩、Redis:主要用于配置信息管理;


PS:当然,我个人的构思存在不完善或者有待仔细斟酌的地方,这里只是给一个参考。具体的架构设计图,可参考京东的全链路军演系统ForceBot的架构设计,如下图:


640.jpg

 

完成了上面的工作,接下来就可以开展全链路压测的工作了。当然,有一点需要说明:全链路压


测并不适用于中小型公司,一方面因为成本,另一方面,不适合而已。最后,在开展性能测试之前,请认真思考:当我们讨论性能测试时,们在说什么?https://www.cnblogs.com/imyalost/p/10353954.html

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
6月前
|
负载均衡 NoSQL 关系型数据库
性能基础之全链路压测知识整理
【2月更文挑战第16天】性能基础之全链路压测知识整理
302 11
|
6月前
|
存储 缓存 中间件
高可用之全链路压测
【2月更文挑战第30天】全链路压测是提升系统可用性的关键方法,它模拟真实流量和业务场景在生产环境中测试,确保性能、容量和稳定性。
|
监控 测试技术 UED
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
286 0
|
域名解析 网络协议 数据可视化
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
205 0
|
SQL 监控 关系型数据库
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(3)
199 0
|
数据可视化 测试技术 定位技术
全链路压测(14):生产全链路压测SOP
从实践经验的角度出发,生产全链路压测在技术实现上没有太多新花样,但要在不同的业务和企业落地,就各有各的实践路径。对于没有太多经验的同学来说,全链路压测的落地,大多还是基于个人的经验和熟悉的领域,即都是在局部作战,缺乏全局的视角和可视化地图。从全局来讲,缺少适用于自己的全链路压测最佳实践。
全链路压测(14):生产全链路压测SOP
|
存储 SQL 缓存
全链路压测(13):高可用和性能优化
业务场景复杂化、海量数据冲击下,发现并解决业务系统的可用性、扩展性以及容错性问题。
全链路压测(13):高可用和性能优化
|
监控 Java 测试技术
全链路压测(12):生产压测必不可少的环节
在生产环境开展全链路压测,相对于测试环境来说风险和成本都是比较大的。因此需要一套严格的流程管控和响应机制,以及高效的团队协同体系。
全链路压测(12):生产压测必不可少的环节
|
SQL 缓存 运维
全链路压测(10):测试要做的准备工作
功能验证环境即用来验证技术组件本身的功能正确性和接入性能损耗的环境,有独立的随时可用的环境最好。如果考虑到成本,也可以用线下性能环境来进行验证。
全链路压测(10):测试要做的准备工作
|
缓存 监控 安全
全链路压测(11):聊聊稳定性预案
从业务角度来讲,无论技术做任何的改动和优化,最终的目的都是为了业务目标的达成。而系统的稳定性,无论从用户体验还是业务目标达成的角度来看,都是不可忽视的一环。
下一篇
无影云桌面