本申请涉及计算机技术领域，特别涉及一种服务器集群的性能测试方法、装置、设备及可读存储介质。
背景技术：
目前业界主流的压测工具主要是有jmeter，loadrunner,apacheab等，压测过程中还需要用到很多监控工具，如nmon，zabbix等。因此每次压测之前都需要申请资源，部署一些工具后才能进行压测。所以传统方案存在以下缺点：
(1)传统方案缺少对测试结果和性能case的管理和维护，之前消耗的大量精力写的脚本在完成一次两次压测后就被丢弃。
(2)压测时本地环境搭建，前期准备比较耗时，按压力环境准备及调试平均2小时计算，大约250人日。
(3)不同环境之间网络有阻碍不能直接进行压测。执行分布式压测需要配置不同节点机器，每台机器需要配置，工作量巨大。
(4)压测数据难以沉淀，性能趋势分析困难，测试结果处理瓶颈，性能监控项及测试报告内容不丰富。
(5)缺少监控体系，难以对压测过程进行自动化监控。
(6)无法向用户展示不同阶段的性能数据，需要用户自己查询对比，效率低下。
如图1所示，传统jemter方案的链路比较简单，首先用户在本地准备脚本，使用jmeter工具向服务器发送请求，然后手工收集测试数据记录。压测期间需要到对应服务器查看资源使用情况，手工收集数据。因此，会有很多不利因素影响性能测试结果，如本地施压机资源，网络带宽情况等。
技术实现要素：
本申请的目的是提供一种服务器集群的性能测试方法、装置、设备及可读存储介质，用以解决传统的测试方案无法满足当前需求的问题。其具体方案如下：
第一方面，本申请提供了一种服务器集群的性能测试方法，包括：
根据上传请求，将测试脚本上传至分布式压测系统；
根据用户在web界面的操作，调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试；
在性能测试过程中，利用监控系统对所述服务器集群进行监控，得到性能数据；将所述性能数据落库，并在所述性能数据超过阈值时进行告警；
根据所述性能数据，生成测试报告。
优选的，所述根据用户在web界面的操作，调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试，包括：
根据用户在web界面的操作，生成定时任务；在达到所述定时任务的时间条件时，利用持续集成模块调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试。
优选的，在所述根据上传请求，将测试脚本上传至分布式压测系统之后，还包括：
对所述测试脚本进行在线编辑。
优选的，所述将所述性能数据落库，包括：
使用infulxdb持久化存储所述性能数据。
优选的，还包括：
根据所述性能数据生成性能趋势图，对所述性能趋势图进行可视化展示。
优选的，在所述根据所述性能数据，生成测试报告之后，还包括：
通过多种渠道将所述测试报告推送给目标用户。
优选的，所述监控系统包括以下任意一项或多项监控工具：influxdb、grafana、pinpoint、skywalking。
第二方面，本申请提供了一种服务器集群的性能测试装置，包括：
脚本上传模块：用于根据上传请求，将测试脚本上传至分布式压测系统；
测试模块：用于根据用户在web界面的操作，调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试；
监控模块：用于在性能测试过程中，利用监控系统对所述服务器集群进行监控，得到性能数据；将所述性能数据落库，并在所述性能数据超过阈值时进行告警；
报告生成模块：用于根据所述性能数据，生成测试报告。
第三方面，本申请提供了一种服务器集群的性能测试设备，包括：
存储器：用于存储计算机程序；
处理器：用于执行所述计算机程序，以实现如上所述的服务器集群的性能测试方法。
第四方面，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现如上所述的服务器集群的性能测试方法。
本申请所提供的一种服务器集群的性能测试方法，包括：根据上传请求，将测试脚本上传至分布式压测系统；根据用户在web界面的操作，调用jmeter-api执行测试脚本，实现对服务器集群的性能测试；在性能测试过程中，利用监控系统对服务器集群进行监控，得到性能数据；将性能数据落库，并在性能数据超过阈值时进行告警；根据性能数据，生成测试报告。
可见，该方法通过在web界面调用jmeter-api执行测试脚本，无需在本地部署客户端，即可实现一键自动化分布式压测，测试过程中监控系统的预警体系发挥作用进行告警，将性能数据落库，持续监测不同阶段的性能变化趋势，最终自动化生成测试报告。
此外，本申请还提供了一种服务器集群的性能测试装置、设备及可读存储介质，其技术效果与上述方法的技术效果相对应，这里不再赘述。
附图说明
为了更清楚的说明本申请实施例或现有技术的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为传统的基于jmeter的测试方案示意图；
图2为本申请所提供的一种服务器集群的性能测试方法实施例一的流程图；
图3为本申请所提供的一种服务器集群的性能测试方法实施例二的过程图；
图4为本申请所提供的一种服务器集群的性能测试方法实施例二中持续集成原理示意图；
图5为本申请所提供的一种服务器集群的性能测试方法实施例二中监控过程示意图；
图6为本申请所提供的一种服务器集群的性能测试装置实施例的功能框图。
具体实施方式
本申请的核心是提供一种服务器集群的性能测试方法、装置、设备及可读存储介质，通过在web界面调用jmeter-api执行测试脚本，实现一键自动化分布式压测，测试过程中监控系统的预警体系发挥作用进行告警，持续监测不同阶段的性能变化趋势，最终生成测试报告。
为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
下面对本申请提供的一种服务器集群的性能测试方法实施例一进行介绍，参见图2，实施例一包括：
s201、根据上传请求，将测试脚本上传至分布式压测系统；
具体的，用户上传压测脚本，上传后系统支持对测试脚本的在线编辑。
s202、根据用户在web界面的操作，调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试；
根据jmeter的运行原理，传统的jmeter工具是通过javaswing框架来调用底层依赖jar包，本实施例为了实现平台统一管理，通过web页面代替swing调用底层依赖。引入jmeter-api，支持分布式压测，压测完毕一键生成测试报告，在线查看下载测试报告等。
具体的，本实施例提供两种压测实现方式：一种是分布式压测系统直接调用jmeter-api执行测试脚本，另一种是分布式压测系统生成定时任务，在达到预设时间时，利用系统内部的持续集成工具调用jmeter-api执行测试脚本。
本实施例中，持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译，发布，自动化测试)来验证，从而尽早地发现集成错误。
jmeter是apache组织开发的基于java的压力测试工具。用于对软件做压力测试。jmeter可以用于对服务器、网络或对象模拟巨大的负载，分析不同压力类型下的整体性能。另外，jmeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证程序是否返回了期望的结果。
s203、在性能测试过程中，利用监控系统对所述服务器集群进行监控，得到性能数据；将所述性能数据落库，并在所述性能数据超过阈值时进行告警；
具体的，使用infulxdb持久化存储所述性能数据。所谓落库，是指压力测试过程会产生大量的性能数据类似tps，rt等，把这些数据储存下来，可以看出每个迭代的过程性能数据分析。
实际应用中，监控系统包括以下任意一项或多项监控工具：influxdb、grafana、pinpoint、skywalking。其中，influxdb是用go语言编写的一个开源分布式时序、事件和指标数据库，无需外部依赖。grafana是一个开源的数据监控分析可视化平台,支持多种数据源配置和丰富的插件及模板功能，支持图表权限控制和报警。pinpoint是开源的基于字节码注入的调用链分析，以及应用监控分析工具，特点是支持多种插件，ui功能强大，接入端无代码侵入。skywalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具，特点是支持多种插件，ui功能较强，接入端无代码侵入。
s204、根据所述性能数据，生成测试报告。
在生成测试报告之后，还可以通过多种渠道将所述测试报告推送给目标用户。此外，为了便于用户查看不同阶段的性能变化趋势，还可以根据性能数据生成趋势图，并对其进行可视化展示。
值得一提的是，本实施例支持多种协议类型脚本，例如dubbo，restful，kong加密接口等。jmeter本身只支持http请求或socket请求的接口，对dubbo接口、kong加密接口需要二次开发支持，本实施例对jmeter二次改造支持了不同类型的接口。具体的，引入第三方dubbo插件，支持dubbo接口，对于开放平台接口编写对称加密和非对称加密代码，支持kong加密接口。
上述dubbo接口是阿里巴巴开源的致力于提供高性能和透明化的rpc远程服务调用方案，以及soa服务治理方案，dubbo框架告别了传统的webservice的服务模式，进而改用provider和consumer模式进行服务。而kong是一个基于apachelicense2.0的开源项目,是一个云原生的快速可扩的分布式微服务抽象层，应用场景为微服务的api网关，类似于springcloud的zuul。
本实施例所提供一种服务器集群的性能测试方法，包括：根据上传请求，将测试脚本上传至分布式压测系统；根据用户在web界面的操作，调用jmeter-api执行测试脚本，实现对服务器集群的性能测试；在性能测试过程中，利用监控系统对服务器集群进行监控，得到性能数据；将性能数据落库，并在性能数据超过阈值时进行告警；根据性能数据，生成测试报告。可见，本实施例至少具备以下优点：
(1)压测脚本统一管理：传统方案缺少对测试结果和性能case的管理和维护，消耗的大量精力编写的脚本在完成一次两次压测后就被丢弃。本实施例深入解析jmeter的jmx脚本，提供脚本在线管理编辑功能，脚本可以多次复用在线调整，分类别管理，提升脚本使用效率。
(2)依赖包统一仓库管理：传统方案中，搭建本地压测环境比较耗时。由于jmeter非常轻便灵活，底层是java语言，支持二次开发，有开发基础的测试人员写一些插件支持复杂的协议和场景，但基本都放在本地供自己使用。本实施例通过平台把这些依赖包统一收集管理，用户使用这些依赖的时候不用自己安装直接在平台使用，方便快捷。
(3)在线执行压测，适应于各个环境，不依赖于实体机：传统方案中，执行分布式压测需要配置不同节点机器，不同环境之间网络有阻碍不能直接进行压测，对大规模并发支持不足。本实施例打通了网络隔离，摆脱了本地网段不通的情况。
(4)定时自动化执行压测，生成报告：由于环境资源有限，工作时间同时并发测试会有冲突，所以本实施例基于持续集成模块提供了定时压测功能。传统方案中压测数据难以沉淀，性能趋势分析困难。本实施例可以在工作时间通过定时任务自动执行性能测试，并实时计算性能测试数据，智能生成报告结果。除了人工执行产生的报告，本实施例另一亮点是自动化执行后报告多渠道的发送，比如钉钉通知，邮件等。
(5)监控预警体系：通过平台打造的监控体系方便压测过程中实时监控，一个视图监控瓶颈。支持一站式智能监控，及时预警，支持持续集成每天执行，监控体系，预警体系全方位告知关系人关注瓶颈问题。
(6)性能大盘：通过每天的压测数据沉淀，形成折线趋势图，利于分析不同阶段的接口性能情况。
下面开始详细介绍本申请提供的一种服务器集群的性能测试方法实施例二。
本实施例提供了基于jmeter工具的脚本管理以及执行的web页面，设计持续集成方案、报告多渠道人性化推送可触达、监控中心、分布式节点管理，把这四种需求集成到一个平台上，实现一键压测，定时自动化压测，分布式压测，持续集成，数据落库，报表展示。
测试过程如图3所示：用户上传压测脚本，上传后系统支持在线编辑，点击启动后直接向服务器集群施压或定时利用持续集成模块向服务器集群施压。向服务器施压过程中，监控中心开始运作，如果有资源阀值超过会开启预警邮件通知相关人，并且压测数据开始落库influxdb，压测完毕可一键生成测试报告，可选择邮件钉钉推送相关人员。此外，压测数据可从infulxdb库中查询并且形成趋势图。
关于分布式压测系统设计，通过web页面代替swing调用底层依赖，引入jmeter-api，支持分布式压测，测试报告生成及在线查看下载。引入定时任务，可定时执行脚本。
关于持续集成模块设计，在分层测试框架的支持下，本实施例将其与maven以及jenkins结合在一起，实现从构建自动化测试脚本开始，到分析测试结果并生成测试报告，最终汇总到测试平台的过程，取代原来的手工操作，减少测试人员的工作量。对测试脚本进行持续集成的目标是自动化构建测试用例，以便每天自动执行一次或多次这些过程，而不是每个周手动运行一次。使用持续集成的最大好处在于代码的更改会定期地自动被集成，各种信息一手掌握。图4是持续集成的原理框架。总之，本实施例中持续集成模块在分布式压测系统里面，是测试平台的一部分，用于定时构建，定时构建后触发推送功能。
关于监控系统设计，压测过程离不开各种监控，所以本实施例集成了多种监控工具，如pinpoint，skywalking，granfana，influxdb等。其中pinpoint和skyworking主要是监控一个接口链路耗时，granfana主要是监控一些服务器硬件资源，其他还有一些db和redis的监控。常规压测的时候无须各个监控来回切换，可提前设计预警规则，设置阀值，智能监控。自动化压测的时候性能数据智能落库，包含tps、rt等重要指标，便于后续分析不同版本的性能差异情况。压测过程中使用后端监听器监听性能数据，从jmeter的日志文件中提取性能数据，落库数据使用infulxdb持久化存储，redash、granfana等bi报表可以提取相关数据智能展示，当性能数据低于一定程度即可智能预警。
总之，整个监控过程如图5所示。压测过程中监控中心开始运作，如果有资源阀值超过会开启预警邮件通知相关人，并且压测数据开始落库influxdb，压测完毕可一键生成测试报告，可选择邮件钉钉推送相关人员。压测数据可从infulxdb库中查询并且形成趋势图。jmeter本身产生的报告文件包通过tomcat服务可使用户主动进入站点访问报告。
关于性能自动化设计，性能自动化，顾名思义性能自动化是指无须人为触发在某个特定的时间点执行性能测试，达到快速回归了解性能概况的方式。当一轮压测完毕后，产出稳定的测试脚本，上传分布式压测系统。之后若想持续观察这个接口的性能，就需要设计自动化方案，通过压测系统定时任务调用持续集成系统，持续产出压测报告，监控每一个版本的性能风险，通过邮件钉钉机器人通知关系人，每日批量产出的接口性能报告。值得一提的是，性能自动化其实是持续集成的一部分，通过每天跑定时跑来监测高优先级接口的性能情况，是压测沉淀出来的性能数据可以做成报表对比不同时期的性能情况，是本框架的一大特色。
本实施例中，主要通过web页面引入jmeter的api打造的压测系统在线执行压测或调用持续集成系统持续定时压测，同时压测过程中的监控中心的预警体系发挥作用进行告警，最终性能自动化每日产出报告通过邮件和钉钉消息发送关系人，同时每日的性能数据落库influxdb通过granfana和redash等可视化软件展示性能差异，对比不同版本之间的性能差异。最后完成报告推送。
可见，本实施例至少具备以下特点：(1)界面化管理解析jmeter测试脚本，支持各种协议脚本，水平扩容压测机器；(2)自动化执行性能测试，低成本持续产生报告；(3)压测数据落库，可持续监测不同阶段的性能情况；(4)报告多渠道人性化触达；(5)整合监控预警体系；(6)一个平台完成全流程性能测试。
从本实施例的效果来说，已支持多个业务线，多场景，多环境使用，pv超过一万，为公司节约了大量测试人力成本及硬件资源成本，也推动了开发开发性能自测，投入产出比高，无缝对接监控平台，监控项标准统一，水平伸缩可拓展架构，支持超大规模并发。自动化批量接口压测，沉淀性能数据，方便分析不同版本的性能状况监控自动预警，节省人力监控。资源归集，支持分布式节点，统一调配避免资源浪费，报告人性化触达，及时了解性能问题，支持多种协议类型，兼容不同类型接口测试。历史数据归档，便于对比形成基线。
下面分以下几点具体阐述：
第一点，硬件成本：试压机传统模式固定申请实体机，测试部门起码配备三台以上，通过本平台框架支持水平扩展，低峰期固定运行原来1/4的资源，高峰使用完后及时释放。一年消耗的费用传统模式单台3300元总计大约耗费10000元，本发明m(元)＝k*3300，k系数0.4左右，节约费用60％以上。
第二点，时间成本：按环境准备及调试最后报告编辑平均2小时，节省时间m＝2*k(人)*n(日)。k系数在80左右，n系数100，累计整个产研部门可以节约8000人日左右。
第三点，报表数据：传统手动留存不易统计，本方案加入实时报告，历史数据存库这些功能只能输出报表，有利于性能评估，提高稳定性。
综上，本实施例至少具备以下优点：
1、改造jmeter调用方式，原方式本地客户端调用jmeter测试脚本，本实施例基于web页面的完成基于jmeter-api的调用。
2、整合持续集成系统，定时执行。压测系统整合持续集成系统巧妙的解决了自动化压测的问题，可以利用空闲时间例如深夜进行压测，无须人为触发。
3、监控体系，预警体系，可视化平台灵活调用，展示效果一目了然。相比传统方案每台服务器每次压测时需要去安装nmon等监控软件节省大量人力，尤其是对于集群部署的服务。
4、自动化批量接口压测，沉淀性能数据，支持批量接口报告。之前一般情况下一次压测产生一份压测报告，但一个服务中包含很多个接口，单接口报告太片面，本框架支持数个接口同一份报告自动产出。
5、报告触达体系，通过钉钉，邮件等推送把聚合的报告发送给关系人。
6、性能大盘：基于压测数据已经落库，数据大盘就是通过可视化工具展示把数据库里的数据提取出来形成可视化的各类图标以供分析。持续自动化压测产生了丰富的性能数据，把这些数据加以利用，形成性能趋势图，可以评估每个迭代的性能概况。
下面对本申请实施例提供的服务器集群的性能测试装置进行介绍，下文描述的服务器集群的性能测试装置与上文描述的服务器集群的性能测试方法可相互对应参照。
如图6所示，本实施例的服务器集群的性能测试装置，包括：
脚本上传模块601：用于根据上传请求，将测试脚本上传至分布式压测系统；
测试模块602：用于根据用户在web界面的操作，调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试；
监控模块603：用于在性能测试过程中，利用监控系统对所述服务器集群进行监控，得到性能数据；将所述性能数据落库，并在所述性能数据超过阈值时进行告警；
报告生成模块604：用于根据所述性能数据，生成测试报告。
本实施例的服务器集群的性能测试装置用于实现前述的服务器集群的性能测试方法，因此该装置中的具体实施方式可见前文中的服务器集群的性能测试方法的实施例部分，例如，脚本上传模块601、测试模块602、监控模块603、报告生成模块604，分别用于实现上述服务器集群的性能测试方法中步骤s201，s202，s203，s204。所以，其具体实施方式可以参照相应的各个部分实施例的描述，在此不再展开介绍。
可以理解的是，在一些具体的实施例中，还可以包括：
报告推送模块：用于通过多种渠道将所述测试报告推送给目标用户。
由于本实施例的服务器集群的性能测试装置用于实现前述的服务器集群的性能测试方法，因此其作用与上述方法的作用相对应，这里不再赘述。
此外，本申请还提供了一种服务器集群的性能测试设备，包括：
存储器：用于存储计算机程序；
处理器：用于执行所述计算机程序，以实现如上文所述的服务器集群的性能测试方法。
最后，本申请提供了一种可读存储介质，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现如上文所述的服务器集群的性能测试方法。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
以上对本申请所提供的方案进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
1.一种服务器集群的性能测试方法，其特征在于，包括：
根据上传请求，将测试脚本上传至分布式压测系统；
根据用户在web界面的操作，调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试；
在性能测试过程中，利用监控系统对所述服务器集群进行监控，得到性能数据；将所述性能数据落库，并在所述性能数据超过阈值时进行告警；
根据所述性能数据，生成测试报告。
2.如权利要求1所述的方法，其特征在于，所述根据用户在web界面的操作，调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试，包括：
根据用户在web界面的操作，生成定时任务；在达到所述定时任务的时间条件时，利用持续集成模块调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试。
3.如权利要求1所述的方法，其特征在于，在所述根据上传请求，将测试脚本上传至分布式压测系统之后，还包括：
对所述测试脚本进行在线编辑。
4.如权利要求1所述的方法，其特征在于，所述将所述性能数据落库，包括：
使用infulxdb持久化存储所述性能数据。
5.如权利要求1所述的方法，其特征在于，还包括：
根据所述性能数据生成性能趋势图，对所述性能趋势图进行可视化展示。
6.如权利要求1所述的方法，其特征在于，在所述根据所述性能数据，生成测试报告之后，还包括：
通过多种渠道将所述测试报告推送给目标用户。
7.如权利要求1-6任意一项所述的方法，其特征在于，所述监控系统包括以下任意一项或多项监控工具：influxdb、grafana、pinpoint、skywalking。
8.一种服务器集群的性能测试装置，其特征在于，包括：
脚本上传模块：用于根据上传请求，将测试脚本上传至分布式压测系统；
测试模块：用于根据用户在web界面的操作，调用jmeter-api执行所述测试脚本，实现对服务器集群的性能测试；
监控模块：用于在性能测试过程中，利用监控系统对所述服务器集群进行监控，得到性能数据；将所述性能数据落库，并在所述性能数据超过阈值时进行告警；
报告生成模块：用于根据所述性能数据，生成测试报告。
9.一种服务器集群的性能测试设备，其特征在于，包括：
存储器：用于存储计算机程序；
处理器：用于执行所述计算机程序，以实现如权利要求1-7任意一项所述的服务器集群的性能测试方法。
10.一种可读存储介质，其特征在于，所述可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时用于实现如权利要求1-7任意一项所述的服务器集群的性能测试方法。
技术总结