CN111552628A - 一种针对图数据库及图服务接口进行分布式压测系统及方法 - Google Patents

Abstract

本发明涉及互联网技术领域，具体涉及一种针对图数据库及图服务接口进行分布式压测系统及方法，提出的系统包括接入层模块、计算引擎模块、存储层模块、压测日志分析模块、前端展示模块、管理模块、分布式资源管理模块。提出的方法包括两个步骤。本发明，将多种压测方式集成一体，以满足小中大企业的大中小各种项目及数据库的压测需求，并且同时支持离线报表，在线报表，实时报表，历史报表的展示及查看，以及对比功能，支持预先数据源，通过分布式读取数据源的方式进行请求压测；支持在客户端提交可执行jar进行实时造数压测，除了支持图数据还支持其它主流数据库的压测，当设置参数目标为图数据库时，就会自动启动金融银行数据模型。

Description

一种针对图数据库及图服务接口进行分布式压测系统及方法

技术领域

本发明涉及互联网技术领域，更具体地说，它涉及一种针对图数据库及图服务接口进行分布式压测系统及方法。

背景技术

压力测试其是一种通过外部行为触发对服务器部署的服务进行尽可能最大化的请求策略，旨在通过大量的数据请求以此达到并找到服务的瓶颈，以方便优化软件性能。在进行此压测性能测试时，通常需要通过服务器的CPU、内存、磁盘IO、磁盘容量、服务器的每秒查询率(Query Per Second，QPS)、网络IO、小到接口的并发数等数据得到服务器的压力测试结果。而分布式压测，就是利用多台物理服务器设备，对某一被压测端(数据库，服务接口)进行大批量的请求策略，与非分布式压测的区别是可以模拟真实的并发场景，以及提高压测负载，相对容易检测出被压测端(数据加，服务接口)的性能瓶颈。而本发明中，着重提出图数据库进行压测，是因为图在数据库的范畴内，相比传统的数据库是更复杂的，可以理解为是Nosql数据库中的一种，而之所以要针对图数据库进行性能测试及调优，主要决取于业务场景的复杂度，通过压测可以优化图数据库的图查询以及图数据插入的性能。

了解到图数据库及图服务的压力测试的主要目标之后，通常采用以下几种方式进行压力测试。

第一种，客户端提交压测任务，服务端将压测日志写入文件，等压测任务完成后，收集各个机器上的文件，然后读取文件、汇总及绘制报表；

第二种，客户端提交压测任务，服务端将压测日志写入支持OLAP查询的数据库或系统，然后通过前端页面通过OLAP查询可以实现即席展示报表。

第三种，客户端提交压测任务，服务端将压测日志写入到流式框架如strom,flink,sparkstreaming。然后前端页面，可以实时显示性能报表及性能波动图进行。

但是目前所有的压测工具的实现，仅支持其中一种实现方式，而单一的实现功能在大数据量或小数据量的情况，所带来的计算成本是有很大差异的。而且同一个压测系统中不仅仅只为一个业务而进行，一家互联网企业会有不同的项目组，不同的项目组还会有多个不同的系统或数据库，而随着目前互联网的发展，海量数据不段输入，在硬件资源及成本的压力下，对数据库及服务接口的性能要求会日益增长。

而针对图数据库或服务进行压测，主要的难点是要模拟实际场景的图关系有实体数据，以此要覆盖图的查询场景。因为图数据库的目标主要是为了解决图在查询过程中的响应速度，如K层展开，全路径查询，最短路径，社区发现，pagerank，图密度，最大联通图的查询。随意的压测数据，将会导致在性能调优时，只会偏向一种的性能查询优化，或如果压测数据过于复杂，这些图的查询将没有任何意义。

此外，在客户端提交压测任务，通常大多数的压测请求都是单一数据源的压测请求，很难满足压测完数据后，还能用上数据进行查询。也就是目前还没有一款系统是专门针对数据库进行压测，更别提再针对图数据库的业务抽象场景下测试压测。

综上上述所述，也就是说目前现有技术存在的技术问题为：

<1>没有将多种压测方式集成一体，来满足不同企业及项目的需求，导致报表数据分析途径单一化且没有统一管理报表的历史归档文档及对比功能或工人干预比较多。

<2>提交压测任务方式单一，数据源单一，针对不同的数据库，因为没有统一规范，需要根据不同的业务场景临时做大量的编程工作，导致人工成本很大。

<3>技术不完善，没有针对数据库进行压测，需要独立编程起服务才能实施。

<4>在针对图数据性能优化中，由于数据量小且维度单一，优化代表性较低，尤其是在金融银行业务场景中，由于没有获取实际的场景数据，在金融银行的图应用领域中，难以发挥出该图数据库的最大性能。

因此，在长期的研发过程中，发明人对客户端压测报表问题进行了大量的研究，提出了一种集成多种压测方式与一体并加入分布式的方式以满足不同项目及业务需求的系统及方法，以解决上述技术和业务问题。

发明内容

针对现有技术存在的不足，本发明的目的在于提供一种针对图数据库及图服务接口进行分布式压测系统及方法，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供了如下技术方案：

一种针对图数据库及图服务接口进行分布式压测系统，包括接入层模块、计算引擎模块、存储层模块、压测日志分析模块、前端展示模块、管理模块以及分布式资源管理模块；

所述接入层模块用于为所述计算引擎模块提供发送数据源；所述计算引擎模块在接收到所述计接入层模块发送的数据源后，通过分布式的方式对接收到的数据进行处理，并在处理过程中采集系统日志或接口日志以及配置信息，并将采集的系统日志或接口日志以及配置信息写入所述存储层模块；

在所述系统日志或接口日志以及配置信息存储完毕后，所述管理模块将会监控所述系统日志或接口日志以及配置信息存储任务的完成成功与否，如果完成成功，所述压测日志分析模块将会读取所述系统日志或接口日志以及配置信息进行压测统计分析，如果所述系统日志或接口日志以及配置信息存储任务是通过实时的方式，则会实时统计分析结果，并将其实时统计的分析结果展示至所述前端展示模块；

所述分布式资源管理模块用于负责分布式压测集群资源分配及管理以协调各个项目侧之间的压测任务。

进一步的，所述分布式压测集群资源包括CPU总核数、内存总量以及磁盘总量。

进一步的，所述计算引擎模块包括控制中心模块、资源管理模块以及任务管理模块；

所述控制中心模块为Metal Control Center，所述资源管理模块为MetalResourceManager即MetalStrom的资源管理器，所述任务管理模块为MetalTaskManager即MetalStorm的任务管理器；

所述Metal Control Center用于接收并收集MetalResourceManager的心跳及日志信息、用于接收并收集MetalTaskManager的心跳及日志信息、用于处理客户端任务请求分配，读取主程序并将主程序提交至MetalTaskManager，再由MetalStorm执行主程序进行压测；

所述MetalResourceManager用于负责给提交的任务的资源进行分配和回收、用于与控制中心通信，将资源分配情况发送给控制中心；

所述MetalTaskManager用于负责任务的管理，包括执行和kill、用于与控制中心通信，将任务的执行情况发送给控制中心。

进一步的，所述的针对图数据库及图服务接口进行分布式压测系统，还包括客户端、计算引擎端以及被压测端；

所述客户端用于负责客户端展示、提交任务展示、报表展示以及可视配置；

所述计算引擎端用于负责客户端提交任务，并审核该任务的可行性以及执行该任务；

所述被压测端包括服务端接口和数据库。

本发明还提出一种针对图数据库及图服务接口进行分布式压测方法，包括如下步骤：

步骤一、操作客户端，操作客户端包括三种操作方式，分别如下：

第一种、配置普通的http请求参数，此时又有两种选择，当不选择指定数据源时，此时提交的压测任务请求方式将会单一化，也就是每次请求的数据的内容都是一至的，这种情况用于测试服务端接口的连通，可行性，以及QPS的支撑量；

当选择了指定数据源，此时提交的压测任务请求将会读取该数据源，在后续的压测请求中将会以该数据源为样例，只要准备的数据源中数据不一致，那么每次请求的数据将也会不一致，这种场景用于测试服务端接口的稳定性，可行性，以及QPS的支撑或链路业务需求，但相对于单一化的提交请求，唯一需要多做的是需要事先准备好数据源，此外这种方式也用于数据库压测；

第二种、配置可执行jar，可通过可执行jar根据业务的实际场景源源不断的造出不同的数据，提交了可执行jar后，后续的数据流程中将会有模块执行该jar。

第三种、客户端提交还涉及一个核心功能压力测试就是图数据库及图服务接口，该选项将在前端的单选框中选择，选项有【图数据库】【图服务接口】，当选择了图数据库选项时，必须上传可执行jar，此时系统会自动配置金融银行的数据源模型作为后续执行器的数据来源；

步骤二、创建分布式实例

读取数据源，如果是单机，则将数据源放到本地，如果是分布式集群，则将数据存储在hdfs分布式文件系统中，需要将文件以hash分块的方式，通过scp或ftp服务输出至集群中的其它机器；

获取数据源，获取到数据源后将会创建数据请求；

请求过程，在被压测端的服务器上部署日志采集器用于采集被压测端的性能参数，然后写入到消息列队或分布式文件系统中；

获取结果，通过查看压测报告即可。

综上所述，本发明主要具有以下有益效果：

1、本发明，将多种压测方式集成一体，以满足小中大企业的大中小各种项目及数据库的压测需求，并且同时支持离线报表，在线报表，实时报表，历史报表的展示及查看，以及对比功能；

2、本发明,支持预先数据源，通过分布式读取数据源的方式进行请求压测；支持在客户端提交可执行jar进行实时造数压测；

3、本发明,除了支持图数据还支持其它主流数据库的压测，当设置参数目标为图数据库时，就会自动启动金融银行数据模型；

4、本发明,支持历史报表存储，以及报表之间的对比，并且在进行数据性能压测时会读取每次压测时的数据库配置，便于在报表对比时，可以提供参数优化。

附图说明

图1为一种实施方式的针对图数据库及图服务接口进行分布式压测系统的架构示意图；

图2为一种实施方式的针对图数据库及图服务接口进行分布式压测系统的流程示意图。

具体实施方式

以下结合附图1-2对本发明作进一步详细说明。

实施例

一种针对图数据库及图服务接口进行分布式压测系统，如图1所示，包括接入层模块、计算引擎模块、存储层模块、压测日志分析模块、前端展示模块、管理模块以及分布式资源管理模块；

所述接入层模块用于为所述计算引擎模块提供发送数据源；所述计算引擎模块在接收到所述计接入层模块发送的数据源后，通过分布式的方式对接收到的数据进行处理，并在处理过程中采集系统日志或接口日志以及配置信息，并将采集的系统日志或接口日志以及配置信息写入所述存储层模块；

在所述系统日志或接口日志以及配置信息存储完毕后，所述管理模块将会监控所述系统日志或接口日志以及配置信息存储任务的完成成功与否，如果完成成功，所述压测日志分析模块将会读取所述系统日志或接口日志以及配置信息进行压测统计分析，如果所述系统日志或接口日志以及配置信息存储任务是通过实时的方式，则会实时统计分析结果，并将其实时统计的分析结果展示至所述前端展示模块；

所述分布式资源管理模块用于负责分布式压测集群资源分配及管理以协调各个项目侧之间的压测任务。

较佳地，所述分布式压测集群资源包括CPU总核数、内存总量以及磁盘总量。

较佳地，所述计算引擎模块包括控制中心模块、资源管理模块以及任务管理模块；

所述控制中心模块为Metal Control Center，所述资源管理模块为MetalResourceManager即MetalStrom的资源管理器，所述任务管理模块为MetalTaskManager即MetalStorm的任务管理器，资源管理器的实现，可以依技术情况来实现，也可以直接使用Yarn来管理；

所述Metal Control Center用于接收并收集MetalResourceMan ager的心跳及日志信息(比如剩于core,memory的情况)、用于接收并收集MetalTaskManager的心跳及日志信息(比如当前正在处理的任务进度及状态)、用于处理客户端任务请求分配，读取主程序并将主程序提交至MetalTaskManager，再由MetalStorm执行主程序进行压测；

需要注意的是：控制中心接收到任务后，其生杀大权，将不再由控制中心处理，而是交给MetalTaskManager处理；

所述MetalResourceManager用于负责给提交的任务的资源进行分配和回收、用于与控制中心通信，将资源分配情况发送给控制中心；

所述MetalTaskManager用于负责任务的管理，包括执行和kill、用于与控制中心通信，将任务的执行情况发送给控制中心(如：进度，状态)。

较佳地，所述的针对图数据库及图服务接口进行分布式压测系统，还包括客户端、计算引擎端以及被压测端；

所述客户端用于负责客户端展示、提交任务展示、报表展示以及可视配置；

所述计算引擎端用于负责客户端提交任务，并审核该任务的可行性以及执行该任务；

所述被压测端包括服务端接口和数据库。

需要说明的是，上述各个模块之间在软件实施上都是强解耦合的，均可以独立进行，对于分布式资源管理模块主要是负责资源分配及管理，分布式压测集群有有CPU总核数，内存总量，磁盘总量，合理的分配资源将有利于协调各个项目侧之间的压测任务，如在接入数据源时，会评估CPU，内存以及磁盘的消耗，如果该任务被评估出来的所占资源超出来了，集群的剩余资源(剩余的CPU核心数，内存，磁盘)，则资源管理模块会通过管理模块需要等待其它任务完成并释放资源后，才能进行该新的压测任务。此时，该新的压测任务，会被标记为待执行状态。

客户端提交参数后，包括需要准备的数据源方式，点击页面端按钮提交，此时任务还并未分发到分布式服务侧，而是先将该任务的情况存储至了mysql中，再将任务提交至计算引擎，的MetalMaster管理模块，MetalMaster会校验前端提交过来的参数，如果校验不通过，会直接返回至客户端，并说明校验不通过的原因，此时如果校验通过，则会向资源管理器申请资源，当资源申请成功后，MetalMaster会通知MetalTaskManager要创建MetalTask实例了，该实例就是计算引擎的执行器，创建好后，将读取数据源(如果数据源是可执行jar，则直接执行可执行jar)，读取数据源后，通过分析后创建压测请求数据，直到数据完全被消耗完。

同时在消费数据时，系统会记录压测日志，任务管理监控到数据消费任务完成后，将会启动压测分析服务，压测分析服务分为实时(实时不需要经常任务管理的控制)，离线(需要任务管理通知分析服务模块执行分析程序)，以及OLAP查询服务(该服务也不需要通过任务管理的控制)，而是通过前端界面，进行OLAP查询。以展示对比不同的压测结果。压测分析日志将会永久归档，以便针对同一图数据库或图服务的历史性版本之间的对比。

各个模块的说明如下：

<1>用户登录后台后，在提交任务前需要做如下配置

●任务名称

●线程数

●Ramp-Up Period

●循环次数

●调度器相关参数配置

包括启动时间，结束时间

●http请求相关参数

因为压测数据来源于预先准备的文件，当被压测源为图相关服务时，会调用金融银行数据模型，所以请求参数应该是动态从预准备的数据中自动填充的。仅用于服务端接口压测场景。

●压测数据源

分为两种

第一种，如果http请求链接设置有误，那么当压测数据源选择也有问题时，那么压测任务是会失败的，所以最好的办法是将Http请求的链接与数据源做一个自动配置的映射关系，那么在客户端只需要设置数据源即可；

第二种，因为系统侧会做接口适配，所以在客户端可以提交可执行jar，服务端接收到jar后会分发到分布式压测的各个服务器，然后并发执行，该执行jar就是提供自定义的数据源。

●被压测服务类型及源

被压测服务类型分为图数据库(其它指定数据库)、图服务接口(其它指定服务接口)。

●展开度数

仅用于图数据库及图服务类型时。

<2>MetalMaster，即控制中心，任务由后台创建好后，会提交给控制中心，控制中心校验参数，以及可执行jar的规则校验，参数校验成功后，会向资源管理器即MetalResourceManager申请资源，申请的资源主要包括CPU-core，内存，此外，如果当下压测任务比较多，并且，网络IO比较大，那么在多个压测任务要并行执行的话，仍然要参考网络IO，否则压测达不到实现想要的效果。集群的CPU-CORE，内存，网络IO,磁盘IO的情况，都会由MetalResourceManager统一收集，由各压测节点统一向MetalResourceManager汇报，MetalResourceManager搜集情报后，再实时展示。

<3>资源调配，主要是资源调配的算法，需要整理CPU-CORE,内存，网络IO，磁盘IO之间的互相影响因素再做定制。

<4>Date Set，是指压测的准备数据来源，前期可以用简单的方式，也就是通过生产或测试的模拟的大批量数据，再上传到服务器指定的位置。需要注意的是，该指定的位置必须要被各个压测节点拉取到。

<5>MetalTaskInstance是由MetalTaskManager创建的实例，当任务最终符合要求后，MetalTaskManager会根据提交的参数，以及MetalResourceManager分配的资源创建Task执行实例。

<6>Task执行实例，会根据压测源数据集，创建压测请求。

<7>被压测的目标，主要分两大类，一类是web api，也就是web端业务开发的接口，这个接口是选择压测数据源时，自动指定的，另一类是database api，在某些场景下我经常需要对目标服务器的数据库进行压测选型，而此类压测，需要在客户端提交可执行程序，执行程序最终由MetalTaskInstance实例执行。

<8>每次请求，需要将服务接口返回的结果情况记录下来，目前整理需要被记录的参数有

●请求计次(总次)

●每次请求状态成功，失败，异常，超时计次

●每次请求耗时

●每次请求时间timestamp

●当前所在节点hostname

●被请求的接口uri路径/被请求的数据库

本发明还提出一种针对图数据库及图服务接口进行分布式压测方法，包括如下步骤：

步骤一、操作客户端，操作客户端包括三种操作方式，分别如下：

第一种、配置普通的http请求参数，此时又有两种选择，当不选择指定数据源时，此时提交的压测任务请求方式将会单一化，也就是每次请求的数据的内容都是一至的，这种情况一般用于测试服务端接口的连通，可行性，以及QPS的支撑量；

当选择了指定数据源，此时提交的压测任务请求将会读取该数据源，在后续的压测请求中将会以该数据源为样例，只要准备的数据源中数据不一致，那么每次请求的数据将也会不一致，这种场景一般用于测试服务端接口的稳定性，可行性，以及QPS的支撑或链路业务需求，但相对于单一化的提交请求，唯一需要多做的是需要事先准备好数据源，此外这种方式也可以用于数据库压测；

第二种、配置可执行jar，可执行jar是一种高度自由的方式，可以通过可执行jar根据业务的实际场景源源不断的造出不同的数据。可以理解为该可执行jar就是一个可高度自由的造数工厂程序。在本发明中，规划将定义该可执行jar规范。因为恶意的可执行jar将会使系统崩溃，得不偿失。提交了可执行jar后，后续的数据流程中将会有模块执行该jar。

第三种、客户端提交还涉及一个核心功能压力测试就是图数据库及图服务接口，该选项将在前端的单选框中选择，选项有【图数据库】【图服务接口】。当选择了图数据库选项时，此时可执行jar是必须要上传的，因为图数据库的种类仍然比较繁多，不同的图数据库之间的系统模型相差比较大，仍然需要通编程来做定制化服务，但因为编程接口高度抽象化，编程难度并没有想象高。本发明中已默认提供了如arangodb,janusgraph,neo4j,azure,Neptune,dgraph，tigergraph,nebula等图数据库压测接口。此时系统会自动配置金融银行的数据源模型作为后续执行器的数据来源；

其次就是分布式计算引擎模块，分布式计算模块和常规的分布式系统雷同，不过本发明规划将使用java语言，结合RPC加上zookeeper分布式协调器来实现该分布式压测系统，因为各个分布式模块都要高度定制，核心任务并不是为了计算，而只是为了做数据请求，所以主要应针对并发，多线程上做考量。

而分布式资源调度，是为了要满足各个项目组之间的任务需求，在日常工作中，经常会为集群的资源情况争执不下，所以资源调度的实现其核心目的不仅仅只是简单的压测任务资源的分配，背后更多的是团队之间的需求的不同，以及项目成本，人工成本，服务资源成本之间的决择。

步骤二、创建分布式实例

因为分布式的特点，在软件架构的实际使用过程中是感知不到它的存在的，所以流程示意图中并没有显示声明分布式的特点，暂且可以认为相同形状的子图重叠的部分为分布式处理。(但不包括资源管理器，因为资源管理器本身是运行在分布式系统中)

如图2-⑤,有一个读取数据源的过程，这个过程的实现，可以依据具体的实际情况来实现，而不是因为想分布式而分布式，分布式的实现更多的是为项目提供了自由的选择，也就是它也可以支持单机，而如果是单机，则可以将数据源放到本地，如果是分布式集群，则可以将数据存存储在hdfs分布式文件系统中，在本明中，规划仍需要实现自己的分布式文件系统，但并不需要像hdfs分布式文件系统一样需要实现数据的一致性，而应该要明确最终的实现目标，是为了压测，而不是为了计算，所以只需要将文件以hash分块的方式，通过scp，或ftp服务输出至集群中的其它机器，而每台机器上的数据都是不一致的，但格式一致，用hash分块的目的是使集群中的每台服务器的源始数据的大小大致是一致的。如果不一致，将会导致在观察压测最后请求的几秒钟或几分种里会出现比较大的断层。这是实际场景中大家所不希望看到的，数据分配得越均匀，对压测结果的准备性将越好。

如图2-⑥，获取到数据源后，将会创建数据请求，结果图2-⑦，请求目的有数据库请求和服务端接口请求，而数据库请求将只能通过提交可执行jar的方式，因为数据库压测场景比服务端接口的压测场景会复杂很多，只有通过自定义的方式，才能满足需求。而针对数据库压测将有几种场景，即单条插入，批量的插入，单条查询，批量查询，单条更新，批量更新，单条删除，批量删除，以及复杂类SQL查询场景，以及还有针对数据库连接数的压测。

如图2-⑧，在请求过程中，需要将被压测端的性能参数，性能参数将来自两个部分，一个部分，请求的返回结果记录，另一部分，将来自被压测端服务器的参数(如对数据库进行压测时，需要记录CPU，内存，磁盘，IO等情况)，因为分布式压测集群与目标机器所在集群和机器不在同一台服务器，但处理同一个局域网内。所以本发明将通过在目标被压测的服务器上部署日志采集器，然后写入到消息列队或分布式文件系统中(可根据实际场景按需部署)。

综上所述，本发明，将多种压测方式集成一体，以满足小中大企业的大中小各种项目及数据库的压测需求，并且同时支持离线报表，在线报表，实时报表，历史报表的展示及查看，以及对比功能；

本发明,支持预先数据源，通过分布式读取数据源的方式进行请求压测；支持在客户端提交可执行jar进行实时造数压测；

本发明,除了支持图数据还支持其它主流数据库的压测，当设置参数目标为图数据库时，就会自动启动金融银行数据模型；

本发明,支持历史报表存储，以及报表之间的对比，并且在进行数据性能压测时会读取每次压测时的数据库配置，便于在报表对比时，可以提供参数优化。

本发明中未涉及部分均与现有技术相同或可采用现有技术加以实现。本具体实施例仅仅是对本发明的解释，其并不是对本发明的限制，本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改，但只要在本发明的权利要求范围内都受到专利法的保护。

Claims (5)

1.一种针对图数据库及图服务接口进行分布式压测系统，其特征在于：包括接入层模块、计算引擎模块、存储层模块、压测日志分析模块、前端展示模块、管理模块以及分布式资源管理模块；

所述接入层模块用于为所述计算引擎模块提供发送数据源；所述计算引擎模块在接收到所述计接入层模块发送的数据源后，通过分布式的方式对接收到的数据进行处理，并在处理过程中采集系统日志或接口日志以及配置信息，并将采集的系统日志或接口日志以及配置信息写入所述存储层模块；

在所述系统日志或接口日志以及配置信息存储完毕后，所述管理模块将会监控所述系统日志或接口日志以及配置信息存储任务的完成成功与否，如果完成成功，所述压测日志分析模块将会读取所述系统日志或接口日志以及配置信息进行压测统计分析，如果所述系统日志或接口日志以及配置信息存储任务是通过实时的方式，则会实时统计分析结果，并将其实时统计的分析结果展示至所述前端展示模块；

所述分布式资源管理模块用于负责分布式压测集群资源分配及管理以协调各个项目侧之间的压测任务。

2.根据权利要求1所述的一种针对图数据库及图服务接口进行分布式压测系统，其特征在于：所述分布式压测集群资源包括CPU总核数、内存总量以及磁盘总量。

3.根据权利要求1所述的一种针对图数据库及图服务接口进行分布式压测系统，其特征在于：所述计算引擎模块包括控制中心模块、资源管理模块以及任务管理模块；

所述控制中心模块为Metal Control Center，所述资源管理模块为MetalResourceManager即MetalStrom的资源管理器，所述任务管理模块为MetalTaskManager即MetalStorm的任务管理器；

所述Metal Control Center用于接收并收集MetalResourceMan ager的心跳及日志信息、用于接收并收集MetalTaskManager的心跳及日志信息、用于处理客户端任务请求分配，读取主程序并将主程序提交至MetalTaskManager，再由MetalStorm执行主程序进行压测；

所述MetalResourceManager用于负责给提交的任务的资源进行分配和回收、用于与控制中心通信，将资源分配情况发送给控制中心；

所述MetalTaskManager用于负责任务的管理，包括执行和kill、用于与控制中心通信，将任务的执行情况发送给控制中心。

4.根据权利要求1所述的一种针对图数据库及图服务接口进行分布式压测系统，其特征在于：还包括客户端、计算引擎端以及被压测端；

所述客户端用于负责客户端展示、提交任务展示、报表展示以及可视配置；

所述计算引擎端用于负责客户端提交任务，并审核该任务的可行性以及执行该任务；

所述被压测端包括服务端接口和数据库。

5.一种针对图数据库及图服务接口进行分布式压测方法，其特征在于：包括如下步骤：

步骤一、操作客户端，操作客户端包括三种操作方式，分别如下：

第一种、配置普通的http请求参数，此时又有两种选择，当不选择指定数据源时，此时提交的压测任务请求方式将会单一化，也就是每次请求的数据的内容都是一至的，这种情况用于测试服务端接口的连通，可行性，以及QPS的支撑量；

当选择了指定数据源，此时提交的压测任务请求将会读取该数据源，在后续的压测请求中将会以该数据源为样例，只要准备的数据源中数据不一致，那么每次请求的数据将也会不一致，这种场景用于测试服务端接口的稳定性，可行性，以及QPS的支撑或链路业务需求，但相对于单一化的提交请求，唯一需要多做的是需要事先准备好数据源，此外这种方式也用于数据库压测；

第二种、配置可执行jar，可通过可执行jar根据业务的实际场景源源不断的造出不同的数据，提交了可执行jar后，后续的数据流程中将会有模块执行该jar。

第三种、客户端提交还涉及一个核心功能压力测试就是图数据库及图服务接口，该选项将在前端的单选框中选择，选项有【图数据库】【图服务接口】，当选择了图数据库选项时，必须上传可执行jar，此时系统会自动配置金融银行的数据源模型作为后续执行器的数据来源；

步骤二、创建分布式实例

读取数据源，如果是单机，则将数据源放到本地，如果是分布式集群，则将数据存储在hdfs分布式文件系统中，需要将文件以hash分块的方式，通过scp或ftp服务输出至集群中的其它机器；

获取数据源，获取到数据源后将会创建数据请求；

请求过程，在被压测端的服务器上部署日志采集器用于采集被压测端的性能参数，然后写入到消息列队或分布式文件系统中；

获取结果，通过查看压测报告即可。

Images