揭开神秘面纱,如何组织一次分布式压测
越来越多的企业开始意识到分布式压测的重要性。
随着互联网行业不断发展,系统架构越发复杂,业务场景越发多样化,对性能测试的要求也越来越高。传统压测方式已经无法满足业务和技术的发展需要,分布式压测,就是在这样的背景下应运而生的。
早在 2006 年前后,IT 系统稳定性就成为了当时集中式架构的挑战。随着互联网的快速兴起,当时的“Unix+小型机”架构遭遇了数据爆增的冲击。特别是在线交易、商业分析和数据库等关键业务系统,在 2010 年前后进入了 TB 甚至 PB 级,导致传统 IT 架构不堪重负,对 IT 系统的稳定性和可扩展性等提出了新要求。也就是从那时起,阿里巴巴开始了去“IOE”改造,采用 X86 服务器和标准存储与网络设备等,重新架设高稳定和可扩展的分布式 IT 系统。
2010 年后的 10 年,中国的互联网公司先后进入了分布式系统的改造和建设; 2020 年伴随着新基建的崛起,更推动了电信、金融、电力、零售、医疗、教育、政府机构等各行各业 IT 系统基于云计算的分布式进化。从集中式架构到分布式架构,IT 系统的稳定性不仅仅涉及到机房布线、网络通信、硬件部署、应用架构、数据容灾等,还需要对平台自身的精细化管控和保障,包括容量压测与评估、全链路压测等。
进入 2021 年,随着企业互联网与产业互联网的大繁荣,为基于分布式系统的 IT 系统稳定性打开了一个新赛道,分布式压测也被提上了日程。
如何用更少的预算完成指定当前业务规模的流量高峰,是技术的永恒主题。
今天我们就在上一期性能测试的基础上,讲讲分布式压测的目的、要解决的问题以及如何组织分布式压测等几个方面展开讨论。
分布式压测是什么?
要回答这个问题,我们首先要清楚分布式压测究竟是什么?
根据百度百科的定义,压力测试指的是主动产生流量,从而对服务造成计算压力,测试服务的性能与健壮性等。
根据关注角度的区分,可以分为分布式压测(客户端)与全链路压测(服务端)。
分布式压测指的是利用多台机器向目标机器产生压力,模拟几万用户并发访问,在压测的基础上做延伸,侧重于发压端的分布式与分散性。
从压测本身出发,压测的目的可分为以下四种:
1、优化:找到系统以及分布式系统中的短板,进行优化;
2、标准资源需求:现有逻辑在指定的资源下,能提供正常服务的临界值是多少,同步给与后续资源扩展时以数据支持;
3、流量回放:针对真实的流量,现有服务以及资源的表型形式;
4、业务演练:对特定业务做演练,提前发现并规避问题。
全链路压测一般指完全引入相关联的系统,真实模拟线上硬件环境,更多的是以请求为核心,完全模拟真实请求流量,通过引流等方式进行场景的模拟进行压测,更多的适用于业务链路较长的业务。通过全链路压测发现系统服务的数据流漏斗模型比例、瓶颈业务、高频业务、高可用节点等问题,给线上服务部署提供真实数据予以参考。
目的是考察从用户开始访问系统到完成全部业务的整个链条中,核心页面和交易关键业务的实际承载能力;模拟完全的真实情况来做到提前心里有数。验证的最好办法是让事件提前发生,通过全链路压测就可以提早发现问题。
分布式压测解决什么问题?
了解了基本的概念后,我们来看下分布式压测可以解决哪些问题。
简单来说,分布式压测可解决以下四方面的问题:
1、单机发压能力有限;
2、流量压力有地域分布等需求;
3、压测过程中的数据指标丰富;
4、压测结果数据汇总展示。
但是,分布式压测在探索和应用的过程中也会面临一些挑战。
比如发压机的调度问题,一方面发压机有可能在过程中出现宕机,另一方面由于发压机的资源配置不同,分配压力也不同,需对发压机的真实运行情况进行监控。
再比如基础数据的调度问题,需要处理好基础数据的分配与调度、多数据源之间的调度、冲突性基础数据之间的调度以及其他相关性数据的准备与入库,任何一个环节出错,都有可能影响整个压测过程。
如何组织分布式压测?
那么,一次完整的分布式压测过程应该是怎样的呢?
一般而言,分布式压测分为 6 个步骤:
1、筹备:准备被压测环境,可以是单独的测试环境,也可以是正式环境以及确定压测时间;
2、确定发压曲线:可以是阶梯型、线性上升型;
3、确定发压机分布:明确流量来源诉求;
4、明确目的:根据目的确定事务与接口;
5、准备基础数据:相关数据的准备以及数据调度的规划;
6、过程监控结果汇总:过程中做监控报警,压测完成之后做数据分析,结合全链路的监控,比如博睿数据 Bonree Net、Bonree Server 等基础监控产品,精确定位到性能瓶颈。
需要注意的是,在组织分布式压测的过程中,需检测发压端设定的流量是否都打到了目标服务器上;如果服务架构比较复杂,有可能有其他因素导致流量缺失等;也可能对发压资源使用预估不足,需对发压端的资源进行监控;同时需要结合全链路的监控,精确定位到性能瓶颈。
评论