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

再谈全链路压测

时间:2023-03-15 15:58:25浏览次数:45  
标签:场景 压测 系统 Agent 谈全 测试 链路

转载:https://www.cnblogs.com/imyalost/p/10525766.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的架构设计,如下图:

 

完成了上面的工作,接下来就可以开展全链路压测的工作了。当然,有一点需要说明:全链路压测并不适用于中小型公司,一方面因为成本,另一方面,不适合而已。

最后,在开展性能测试之前,请认真思考,当我们讨论性能测试时,我们在说什么?

 

标签:场景,压测,系统,Agent,谈全,测试,链路
From: https://www.cnblogs.com/ceshi2016/p/17218824.html

相关文章

  • 数据链路层
    3.1数据链路层概述链路:就是从一个结点到相邻结点的一段物理线路,而中间没有任何其他的交换结点。数据链路:是指把实现通信协议的硬件和软件加到链路上,就构成了数据链路......
  • 基于OFDM+STBC通信链路的误码率matlab仿真
    1.算法描述      空时分组码(STBC)与正交频分复用(OFDM)相结合的STBC-OFDM技术可以有效对抗多径效应和频率选择性衰落,在复杂通信环境中提高传输效率,降低误码率,并且编译......
  • 基于OFDM+STBC通信链路的误码率matlab仿真
    1.算法描述空时分组码(STBC)与正交频分复用(OFDM)相结合的STBC-OFDM技术可以有效对抗多径效应和频率选择性衰落,在复杂通信环境中提高传输效率,降低误码率,并且编译码简单。在Mat......
  • skywalking 实现收集基于虚拟机环境 dubbo微服务链路跟踪案例
      安装skywalkingjavaagent  下载链接:https://archive.apache.org/dist/skywalking/java-agent/   dubbo-provider和dubbo-client节点都安装并配置skywalking......
  • 6、Redis禁用危险命令和压测工具
    1.Redis禁用危险命令Redis危险的命令有哪些?>FLUSHALL会清空Redis所有数据>FLUSHDB会清除当前DB所有数据>KEYS*在键过多的时候......
  • HCIP-网络类型及数据链路层协议
    前言:网络类型是根据我们数据链路层所运行的协议及规则来划分。网络类型的分类P2P----点到点---pointtopointMA---多点接入网络BMA---广播型多点接入网络NBM......
  • 轻量级压测平台RunnerGo简介及使用教程
    RunnerGo是一个功能强大,使用简单的性能测试平台,它基于go语言开发,支持接口管理、自动化测试、性能测试等功能。更重要的是,RunnerGo完全开源。下图为RunnerGo首页的数据大屏......
  • 自实现分布式链路追踪 方案&实践
    前言:排查问题是程序员的基本能力也是必须要会的,在开发环境,我们可以debug,但是一旦到了服务器上,就很难debug了,最有效的方式就是通过日志揪出bug,而一次请求的日志如果没有一个......
  • 基于API+MQ消息双链路数据同步中间件技术方案
    一、数据同步的背景及意义随着公司业务的发展,业务系统也会变得越来越复杂繁多,业务数据或分散、或冗余于各个业务系统中,增加了数据的管理难度和维护成本。因此,中心......
  • 2个月内如何在千人团队落地压测平台?
    本来今天要继续更新devops系列的文章,昨天下午看到一篇技术文章,讲到了从零开始落地项目的经验。正好我也有过类似的实践,临时写了这篇文章,如标题所述:3个人,如何在2个月内在......