虚拟支付机的集群管理方法、系统、存储介质和电子设备

摘要

本发明提供虚拟支付机的集群管理方法、系统、存储介质和电子设备，其中集群管理方法包括：将订单支付请求分配至各虚拟支付机；接收各虚拟支付机的支付反馈信息；统计各虚拟支付机的支付成功率和负载率；向支付成功率大于成功率阈值、且负载率小于负载率阈值的各虚拟支付机加派订单，并向支付成功率小于成功率阈值、且负载率大于负载率阈值的各虚拟支付机发出第一类预警信息。本发明对虚拟支付机进行集群管理，方便实现多台虚拟支付机的成功率监控、负载率监控、余额监控、客户端升级、网络代理切换、异常自动恢复等一系列配套功能，保证了业务的准确性和高可用性。

说明书

技术领域

本发明涉及互联网技术领域，尤其涉及一种虚拟支付机的集群管理方法、系统、存储介质和电子设备。

背景技术

对于在线旅行社等电商系统，消费者线上付费预定服务后，在线旅行社要向第三方资源库付费购买产品，然后再将产品售至消费者。向第三方资源库付费购买产品时，通常使用虚拟支付机进行支付。

虚拟支付机是由软件程序运行在物理机上模拟出的一个支付客户端，通常一台物理机上可以运行多台虚拟支付机。

随着互联网的不断发展，需要支付的订单量不断增多，虚拟支付机的数量也大量增加。但由于目前对于虚拟支付机的管理方式仍较为单一，通常只能分次实现单个功能，使得虚拟支付机缺乏监管，日常维护效率低下，应对突发状况不力。

因此，有必要提供一种新的技术方案改善上述方案中存在的一个或者多个问题。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

针对现有技术中的缺陷，本发明的目的是提供一种虚拟支付机的集群管理方法、系统、存储介质和电子设备，实现支付机可视化监管。

根据本发明的一个方面，提供一种虚拟支付机的集群管理方法，用于管理至少一个虚拟支付机集群，所述虚拟支付机集群包含多台虚拟支付机，所述集群管理方法包括：

步骤S1、接收订单支付请求，将所述订单支付请求分配至各虚拟支付机；

步骤S2、接收各虚拟支付机的支付反馈信息，所述支付反馈信息包括支付成功信息和支付失败信息；

步骤S3、统计各虚拟支付机的支付成功率，所述支付成功率为该虚拟支付机的支付成功订单数占支付总订单数的比例，将各虚拟支付机的支付成功率与预设的成功率阈值进行比较；并且统计各虚拟支付机的负载率，所述负载率为该虚拟支付机单位时间内实际支付订单数与单位时间内最大可支付订单数的比例，将各虚拟支付机的负载率与预设的负载率阈值进行比较；

步骤S4、向支付成功率大于成功率阈值、且负载率小于负载率阈值的各虚拟支付机加派订单，加派订单的数量小于所述虚拟支付机的单位时间内实际支付订单数与单位时间内最大可支付订单数的差值；并且向支付成功率小于成功率阈值、且负载率大于负载率阈值的各虚拟支付机发出第一类预警信息。

优选地，上述的集群管理方法还包括：

步骤S5、对于支付成功率小于成功率阈值、且负载率小于负载率阈值的各虚拟支付机，监控该虚拟支付机的余额；

步骤S6、将各虚拟支付机的余额与预设的余额阈值进行比较，对支付成功率小于成功率阈值、且余额小于余额阈值的各虚拟支付机，发出第二类预警信息。

优选地，上述的集群管理方法还包括：

步骤S7、对于支付成功率小于成功率阈值、且余额大于余额阈值的各虚拟支付机，监控该虚拟支付机的心跳包发送频率，在预设周期时间段内连续发送心跳包则为运行正常，反之运行异常；

步骤S8、向运行正常的各虚拟支付机加派订单，加派订单的数量小于所述虚拟支付机的单位时间内实际支付订单数与单位时间内最大可支付订单数的差值，并返回步骤S2；

步骤S9、向运行异常的各虚拟支付机发送重启客户端指令。

优选地，上述的集群管理方法中，所述步骤S9包括：监控该虚拟支付机的运行异常持续时间，当运行异常持续时间达到临界阈值时，向该虚拟支付机发送重启客户端指令。

根据本发明的另一个方面，提供一种虚拟支付机的集群管理系统，用于管理至少一个虚拟支付机集群，所述虚拟支付机集群包含多台虚拟支付机，所述集群管理系统包括：

订单分配模块，用于接收订单支付请求，将所述订单支付请求分配至各虚拟支付机；

反馈接收模块，用于接收各虚拟支付机的支付反馈信息，所述支付反馈信息包括支付成功信息和支付失败信息；

成功率监控模块，用于统计各虚拟支付机的支付成功率，所述支付成功率为该虚拟支付机的支付成功订单数占支付总订单数的比例，将各虚拟支付机的支付成功率与预设的成功率阈值进行比较；

负载率监控模块，用于对支付成功率低于成功率阈值的虚拟支付机，统计该虚拟支付机的负载率，所述负载率为该虚拟支付机单位时间内实际支付订单数与单位时间内最大可支付订单数的比例，将各虚拟支付机的负载率与预设的负载率阈值进行比较；

第一预警模块，用于向支付成功率大于成功率阈值、且负载率小于负载率阈值的各虚拟支付机加派订单，加派订单的数量小于所述虚拟支付机的单位时间内实际支付订单数与单位时间内最大可支付订单数的差值；并且向支付成功率小于成功率阈值、且负载率大于负载率阈值的各虚拟支付机发出第一类预警信息。

优选地，上述的集群管理系统还包括：

余额监控模块，用于对于支付成功率小于成功率阈值、且负载率小于负载率阈值的各虚拟支付机，监控该虚拟支付机的余额；

第二预警模块，用于将各虚拟支付机的余额与预设的余额阈值进行比较，对支付成功率小于成功率阈值、且余额小于余额阈值的各虚拟支付机，发出第二类预警信息。

优选地，上述的集群管理系统还包括：

异常监控模块，用于对于支付成功率小于成功率阈值、且余额大于余额阈值的各虚拟支付机，监控该虚拟支付机的心跳包发送频率，在预设周期时间段内连续发送心跳包则为运行正常，反之运行异常；

重启模块，用于向运行正常的各虚拟支付机加派订单，加派订单的数量小于所述虚拟支付机的单位时间内实际支付订单数与单位时间内最大可支付订单数的差值；并且向运行异常的各虚拟支付机发送重启客户端指令。

优选地，上述的集群管理系统中，所述重启模块监控该虚拟支付机的运行异常持续时间，当运行异常持续时间达到临界阈值时，向该虚拟支付机发送重启客户端指令。

根据本发明的另一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述集群管理方法的步骤。

根据本发明的另一个方面，提供一种电子设备，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行上述集群管理方法的步骤。

有鉴于此，本发明提供的支付机可视化管理平台，实现支付成功率监控、负载率监控、余额监控、支付机异常自动恢复等一系列配套功能，从而保证了业务的准确性和高可用性。同时，对于支付成功率较高且负载率未达负载率阈值的虚拟支付机，加派合适量的订单，从而提高集群中虚拟支付机的利用率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出本发明示例性实施例中一种虚拟支付机的集群管理方法的流程示意图；

图2示出本发明示例性实施例中对虚拟支付机进行成功率监控的示意图；

图3示出本发明示例性实施例中对虚拟支付机进行负载率监控的示意图；

图4示出本发明示例性实施例中对虚拟支付机进行余额监控的示意图；

图5示出本发明示例性实施例中对异常运行的虚拟支付机发送重启指令的示意图；

图6示出本发明示例性实施例中对虚拟支付机进行集群管理的示意图；

图7示出本发明示例性实施例中一种虚拟支付机的集群管理系统的模块示意图；

图8示出本发明示例性实施例中一种计算机可读存储介质的示意图；

图9示出本发明示例性实施例中一种电子设备的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本发明的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1是本发明示例性实施例中一种虚拟支付机的集群管理方法的步骤示意图。本发明的集群管理方法用于管理至少一个虚拟支付机集群，该虚拟支付机集群包含多台虚拟支付机。结合图1所示，本发明的集群管理方法包括：

步骤S1、接收订单支付请求，将订单支付请求分配至各虚拟支付机。通常，多个订单支付请求可以均分至各个虚拟支付机。在虚拟支付机集群中，每台虚拟支付机在创建时会有与其唯一对应的支付机名称以及IP号。

步骤S2、接收各虚拟支付机的支付反馈信息，该支付反馈信息包括支付成功信息和支付失败信息。每台虚拟支付机完成订单支付后会拿到一个支付成功与否的信息(也即支付成功信息和支付失败信息)，并且通知远程服务器，服务器有个线程并行分析所有支付过的订单数据，并且依此来分析每台支付机是否支付成功。

步骤S3、统计各虚拟支付机的支付成功率，支付成功率为该虚拟支付机的支付成功订单数占支付总订单数的比例，将各虚拟支付机的支付成功率与预设的成功率阈值进行比较；并且，统计各虚拟支付机的负载率，负载率为该虚拟支付机单位时间内实际支付订单数与单位时间内最大可支付订单数的比例，将各虚拟支付机的负载率与预设的负载率阈值进行比较。

图2是对虚拟支付机进行成功率监控的示意图。虚拟支付机集群中包括多台虚拟支付机，图2以十台为例进行展示，各虚拟支付机的名称分别为ZF1～ZF10。服务器对每台虚拟支付机的支付成功率进行统计，统计得出虚拟支付机ZF1的成功率96.84％，虚拟支付机ZF3的成功率95.65％，虚拟支付机ZF8的成功率97.59％，虚拟支付机ZF10的成功率89.66％，其余虚拟支付机ZF2、ZF4～ZF7以及ZF9的支付成功率均为100％。然后，将各虚拟支付机的支付成功率与预设的成功率阈值进行比较，该成功率阈值例如设定为98％，那么可以得出结论：支付成功率低于该成功率阈值98％的虚拟支付机ZF1、ZF3、ZF8以及ZF10的支付成功率未达标，而其余虚拟支付机ZF2、ZF4～ZF7以及ZF9的支付成功率达标。

当然，若统计得出该虚拟支付机集群中超出半数的虚拟支付机的支付成功率低于成功率阈值，则发出报警信息。此步骤主要用于模式识别，如果大量虚拟支付机成功率告警，说明业务线出现问题，需要业务线介入，从另一方面保证了业务的稳定性。

进一步的，步骤S3还统计各虚拟支付机的负载率。图3是对虚拟支付机进行负载率监控的示意图。经过大量观察，发现虚拟支付机每支付一单耗时20秒，也就是说如果不间断工作并且不出现任何异常情况的理想状态下，虚拟支付机每5分钟可以支付15笔订单，因此把“每5分钟支付15笔订单”这个值作为一个评判标准，作为虚拟支付机单位时间内最大可支付订单数。参照图3所示，如果某一虚拟支付机在过去的5分钟内支付的总订单数量大于12单，就标记该虚拟支付机为高负载。也即，将每5分钟支付12笔订单设定为负载率阈值，大于该负载率阈值的情况则判定为高负载率。将负载率阈值设定为稍小于虚拟支付机单位时间内最大可支付订单数，以避免虚拟支付机超负荷工作造成系统瘫痪。而如果小于等于12单，则标记为低负载。统计各虚拟支付机的负载率，从图3可看出，除虚拟支付机ZF8的负载率为高外，其余虚拟支付机的负载率均为低。

当然，负载率监控的功能也适于在业务高峰期使用，用于实施监控虚拟支付机数量是否足以处理大量订单请求，如果有超出半数的虚拟支付机的负载率为高(表示一直处于繁忙状态)，则可发出告警，从而通知相关人员及时往集群中追加虚拟支付机，以满足业务的增长需求。

步骤S4、向支付成功率大于成功率阈值、且负载率小于负载率阈值的各虚拟支付机加派订单，加派订单的数量小于该虚拟支付机的单位时间内实际支付订单数与单位时间内最大可支付订单数的差值；并且向支付成功率小于成功率阈值、且负载率大于负载率阈值的各虚拟支付机发出第一类预警信息。也即，对于支付成功率大于成功率阈值98％、且负载率为低的各虚拟支付机ZF2、ZF4～ZF7以及ZF9加派订单，并且所加派的订单的数量加派订单的数量小于该虚拟支付机的单位时间内实际支付订单数与单位时间内最大可支付订单数的差值。这样，支付成功率高的各虚拟支付机可以承担系统内更多的支付任务，同时又保证这些虚拟支付机的负载不会过高，在提升系统业务处理效率的同时保障各虚拟支付机的稳定性。另外，对于支付成功率小于成功率阈值98％、且负载率为高的虚拟支付机ZF8发出第一类预警信息。系统接收到该第一类预警信息后，可适当减小分配至该虚拟支付机ZF8的订单量。

进一步的，本发明的集群管理方法还包括：步骤S5、对于支付成功率小于成功率阈值、且负载率小于负载率阈值的各虚拟支付机，监控该虚拟支付机的余额；步骤S6、将各虚拟支付机的余额与预设的余额阈值进行比较，对支付成功率小于成功率阈值、且余额小于余额阈值的各虚拟支付机，发出第二类预警信息。

图4是对虚拟支付机进行余额监控的示意图。参照图4所示，若虚拟支付机成功率未达标，而负载率并未超出负载率阈值(即负载率为低)，则可进一步监控该虚拟支付机的余额(事实上系统可以对所有的虚拟支付机并行监控余额)。余额监控的作用是防止虚拟支付机因为余额不足导致不能正常使用，在支付业务上，余额不足是一种不可恢复的操作，必须由人工介入，因此必须实时监控每台虚拟支付机当前的可用余额，这样可以及时通知财务充值。余额数据是虚拟支付机客户端采集过来的，每台虚拟支付机在支付完10笔订单之后会采集一次账户余额并发到服务器上(为了考虑支付时效不是每单都会采集，采集一次大约耗时1～3秒，网页有时候加载缓慢等)，服务器拿到数据之后再做可视化呈现并进行监控。从图4可看出，虚拟支付机ZF1余额低于余额阈值(本实施例中设定为50000)，而其余虚拟支付机的余额均高于余额阈值，因此向该虚拟支付机ZF1发出第二类预警信息，从而可以及时通知财务对该虚拟支付机ZF1充值。

进一步的，本发明的集群管理方法还包括：步骤S7、对于支付成功率小于成功率阈值、且余额大于余额阈值的各虚拟支付机，监控该虚拟支付机的心跳包发送频率，在预设周期时间段内连续发送心跳包则为运行正常，反之运行异常；步骤S8、向运行正常的各虚拟支付机加派订单，加派订单的数量小于所述虚拟支付机的单位时间内实际支付订单数与单位时间内最大可支付订单数的差值，并返回步骤S2；步骤S9、向运行异常的各虚拟支付机发送重启客户端指令。

图5是对异常运行的虚拟支付机发送重启指令的示意图。参照图5所示，目前系统中虚拟支付机的运行状态分为三种：正常运行状态、异常运行状态和停止状态。正常运行状态就是虚拟支付机客户端与服务器端能够正常通讯，虚拟支付机每隔15秒会发一次心跳包，如果服务器连续2分钟没有收到某台虚拟支付机的心跳包，那么这台虚拟支付机就会被诊断为异常运行状态。停止状态是虚拟支付机客户端反馈的状态，表示该虚拟支付机已经无法工作，必须人工介入处理(如账户余额不足、代理被封等)。对于上一步中检测到的支付成功率低于成功率阈值、而余额未低于余额阈值的各虚拟支付机，可以进一步监控该虚拟支付机的心跳包发送频率(事实上系统可以并行监控所有虚拟支付机的心跳包发送频率)。

例如，监测过程中，诊断出虚拟支付机ZF3以及虚拟支付ZF10处于异常运行状态，则继续监控该虚拟支付机ZF3以及虚拟支付ZF10的运行异常持续时间，当运行异常持续时间达到临界阈值例如10分钟，也即当虚拟支付机ZF3以及虚拟支付ZF10的异常运行状态超过10分钟还未恢复，则向该虚拟支付机ZF3以及虚拟支付ZF10各发送一条重启支付机客户端指令(图中Ewatch表示系统自动检测异常发送的重启客户端命令，让虚拟支付机自动恢复功能)交由虚拟支付机客户端执行。如果连续2次执行重启支付机客户端指令之后虚拟支付机还没有恢复正常，系统再推送一条重启操作系统指令，如此往复，直到虚拟支付机恢复正常。也即直到接收到该虚拟支付机发送的心跳包。

异常自动恢复是保证业务高可用性的解决方案，支付机客户端程序产生偶发故障后虚拟支付机就不能正常工作，如果是工作时间可能会有相关人员来介入重启，但是如果是非工作时间的话就得不到保证。因此系统提供了异常自动恢复办法，系统中运行着一个检测虚拟支付机运行状态的任务，当检测到虚拟支付机异常状态并且超过一定的时间阈值，系统会判定该虚拟支付机是否为可恢复异常类。如果属于可恢复异常，则往该虚拟支付机下发一条重启支付机客户端指令，如果连续下发3条重启指令后虚拟支付机依然没有正常恢复，则系统会再下发一条重启操作系统的指令，如此循环，最终确保虚拟支付机能够正常运行。

在此步骤中，如果检测到运行正常的虚拟支付机，而其支付成功率却低于成功率阈值，可以尝试向该虚拟支付机加派订单，并返回到步骤S2中继续监控该虚拟支付机的支付成功率，看是否是偶发性因素引起支付成功率降低。

图6展示出本发明示例性实施例中对虚拟支付机进行集群管理的整体示意图。参照图6所示，除上述的支付成功率和负载率监控、余额监控、支付机异常自动恢复等管理方法外，本发明的集群管理方法还包括：支付机一键升级，用于帮助开发人员提升部署效率，支付机客户端程序本身也是需要定期升级，但是大量的虚拟支付机纯人工升级效率太低，一般升级一台虚拟支付机需要1分钟，还需要一定量的时间做观察，长此以往维护成本会越来越高。因此本发明的集群管理方法提供一键发布，先拉出集群中几台虚拟支付机发布最新版本的客户端，完成升级后观察一定周期，确保没有问题后再对集群中的所有虚拟支付机批量升级，这种集群管理的升级方法不会造成主体业务中断，从而保证业务的高可用性。

进一步的，本发明的集群管理方法还包括：网络代理切换，网络代理切换也是为了提升业务稳定性而提出的解决方案，在没有代理切换之前，公司网络有的时候不稳定，造成虚拟支付机不可用，因此本发明在虚拟支付机集群中，部署一半虚拟支付机使用网络代理，那么即使公司网络出问题，集群中至少还有一半的虚拟支付机可以正常运行，保证业务的高可用性。

本发明立足于集群管理，支持集群中虚拟支付机的拉入拉出，方便做灰度测试以及检测到不可恢复故障后自动踢出集群，保证了业务的准确性和高可用性。本发明可实现集群中虚拟支付机的支付成功率和负载率监控、余额监控、支付机客户端一键升级发布、支付机网络代理切换、支付机异常自动恢复等一系列配套功能。

本发明还提供一种虚拟支付机的集群管理系统，图7示出一种虚拟支付机的集群管理系统的模块示意图。本发明的集群管理系统用于管理至少一个支付机集群，该支付机集群中包括多台虚拟支付机ZF1～ZFn。参照图7所示，集群管理系统40主要包括：通讯模块401，用于和支付机集群30中的各虚拟支付机(包括虚拟支付机ZF1～ZFn)通讯，搜集支付机信息、下发操作指令等等。其中，订单分配模块、反馈接收模块、第一预警模块、第二预警模块等用于与各虚拟支付机通讯的模块均包含在该通讯模块401中。执行模块402，用于执行系统定时任务，包括成功率监控、负载率监控、余额监控、异常监控等等。执行模块402根据通讯模块401接收到的各虚拟支付机的信息来执行各项监控任务，并且传递相应操作指令至通讯模块401，由通讯模块401下发至对应的虚拟支付机。后台管理模块403用于管理集群管理系统中的各个功能模块的运行。显示模块404用于实时显示监控数据，实现可视化管理。

进一步的，支付机集群30还与内网服务器405连接，内网服务器405主要提供文件下载服务，考虑到安全性，在升级支付机客户端的时候需要把打包好的程序放到内网服务器405上面。

本发明的集群管理系统采用主流的B/S结构开发，开发模型采用MVC，数据操作使用ORM简化代码，接口通讯采用http协议，报文格式为JSON，前端框架使用easyui+bootstrap，该系统包括如下组件：SmartMVC，一款基于ASP.NET平台的MVC框架，把传统asp.net网页开发变成.net.mvc模式，更好地组织代码结构，易于使用，方便扩展；SmartORM，一款基于C#语言的MySQL数据库操作类库，基于传统的ADO.NET封装，简化代码，提升开发效率；Mytable，一款基于JavaScript语言的jQuery表格插件，功能完备。

在本发明的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被例如处理器执行时可以实现上述任意一个实施例中所述集群管理方法的步骤。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述集群管理方法部分中描述的根据本发明各种示例性实施方式的步骤。

参考图8所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品500，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品500可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

所述计算机可读存储介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读存储介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

在本发明的示例性实施例中，还提供一种电子设备，该电子设备可以包括处理器，以及用于存储所述处理器的可执行指令的存储器。其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一个实施例中所述集群管理方法的步骤。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图9来描述根据本发明的这种实施方式的电子设备600。图9显示的电子设备600仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，电子设备600以通用计算设备的形式表现。电子设备600的组件可以包括但不限于：至少一个处理单元610、至少一个存储单元620、连接不同系统组件(包括存储单元620和处理单元610)的总线630、显示单元640等。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元610执行，使得所述处理单元610执行本说明书上述集群管理方法部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元610可以执行如图1中所示的步骤。

所述存储单元620可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)6201和/或高速缓存存储单元6202，还可以进一步包括只读存储单元(ROM)6203。

所述存储单元620还可以包括具有一组(至少一个)程序模块6205的程序/实用工具6204，这样的程序模块6205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线630可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备600也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备600交互的设备通信，和/或与使得该电子设备600能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口650进行。并且，电子设备600还可以通过网络适配器660与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。网络适配器660可以通过总线630与电子设备600的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备600使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本发明实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、或者网络设备等)执行根据本发明实施方式的上述集群管理方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由所附的权利要求指出。