具体实施方式
为了使本领域的人员更好地理解本申请实施例中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅是本申请实施例一部分实施例,而不是全部的实施例。基于本申请实施例中的实施例,本领域普通技术人员所获得的所有其他实施例,都应当属于本申请实施例保护的范围。
为便于理解本申请实施例的方案,以下首先结合图1对容器化集群进行简要说明。
图1示出了一种容器化集群的示例,图1中,该系统100可以包括多台节点设备102、和通信网络104。每台节点设备102上均可运行多个容器,在多台节点设备102中,存在一台可运行主管理程序Master的主机节点,以及可接收主机节点管理和任务分配的一台或多台工作节点,如可运行kubelet的Worker节点。需要说明的是,该系统100中的多个节点示意为物理节点,但本领域技术人员应当明了的是,该多个节点也可以是虚拟机节点。
以kubernetes容器化集群为示例,假设图1中在左侧节点设备102中运行Master程序,即主机节点,用于控制kubernetes容器化集群中的节点设备、创建作业任务等。
下侧虚线框中节点设备的每个设备中运行有至少一个POD,为工作节点,这些工作节点在主机节点的控制下执行被分配的任务。其中,POD由一个或多个(两个及两个以上)容器构成,作为一个整体被部署至一个工作节点上,同一个POD中的容器共享IP地址、进程间通讯(IPC)、主机名及其它资源。
此外,主机节点中配置有Replication controller(复制控制器),用于控制一个POD在集群上运行的实例数量。主机节点中配置的api server提供kubernetes集群的API调用,scheduler作为调度容器,负责将请求或任务分配到工作节点中。
而在各个工作节点上,配置有kubelet,负责按照配置文件中定义的容器规格启动容器,获取容器列表,保证被声明的容器已经启动并且正常运行。
右侧虚线框中的节点设备用于作为etcd存储数据,图中标示为存储节点。
例如,用户通过kubernetes的命令工具kubectl向主机节点提交了需要运行的POD的请求,主机节点会通过api server将请求存储至etcd中,等待scheduler扫描并在扫描到后为其分配工作节点。工作节点中的kubelet通过主机节点中的api server找到需要自已运行的POD,进而在本机上运行。
在基于上述架构进行集群测试的传统方式中,需要图1中所示的主机节点和各个工作节点合作执行测试,随着工作节点数量的增多,与之相关的缺陷数也会呈指数级增加。对于节点数量多达1000以上的大型集群来说,集群测试需要投入大量的物力和人力。而本申请实施例提供的集群测试方案,在单台设备如图1中左侧的节点设备102中部署模拟工作节点,通过该一台节点设备即可实现部分集群功能的测试,相较于传统方式极大地节省了人力和物力。
而对于图1中所示的通信网络104,其可以是一个或多个有线和/或无线网络的任何适当的组合。例如,通信网络104能够包括以下各项中的任何一种或多种:互联网、内联网、广域网(WAN)、局域网(LAN)、无线网络、数字订户线路(DSL)网络、帧中继网络、异步转移模式(ATM)网络、虚拟专用网(VPN)和/或任何其它合适的通信网络。节点设备102之间能够通过通信网络104进行互连和通信。
以下,结合附图和多个实施例,对图1中所示的容器化集群进行集群测试的方案进行说明。
实施例一
参照图2,示出了根据本申请实施例一的一种分布式集群测试方法的步骤流程图。
本实施例的分布式集群测试方法包括以下步骤:
步骤S202:在容器化集群的主机节点中接收到对容器化集群进行集群测试的触发操作。
本申请实施例中,主机节点意指运行主管理程序如Master程序的节点,也即主节点。当需要对容器化集群进行测试时,通常会通过适当的触发操作向主机节点发送测试指令或测试请求。其中,触发操作可包括但不限于通过触发按钮、触发选项、触发语音、触发手势,或者通过容器化集群管理系统如kubernetes输入指令,如通过kubernetes的命令工具kubectl输入指令,等等形式,本申请实施例对触发操作的具体形式不作限制。
对容器化集群进行的集群测试可由本领域技术人员根据测试需求设定具体测试项目,包括但不限于用于测试集群可承载工作节点数量的集群容量测试,用于测试集群连接情况的集群网络测试,用于测试任务执行能力的集群性能测试,也可以是兼顾上述各方面的综合测试,等等。因为测试重点的不同,用于完成测试任务的测试程序的使用情况也不同,可基于此,在进行不同的集群测试时,重点关注与当前测试关联度较高的那些测试程序。
步骤S204:在主机节点中根据触发操作触发生成集群测试任务。
一般来说,集群测试任务中会包括多个测试程序,通过表现为测试函数,每个测试程序完成不同的测试功能,或者为其它测试程序提供数据支持或运行支持。例如,为其它测试程序提供必要的辅助数据,或者为其它测试程序提供必要的运行参数和环境等。
本申请实施例中,集群测试任务中的每个测试程序都具有时间复杂度标记,用于标示当前测试程序的执行时间复杂度。对于某些集群测试来说,高时间复杂度的测试程序可能并不会对测试产生有益帮助,反而会带来高的资源和性能消耗,因此,通过标示出测试程序的时间复杂度,可在集群测试中,对高时间复杂度的测试程序进行针对性处理。
步骤S206:在主机节点中生成模拟工作节点,基于模拟工作节点和满足预设时间复杂度标准的测试程序,执行集群测试任务。
本申请实施例中,将每个工作节点视为主机节点中的一个进程,通过主机节点创建相应的工作节点进程,来模拟工作节点,无需实际建立工作节点。尤其是在容器化集群的集群容量测试时,通过模拟生成的模拟工作节点,即可有效确定主机节点可能承受的工作节点的数量,达到与真实集群的集群容量测试同样的效果。
并且,如前所述,在测试时,针对高时间复杂度的测试程序进行处理,使得测试时可执行满足预设时间复杂度标准的测试程序,即低时间复杂度的测试程序(如线性时间复杂度或常数复杂度的测试程序),从而有效降低CPU资源消耗,提高测试效率。
其中,代替高时间复杂度的测试程序预先设置在测试程序中,当执行至高时间复杂度的测试程序时,将会跳过该测试程序转而执行代替它的低时间复杂度的测试程序。由此,在既达到测试目的(如得到集群可承载容量)的同时,还可通过其它测试程序测试出集群存在的其它问题,甚至是其它严重问题,实现了更有效的集群测试。
通过本实施例,将提供的集群测试方案应用于容器化集群测试中,与传统测试不同的是,其不再需要真实的节点、设备和集群环境,通过集群中某台可运行主管理程序的设备即可实现基于单台设备的对整个容器化集群的测试。在本申请实施例的测试方案中,当集群中的某台可运行主管理程序的节点即主机节点接收到进行集群测试的触发操作时,会获取预先标记有执行时间复杂度标记的测试程序生成的集群测试任务,并且,在主机节点本地生成模拟工作节点,以基于这些设置进行集群测试方案。一方面,在某些测试中,如集群容量测试中,无需真实的工作节点运行测试程序,因此,通过模拟工作节点即可协助主机节点完成集群测试,可提高测试效率,又因无需部署真实的工作节点设备的集群环境,可达到节省人力和物力的效果。另一方面,在执行集群测试任务时,也仅满足预设执行时间复杂度标准的测试程序可被执行,这些测试程序通常为时间复杂度较低的测试程序,基于这些测试程序进行集群测试,即可满足诸如集群容量测试等测试方面的需求,又可避免系统资源消耗过大,还更容易发现与节点数量关联不高的其它的集群缺陷,进一步提升了集群测试的效率。
实施例二
参照图3A,示出了根据本申请实施例二的一种分布式集群测试方法的步骤流程图。
本实施例中,以对容器化集群进行集群容量测试为示例,对本申请的分布式集群测试方法进行说明,但本领域技术人员应当明了的是,其它依赖于节点数量进行的集群测试也均可适用本申请实施例的方案。
本实施例的分布式集群测试方法包括以下步骤:
步骤S302:预先对容器化集群的集群测试任务进行预测试执行,以根据执行结果对集群测试任务中的多个测试程序进行时间复杂度标记。
如前所述,集群测试任务通过多个测试程序(测试函数)实现,本实施例中,以进行集群容量测试为例,一个测试程序可因为工作节点的触发而循环执行,但不管循环执行几次,其均是由一个工作节点进行操作,对于这样的测试程序,其循环执行对集群容量测试并无助益,反而会对资源和算力造成不良影响。基于此,可先对集群测试任务进行预测试执行,进而根据执行结果标记出每个测试程序的执行时间复杂度,从中确定中高时间复杂度的测试程序,如时间复杂度为O(N3)及以上复杂度的测试程序。
在一种可行方式中,可以在包括主机节点和多个真实工作节点的预设规模的容器化集群中,执行集群测试任务;根据任务执行结果,对集群没试任务中的多个测试程序进行时间复杂度标记。其中,预设规模的容器化集群通常可以为具有较小数量的节点设备的容器化集群,如可以为几十个,或一百个等,其数量规模远小于大型分布式集群中的设备的数量规模,以节省成本开销。需要说明的是,该预设规模的容器化集群中的节点设备均为真实的节点设备,以保证执行结果的准确性,并使得基于该准确性较高的执行结果确定出的各个测试程序的执行时间复杂度也具有较高的准确性。
在实际实现时,可以先从单个真实工作节点开始,逐个增加真实工作节点的数量直至达到多个真实工作节点的总数量,并在每增加一个真实工作节点时,通过主机节点和增加的真实工作节点执行集群测试任务,直至所有真实工作节点执行完成。这样,可以根据每增加一个真实工作节点时,多个测试程序的时间复杂度变化情况,对多个测试程序进行时间复杂度标记。也即,每个真实工作节点都要执行一遍集群测试任务,随着真实工作节点数量的增加,集群测试任务的执行次数及时间均会发生变化,通过增加工作节点前的测试任务的执行次数和执行时间,与,增加工作节点后的测试任务的执行次数和执行时间,可确定测试任务的执行时间复杂度,例如,为O(1)、O(N)、O(N2)、O(N3)或更多等等。通过一定规模的真实节点执行集群测试任务,可保证测试结果以及测试程序的时间复杂度标记的准确性和有效性。
仍以kubernetes集群为例,可以首先对集群主机节点的master组件中的每个函数都进行埋点处理,通过埋点处理,可以在后续计算出其中每个函数被执行的次数。接着,搭建一个单worker节点(工作节点)的真实集群,执行集群容量测试任务,通过埋点获取到master组件中每个函数的执行次数。然后,逐渐增大真实集群中worker节点的数量(例如,从1到10),每增加一个worker节点执行一次集群容量测试任务,获取到不同worker节点数量对应的master组件中每个函数的执行次数。进而,可将每个函数的时间复杂度标记出来,尤其是将O(N3)或更高时间复杂度的函数标记出来。这些被标记的高时间复杂度函数包括但不限于CPU密集型函数、高内存占用函数、高IO函数等,其中的大部分具有节点依赖性,可称为节点依赖性函数,均为高时间复杂度函数,当工作节点数量增大时,其执行时间会成指数级增长。可选地,可对这些高时间复杂度函数进行特别标记,以便有效区分和处理。或者,仅将这些高时间复杂度函数标记出来,以备后续处理。
一种具有时间复杂度标记的测试程序示例如下所示:
可见,上文中通过注释方式标记出相关函数的时间复杂度。但不限于此,其它标记方式,如通过不同字母、或符号、或数字等方式进行标记也同样适用于本申请实施例。
此外,对于节点依赖性函数来说,其中的某些函数具有输入和/或输出,而另一些函数则不具有。针对此种情况,在一种可行方式中,可以在每增加一个真实工作节点时,记录多个测试程序的时间复杂度变化情况,对多个测试程序进行时间复杂度标记,并且,记录多个测试程序中具有输入参数和/或输出参数的测试程序对应的输入数据和/或输出数据,以及执行时间。一种方式中,对于没有输入和/或输出的那些函数来说,在记录时相对应的信息项为空即可。在另一种方式中,也可以先判断待执行的测试程序是否具有输入参数和/或输出参数,在具有的情况下再针对该测试程序进行记录。通过这种记录的方式,在后续测试中针对这种函数进行回放,即可提高测试效率,减少资源消耗,还可防止其它函数因输入和/或输出与该函数存在关联而导致测试错误。
仍以kubernetes集群为例,可以在节点依赖性函数的执行前后加入数据保存功能。在部署master节点的单机中启动worker节点的agent,如kubelet。将每个worker节点的agent作为一个进程在部署master节点的单机中执行。(如果需要模拟的worker节点数较多,可以改进kubelet,在测试中只启动一个kubelet,通过不同的label来区分不同的worker节点)。在启动集群测试任务后,将节点依赖性函数的输入、输出、执行时间记录下来并保存到数据库中,以便在后续进行正常测试时进行回放。
一种记录方式如下所示:
in=parameter
time1=getCurrentTime()
result=MasterInitDemo(parameter)//O(N3)
time2=getCurrentTime()
out=result
recordDB(in,out,time2-time1)
其中,in表示函数的输入数据、out表示函数的输出数据、time1表示函数开始执行时的时间,time2表示函数执行结束的时间,result表示函数执行结果,recordDB表示将相应数据存入数据库中,其中的time2-time1表示函数的执行时间。
在确定了高时间复杂度的节点依赖性函数后,可对其进行改写,以使后续使用其进行集群测试时,可跳过其而执行其对应的低时间复杂度(如常数复杂度)的函数。例如,可通过诸如if…else…语句,将原函数内容放入if部分并设定路过条件,而将低时间复杂度函数放入else部分,代替原函数内容执行。可选地,低时间复杂度函数可以为sleep函数,以简化实现。一种时间复杂度标记及函数改写的示例如下所示:
由上可见,通过设置!singleNodeCheck条件,使得在后续测试时,可以跳过高时间复杂度的函数而去执行else后面的常数复杂度函数。
此外,在一种可行方式中,对于节点依赖性函数的输出,可以通过sleep函数来模拟函数的执行,通过回放来模拟函数的输出,从而降低系统负载,来触发多节点缺陷。一个示例如下:
if singleNodeCheck{//数据库中存储有记录的函数的输入in、输出out和执行时间time,通过输入相应的参数,从数据库中获得对应的输出out和执行时间time
通过上述过程,即可实现测试程序的时间复杂度的有效标记,以为后续正常测试提供依据。需要说明的是,一次标记可在后续长期使用,无需每次进行集群测试时均进行标记。
在标记完成后,即可进行下述本申请实施例的集群测试方案。需要说明的是,本实施例中以先执行上述测试程序的时间复杂度标记后接着执行集群测试为示例,但本领域技术人员应当明了的是,在实际应用中,两者并没有接续关系,正常的集群测试可以在时间复杂度标记后的任意时间执行。
步骤S304:在容器化集群的主机节点中接收到对容器化集群进行集群测试的触发操作。
如前所述,所述触发操作可以为任意适当形式的触发操作,对容器化集群的集群测试的主要目的可由本领域技术人员根据实际需求设定,本申请实施例尤其适用于与节点数量有关的测试,如集群容量测试等。
步骤S306:根据触发操作触发生成集群测试任务。
其中,集群测试任务中包括多个测试程序,测试程序具有时间复杂度标记。测试程序的时间复杂度标记可通过步骤S302中所描述的方式标记获得。
步骤S308:在主机节点中生成模拟工作节点,基于模拟工作节点和满足预设时间复杂度标准的测试程序,执行集群测试任务。
其中,所述预设时间复杂度标准通常为低时间复杂度标准,如线性复杂度标准或常数时间复杂度标准。本申请实施例中,选用常数时间复杂度标准O(1),既对于高时间复杂度的测试程序,如O(N3)及以上时间复杂度的测试程序,在其执行时将其替换为常数时间复杂度的测试程序,如sleep函数实现的测试程序。基于此,在一台设备即主机节点中即可基于通过进程生成的模拟工作节点和常数复杂度的测试程序,执行集群测试任务,如集群容量测试任务等。
在一种可行方式中,本步骤可以通过以下方式实现:在主机节点中依次逐个启动工作节点进程,通过启动的工作节点进程模拟工作节点;基于主机节点和模拟工作节点执行集群测试任务,并在执行至具有第一时间复杂度标记的测试程序时,跳转至与该测试程序对应的具有第二时间复杂度标记的测试程序执行;其中,第一时间复杂度高于第二时间复杂度,第二时间复杂度为常数复杂度。本实施例中,依次逐个启动工作节点意指每次多增加启动一个工作节点,该工作节点的增加通过增加启动工作节点进程实现,也即,每增加启动一个工作节点进程就可实现增加一个模拟工作节点。并且,每增加一个模拟工作节点,执行一次集群测试任务,在执行过程中,如果碰到时间复杂度较高(即第一时间复杂度标记)的测试程序,如具有O(N3)标记的测试程序,因在对其标记时还为其设置了替换的低时间复杂度的测试程序(即第二时间复杂度标记的测试程序如O(1)时间复杂度的测试程序),因此,可跳转至该低时间复杂度的测试程序执行。
此外,对于被标记的具有第一时间复杂度的测试程序,若其还有输入和/或输出,在在执行至具有第一时间复杂度标记的测试程序时,可以先获取预先存储的测试程序的输入、输出和执行时间,并跳转至与该测试程序对应的具有第二时间复杂度标记的测试程序;通过具有第二时间复杂度标记的测试程序,基于所述输入、输出和执行时间,进行该测试程序的执行回放。此种方式中,通过进程来模拟工作节点,通过自动对高时间复杂度函数的判定以及自动的记录和回放的方式,实现了单机模拟多节点集群来进行集群测试,达到了集群测试的低成本实现的效果。
需要说明的是,在集群容量测试中,具有第一时间复杂度标记的测试程序多为节点依赖性测试程序,会随着节点数量的增加,执行复杂度呈指数级增长。但不限于此,该第一时间复杂度标记的测试程序也可为其它类型的测试程序,并不意味着只有节点依赖性测试程序才具有第一时间复杂度标记。
以下,以一个具体示例对上述集群容量测试的过程进行示例性说明,如图3B所示。
以Kubernetes为例,当Kubernetes集群的节点数量较高时,如高于100以上时,集群的缺陷将呈现指数级的增长。由于成本原因,对于个人开发者和中小企业很难承担验证大规模分布式集群的成本。为此,本申请实施例提供了一种通过单机来验证大规模多节点分布式集群的方案,以利用有限的资源环境尽可能地触发多节点的集群缺陷。
图3B中,首先在小规模的真实集群中进行预测试,以确定实现测试程序的函数的时间复杂度。例如,先对Kubernetes集群的主节点的master组件进行埋点处理,通过埋点,可以计算出每个函数被执行的次数。具体地,可以搭建一个单worker节点的真实集群,通过埋点获取到master组件中每个函数的执行次数。然后逐渐增大真实集群中worker节点的数量(例如,从1到10),获取到不同worker节点数量对应的master组件中每个函数的执行次数。
然后,标记时间复杂度高(如O(N3)及以上)的函数。本示例中,仅标记时间复杂度高的函数,但如前所述,也可对每个函数的时间复杂度均进行标记,从中确定时间复杂度高的函数。如图3B中右上角实线框中所示,可以将O(N3)或更高时间复杂度的函数标记出来。这些被标记的函数,通常具有节点依赖性,当节点数量增大时,其执行时间会呈指数级增长。
在标记时间复杂度高的函数的过程中,存储节点依赖性函数的输入、输出、和执行时间。例如,在节点依赖性函数的执行前后加入数据保存功能。将节点依赖性函数的输入、输出、和执行时间保存到数据库中。
至此,可以认为前期的测试程序(函数)的标记处理和记录工作完成,可进行后续的正常测试了。
基于此,可以在单机中模拟多工作节点,使用标记过的测试程序进行集群测试。如图3B中右下角实线框所示,将节点依赖性函数替换为复杂度为O(1)的sleep函数。即,当worker节点数增大时,程序会跳过节点依赖性函数,执行复杂度为O(1)的sleep函数,避免主机CPU负载过高。并且,程序会自动将记录在数据库中的函数输入对应的输出值和执行时间从数据库调取,进行回放,从而降低系统负载,来触发多节点缺陷。
可见,通过将本实施例的方案应用于容器化集群测试中,与传统测试不同的是,其不再需要真实的节点、设备和集群环境,通过集群中某台可运行主管理程序的设备即可实现基于单台设备的对整个容器化集群的测试。在本申请实施例的测试方案中,当集群中的某台可运行主管理程序的节点即主机节点接收到进行集群测试的触发操作时,会获取预先标记有执行时间复杂度标记的测试程序生成的集群测试任务,并且,在主机节点本地生成模拟工作节点,以基于这些设置进行集群测试方案。一方面,在某些测试中,如集群容量测试中,无需真实的工作节点运行测试程序,因此,通过模拟工作节点即可协助主机节点完成集群测试,可提高测试效率,又因无需部署真实的工作节点设备的集群环境,可达到节省人力和物力的效果。另一方面,在执行集群测试任务时,也仅满足预设执行时间复杂度标准的测试程序可被执行,这些测试程序通常为时间复杂度较低的测试程序,基于这些测试程序进行集群测试,即可满足诸如集群容量测试等测试方面的需求,又可避免系统资源消耗过大,还更容易发现与节点数量关联不高的其它的集群缺陷,进一步提升了集群测试的效率。
实施例三
参照图4,示出了根据本申请实施例三的一种分布式集群测试装置的结构框图。
本实施例的分布式集群测试装置设置于容器化集群的主机节点中,所述装置包括:触发模块402,用于在容器化集群的主机节点中接收到对容器化集群进行集群测试的触发操作;生成模块404,用于根据触发操作触发生成集群测试任务,其中,集群测试任务中包括多个测试程序,测试程序具有时间复杂度标记;测试模块406,用于在主机节点中生成模拟工作节点,基于模拟工作节点和满足预设时间复杂度标准的测试程序,执行集群测试任务。
可选地,测试模块406,用于在主机节点中依次逐个启动工作节点进程,通过启动的工作节点进程模拟工作节点;基于主机节点和模拟工作节点执行集群测试任务,并在执行至具有第一时间复杂度标记的测试程序时,跳转至与该测试程序对应的具有第二时间复杂度标记的测试程序执行;其中,第一时间复杂度高于第二时间复杂度,第二时间复杂度为常数复杂度。
可选地,测试模块406在执行至具有第一时间复杂度标记的测试程序时,跳转至与该测试程序对应的具有第二时间复杂度标记的测试程序执行时,可以包括:在执行至具有第一时间复杂度标记的测试程序时,获取预先存储的所述测试程序的输入、输出和执行时间,并跳转至与该测试程序对应的具有第二时间复杂度标记的测试程序;通过具有第二时间复杂度标记的测试程序,基于所述输入、输出和执行时间,进行测试程序的执行回放。
可选地,具有第一时间复杂度标记的测试程序包括:具有第一时间复杂度标记的节点依赖性测试程序。
可选地,本实施例的分布式集群测试装置还包括:预处理模块408,用于预先对集群测试任务进行预测试执行,以根据执行结果对集群测试任务中的多个测试程序进行时间复杂度标记。
可选地,预处理模块408,用于在包括主机节点和多个真实工作节点的预设规模的容器化集群中,执行集群测试任务;根据任务执行结果,对集群没试任务中的多个测试程序进行时间复杂度标记。
可选地,预处理模块408在包括主机节点和多个真实工作节点的预设规模的容器化集群中,执行集群测试任务可以包括:从单个真实工作节点开始,逐个增加真实工作节点的数量直至达到多个真实工作节点的总数量,并在每增加一个真实工作节点时,通过主机节点和增加的真实工作节点执行所述集群测试任务,直至所有真实工作节点执行完成;预处理模块408在根据任务执行结果,对集群没试任务中的多个测试程序进行时间复杂度标记可以包括:根据每增加一个真实工作节点时,多个测试程序的时间复杂度变化情况,对多个测试程序进行时间复杂度标记。
可选地,预处理模块408根据每增加一个真实工作节点时,多个测试程序的时间复杂度变化情况,对多个测试程序进行时间复杂度标记可以包括:在每增加一个真实工作节点时,记录多个测试程序的时间复杂度变化情况,对多个测试程序进行时间复杂度标记,并且,记录多个测试程序中具有输入参数和/或输出参数的测试程序对应的输入数据和/或输出数据,以及执行时间。
可选地,对容器化集群进行的集群测试为集群容量测试。
本实施例的分布式集群测试装置用于实现前述多个方法实施例中相应的分布式集群测试方法,并具有相应的方法实施例的有益效果,在此不再赘述。此外,本实施例的分布式集群测试装置中的各个模块的功能实现均可参照前述方法实施例中的相应部分的描述,在此亦不再赘述。
实施例五
参照图5,示出了根据本申请实施例五的一种电子设备的结构示意图,本申请具体实施例并不对电子设备的具体实现做限定。
如图5所示,该电子设备可以包括:处理器(processor)502、通信接口(Communications Interface)504、存储器(memory)506、以及通信总线508。
其中:
处理器502、通信接口504、以及存储器506通过通信总线508完成相互间的通信。
通信接口504,用于与其它电子设备或服务器进行通信。
处理器502,用于执行程序510,具体可以执行上述分布式集群测试方法实施例中的相关步骤。
具体地,程序510可以包括程序代码,该程序代码包括计算机操作指令。
处理器502可能是中央处理器CPU,或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit),或者是被配置成实施本申请实施例的一个或多个集成电路。智能设备包括的一个或多个处理器,可以是同一类型的处理器,如一个或多个CPU;也可以是不同类型的处理器,如一个或多个CPU以及一个或多个ASIC。
存储器506,用于存放程序510。存储器506可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。
程序510具体可以用于使得处理器502执行前述多个方法实施例中任意一个方法实施例的分布式集群测试方法。
程序510中各步骤的具体实现可以参见上述分布式集群测试方法实施例中的相应步骤和单元中对应的描述,在此不赘述。所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的设备和模块的具体工作过程,可以参考前述方法实施例中的对应过程描述,并具有相应的效果,在此不再赘述。
本申请实施例还提供了一种计算机程序产品,包括计算机指令,该计算机指令指示计算设备执行上述多个方法实施例中的任一分布式集群测试方法对应的操作。
需要指出,根据实施的需要,可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤,也可将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤,以实现本申请实施例的目的。
上述根据本申请实施例的方法可在硬件、固件中实现,或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码,或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码,从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解,计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如,RAM、ROM、闪存等),当所述软件或计算机代码被计算机、处理器或硬件访问且执行时,实现在此描述的分布式集群测试方法。此外,当通用计算机访问用于实现在此示出的分布式集群测试方法的代码时,代码的执行将通用计算机转换为用于执行在此示出的分布式集群测试方法的专用计算机。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及方法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请实施例的范围。
以上实施方式仅用于说明本申请实施例,而并非对本申请实施例的限制,有关技术领域的普通技术人员,在不脱离本申请实施例的精神和范围的情况下,还可以做出各种变化和变型,因此所有等同的技术方案也属于本申请实施例的范畴,本申请实施例的专利保护范围应由权利要求限定。