越来越多的企业开始意识到分布式压测的重要性。
随着互联网行业不断发展，系统架构越发复杂，业务场景越发多样化，对性能测试的要求也越来越高。传统压测方式已经无法满足业务和技术的发展需要，分布式压测，就是在这样的背景下应运而生的。
早在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等基础监控产品，精确定位到性能瓶颈。
需要注意的是，在组织分布式压测的过程中，需检测发压端设定的流量是否都打到了目标服务器上；如果服务架构比较复杂，有可能有其他因素导致流量缺失等；也可能对发压资源使用预估不足，需对发压端的资源进行监控；同时需要结合全链路的监控，精确定位到性能瓶颈。