00:00
Hello,大家好,我是fan啊,今天给大家分享一下分布式性能测试框架,嗯,在最近的较长一段时间的工作中。我一直在做啊性能测试这块的工作,然后有时候我们会遇到单机去发起压力的情况,不能满足我们的啊压力需求,我们就需要使用到分布式性能测试框架啊,所以啊我也自己对fan原有的框架进行了一个分布式的拓展。啊,今天给大家分享一下啊,具体的设计以及呃实现的一些逻辑。啊,首先我们看一下整体设计的架构图啊,这里面采用了啊,比较常用的有master和SLAVE2种那个服务啊这种架构,然后嗯,这个跟jackins或者nreer这种分布式测试框架啊,设计的思路是一样的啊,然后统一的由这个啊master服务提供一个对外的接口啊,以及任务的分发,还有就是呃,一些用户跟压测没关系的这些用户业务的实现,比如说用力的保存啊,呃,用力的读取啊,修改啊,或者说关联一些监控啊这种啊业务的实现,然后大家看。
01:33
这个地方有一个权限的校验啊,这里面要着重的讲一下就是呃,这里的权限校验不仅是对用户访问的权限,一些编辑权限这种校验,还有最重要的是对API的校验,因为在我的设计里面啊,中级的测试用例是通过格脚本或者说是Java脚本啊上传到。服务,然后存在数据库或者说是某个地方,而这种脚本在执行的过程中,它是可以访问啊服务本身自己的API的,就内部的API啊,包括这个它master服务,将这个用例下发到slave服务之后,它也是可以访问啊六节点的这个服务的,呃,API的,那这样的话有一个好处。
02:23
就是我们可以使用脚本对服务的一些数据或者常量进行一些修改。但是这也是一个巨大的风险啊,一般我不提倡这么做啊,最好是在框业务框架层面就把这个工作给做了啊,不要让用户去访问,但是用户在呃自己本地调试脚本的时候,经常会需要用到呃整个项目框架所提供的API进行调试,或者查看一些日志啊,或者说是进行一些简单的验证啊,这个时候我他有可能会把这些。
03:01
用例里面调用。框架API的这些代码没有注释掉,它就上传到这个呃管理服务当做一个用例,然后这个用例如果是在呃,通过验证在执行的过程中,它就有会改变呃,Sleep或者是must服务自己的一些数据,比如说有可能是一些常量。啊,比如说就可能是超时时间啊,或者跟用户相关的啊,用户的啊配置这样,所以这个API校验主要是避免用户去调用呃,比较关键的API。然后。就是会影响到整个服务的数据,然后会影响到下一个用力的执行,这样,然后呃,我们先看左边吧,左边这个拉是。呃,用来做那个节点信息管理的啊,这里面啊,16个节点的话,去向NAS注册啊,把自己的那啊服务的IP啊端口还有一些原数据,那包括服务运行的状态这样啊,因为在这个里面我设计的一个。
04:19
思路主要是参考了n re啊,它里面有一个嗯嗯算是限制吧,就是呃,一个节点一次性只能运行一个用力,这也就跟我刚才呃这个API这块的限制。呃考虑是一致,就是它用力之间可能会相互影响,因为用力使用同一套数据的呃服务的话,嗯影响可能会有影会有影响,而且呃对于同一台机器运行多个性能测试,用力的话,从硬件资源的角度上来说也会有影响啊,所以说目前呃我的这个设计也是跟他是一样的,是通过一个。
05:06
限制就是说一个节点只能同时执行一个测试用例,然后在这里注册,注册上自己的数据,然后同步上自己的运行状态,然后这个运行状态在master节点下发任务的时候,还有就是呃,Slave接到任务的时候都会进行验证。然后master节点是怎么获取这些信息呢?啊,就是master节点也是通过去跟NAS进行一些数据的交互,然后去拿到呃六节点的呃,注册拿的这些信息,然后根据这些信息去下发呃,不同的任务到不同的节点上,然后这样执行。然后我们再看右侧这个监控,呃,这个监控画的是有一点点,嗯呃,比较宽泛,第一个监控是针对那个呃,16个节点的监控。
06:01
因为在我最初的设计方案里面,呃是没有拿S的,因为呃这个拿S是跟公司现在的技术上略要保持一致,所以说引用的拿S在我之前的设计全是由呃master节点呢,一些定时任务,还有一些呃master节点直接跟16节点的呃相互请求来实现这个呃节点的管理啊,状态的同步的,嗯这个监控的话。嗯,一部分是我们公司自己内部的监控,主要用于监控呃,被测节点的信息,以及被测节点上下游节点的信息啊,还有就是QPS啊,RT这种监控就这些,然后这里面我画的这个监控,其实还有一部分是对内节点的进行硬件级别的监控,还有就是QPS级别的监控,这个监控有好处就是我可以啊,在用力我运行的过程中啊,达到一个自动停止的目的。
07:00
因为在压测过程中,很有可能一些指标会啊,超出我们的预期啊,继续压测可能会对服务造成一些呃不稳定的因素,所以说这个监控是做在这里,是做这个用途的。嗯,这个这块实现的起来是比较复杂的,技术上也比较多,嗯,目前还在努力接入实现我刚才说的功能,所以说这里面画的也比较简单了啊,然后我们看这个。嗯,用例这块,呃,我我刚才提到就是我们的终极用例是用group脚本,或者说啊Java脚本啊,大家就可以把它当做一个,呃文本文本信息啊,这个存储的方式的话啊,目前是放在那个getlab库里面。啊,也就是说,呃,用户并不实际上传这些实际的内容,他只是上传用例的一个地址。就可以,或者说是用户把实际的脚本上传到呃服务,然后服务再把这些呃用例存到GALA库里面,嗯这个在一开始的时间里面,我是想的直接设计从呃存放在MYSQL里面啊,但是这种不不便于去管理啊,因为我们本地去做用例的编写的话,可能呃get还是比较方便的啊,传完之后呃直接就上传呃push到那个仓库仓库里面,然后。
08:29
可以通过这个master节点啊,去仓指定的仓库,可以选仓库,以及进行一些简单的过滤,去把这些用例选出来之后,然后去点击执行,是这样啊,这个也是参考了green它的一个呃设计啊,这个我觉得还是挺好的,因为如果是呃用户直接把这个脚本上传的话,嗯,有有点不是太特别可控。啊是这样,然后这就是读取用例,然后配置的话,这这有一个数据中心,这个数据中心呃主要是用来做呃,第一是呃用力的数据,因为有些测试数据我们会比较大,可能几十万上百万条,然后我们不可能去把这个东西存在用例里面,然后我们就需要把存在一个数据中心,然后呃。
09:23
Master节点在下发的时候,会把这个信息也都下发到内节点上,然后再去数据中心拿这些数据去执行我们的测试用例,然后这个数据中心呢,还有一些就是我们的监控信息,以及呃,内节点运行的过程中的一些啊数据,比如说他本地记的一些啊,像QCSRT错误率这些啊,会同步到数据中心去做一个啊,那个整个测试过程中数据的一个展示啊,大概就是这样,然后。嗯,整个这个架构呢,没有前端啊,因为我不太会啊,我也只是负责后端的一些啊,技术的一些验证和实现啊,然后大概的架构图就是这样的。
我来说两句