系统集群的业务处理方法、装置、电子设备及介质

技术领域

本申请中涉及数据处理技术，尤其是一种系统集群的业务处理方法、装置、电子设备及介质。

背景技术

随着计算机处理技术的快速发展，基于互联网的各类系统平台已经越来越多的被应用在针对用户服务的业务处理中。

可以理解的，一个业务系统平台通常由多个业务服务器所组成。其中业务系统可以利用通用的物理和逻辑资源，动态的向各个业务服务器分配对应的处理任务，并由各个业务服务器利用网络资源与外部的业务节点进行信息交换，从而完成自身被分配到的任务。

然而，现有技术中的业务处理方式会导致系统平台的整体流量开销较大，这也增大了企业的运营成本。

发明内容

本申请实施例提供一种系统集群的业务处理方法、装置、电子设备及介质。用以解决相关技术中存在的，业务系统中的整体流量开销较大进而导致增加运营成本的问题。

其中，根据本申请实施例的一个方面，提供的一种系统集群的业务处理方法，包括：

当检测到业务系统的性能指标满足预设触发条件时，向所述业务系统下的各个候选业务服务器下发选举指示信息，其中所述候选业务服务器为与外部服务器协同进行业务处理的服务器；

基于各个候选业务服务器根据所述选举指示信息所反馈的性能指标，从多个所述候选业务服务器中选举出目标业务服务器；

利用所述目标业务服务器，对所述业务系统中的业务进行处理；

其中，所述目标业务服务器为所述业务系统下，唯一与所述外部服务器协同进行业务处理的服务器。

可选地，在基于本申请上述方法的另一个实施例中，所述检测到业务系统的性能指标满足预设触发条件，包括：

检测到所述业务系统的流量负荷程度超过预设负荷值，确定所述业务系统的性能指标满足所述预设触发条件；和/或，

检测到所述业务系统的当前业务处理数量超过预设数值，确定所述业务系统的性能指标满足所述预设触发条件。

可选地，在基于本申请上述方法的另一个实施例中，在所述确定所述业务系统的性能指标满足所述预设触发条件之后，还包括：

生成选举策略，所述选举策略用于指示所述候选业务服务器反馈预设类型的性能指标，其中，所述预设类型包括流量需求类型、处理性能饱和度类型、服务器属性类型的至少一种。

向所述业务系统下的各个候选业务服务器下发包含所述选举策略的选举指示信息。

可选地，在基于本申请上述方法的另一个实施例中，所述向所述业务系统下的各个候选业务服务器下发选举指示信息，包括：

向所述候选业务服务器下发，用于指示由各个候选业务服务器之间自行选举出所述目标业务服务器的第一选举指示信息；或，

向所述候选业务服务器下发，用于指示由所述业务系统从各个候选业务服务器中选举出所述目标业务服务器的第二选举指示信息

可选地，在基于本申请上述方法的另一个实施例中，所述基于各个候选业务服务器根据所述选举指示信息所反馈的性能指标，从多个所述候选业务服务器中选举出目标业务服务器，包括：

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出，处理性能饱和度最低的所述目标业务服务器；或，

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出，与所述外部服务器的部署区域最近的所述目标业务服务器；或，

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出流量需求最小的所述目标业务服务器。

可选地，在基于本申请上述方法的另一个实施例中，在所述从多个所述候选业务服务器中选举出目标业务服务器之后，还包括：

向所述目标业务服务器发送用于指示在第一预设时间段内，与所述候选业务服务器进行业务数据传输的第一传输指示消息；以及，

向所述其它业务服务器发送用于指示在所述第一预设时间段内，与所述目标业务服务器进行所述业务数据传输的第二传输指示消息；

其中，所述业务数据为所述候选业务服务器与所述外部服务器协同进行业务处理所需的信息。

可选地，在基于本申请上述方法的另一个实施例中，在所述向所述其它业务服务器发送用于指示在所述预设时间段内，与所述目标业务服务器进行所述业务数据传输的第二传输指示消息之后，还包括：

利用所述目标业务服务器，接收所述候选业务服务器通过近程通信方式传输的第一业务数据后，将所述第一业务数据通过远程通信方式传输给对应的所述外部服务器；以及，

利用所述目标业务服务器，接收所述外部服务器通过远程通信方式传输的第二业务数据后，将所述第二业务数据通过近程通信方式传输给对应的所述候选业务服务器。

其中，根据本申请实施例的又一个方面，提供的一种系统集群的业务处理装置，其特征在于，包括：

发送模块，被配置为当检测到业务系统的性能指标满足预设触发条件时，向所述业务系统下的各个候选业务服务器下发选举指示信息，其中所述候选业务服务器为与外部服务器协同进行业务处理的服务器；

生成模块，被配置为基于各个候选业务服务器根据所述选举指示信息所反馈的性能指标，从多个所述候选业务服务器中选举出目标业务服务器；

处理模块，被配置为利用所述目标业务服务器，对所述业务系统中的业务进行处理；

其中，所述目标业务服务器为所述业务系统下，唯一与所述外部服务器协同进行业务处理的服务器。

根据本申请实施例的又一个方面，提供的一种电子设备，包括：

存储器，用于存储可执行指令；以及

显示器，用于与所述存储器以执行所述可执行指令从而完成上述任一所述系统集群的业务处理方法的操作。

根据本申请实施例的还一个方面，提供的一种计算机可读存储介质，用于存储计算机可读取的指令，所述指令被执行时执行上述任一所述系统集群的业务处理方法的操作。

本申请中，可以在当检测到业务系统的性能指标满足预设触发条件时，向业务系统下的各个候选业务服务器下发选举指示信息，其中候选业务服务器为与外部服务器协同进行业务处理的服务器；基于各个候选业务服务器根据选举指示信息所反馈的性能指标，从多个候选业务服务器中选举出目标业务服务器；利用目标业务服务器，对业务系统中的业务进行处理；其中，目标业务服务器为业务系统下，唯一与外部服务器协同进行业务处理的服务器。通过应用本申请的技术方案，可以实现一种从系统中选举出一个唯一与外部服务器进行数据传输的目标服务器。以使系统中的其他服务器通过资源开销较小的进程通信方式将业务数据传输给目标服务器之后，再由目标服务器统一将业务数据传输给对应的外部服务器。从而避免了相关技术中存在的，每个业务服务器都需要与外部服务器建立通信连接才可传输数据所导致的性能负担较重且额外增加流量开销的问题。

下面通过附图和实施例，对本申请的技术方案做进一步的详细描述。

附图说明

构成说明书的一部分的附图描述了本申请的实施例，并且连同描述一起用于解释本申请的原理。

参照附图，根据下面的详细描述，可以更加清楚地理解本申请，其中：

图1示出了本申请一实施例所提供的一种系统集群的业务处理方法示意图；

图2示出了本申请一实施例所提供的一种系统集群的业务处理方法的流程示意图；

图3示出了本申请一实施例所提供的选举目标业务服务器的流程示意图；

图4示出了本申请一实施例所提供的一种电子装置的结构示意图；

图5示出了本申请一实施例所提供的一种电子设备的结构示意图；

图6示出了本申请一实施例所提供的一种存储介质的示意图。

具体实施方式

现在将参照附图来详细描述本申请的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本申请的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，不作为对本申请及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

另外，本申请各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

需要说明的是，本申请实施例中所有方向性指示(诸如上、下、左、右、前、后……)仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应的随之改变。

下面结合图1-图3来描述根据本申请示例性实施方式的用于进行系统集群的业务处理方法。需要注意的是，下述应用场景仅是为了便于理解本申请的精神和原理而示出，本申请的实施方式在此方面不受任何限制。相反，本申请的实施方式可以应用于适用的任何场景。

本申请还提出一种系统集群的业务处理方法、装置、电子设备及介质。

图1示意性地示出了根据本申请实施方式的一种系统集群的业务处理方法的流程示意图。如图1所示，该方法包括：

S101，当检测到业务系统的性能指标满足预设触发条件时，向业务系统下的各个候选业务服务器下发选举指示信息，其中候选业务服务器为与外部服务器协同进行业务处理的服务器。

S102，基于各个候选业务服务器根据选举指示信息所反馈的性能指标，从多个候选业务服务器中选举出目标业务服务器。

S103，利用目标业务服务器，对业务系统中的业务进行处理；

其中，目标业务服务器为业务系统下，唯一与外部服务器进行业务数据传输的服务器。

相关技术中，一个业务系统平台通常由多个业务服务器所组成。其中业务系统可以利用通用的物理和逻辑资源，动态的向各个业务服务器分配对应的处理任务，并由各个业务服务器利用网络资源与外部的业务节点进行信息交换，从而完成自身被分配到的任务。

可以理解的，对于每个业务服务器来说，其在和外部的业务节点进行信息交换得到过程中通常可以通过两种方式来实现。

一种是由业务服务器通过网络传输协议(例如超文本传输协议HTTP，或超文本传输安全协议HTTPS协议等等)调用系统为其提供的服务接口，主动发起连接请求到外部服务器并与其在建立的通信通道上进行数据传输。这种情况下，由于在完成每次的信息或数据交互后，业务服务器便会关闭连接，也即每次调用结束后业务服务器便失去了与外部服务器的连接，这也导致二者需要频繁的建立通信链路通道后才可实现数据的传输。

另一种通信方式则是由业务服务器主动发起长连接请求到外部服务器并与其在建立的通信通道上进行数据传输。这种情况下，二者建立的通信通道能够长时间保留。以便二者随时实现数据的传输。

可以理解的，无论上述哪种通信方式都会对业务服务器造成一定的消耗，例如对于长连接来说，虽然其可以保证两个服务器之间的消息能够及时地被传输，但是维持长连接通道对业务服务器的流量以及性能消耗也很明显。而对于短连接来说，由于其需要频繁建立通信链路通道，这也同样会导致业务服务器的流量以及性能消耗。

进一步的，针对上述存在的问题，本申请提出一种系统集群的业务处理方法，其思想为实现一种从系统中选举出一个唯一与外部服务器进行数据传输的目标服务器。以使系统中的其他服务器通过资源开销较小的进程通信方式将业务数据传输给目标服务器之后，再由目标服务器统一将业务数据传输给对应的外部服务器的技术方案。

进一步而言，本申请结合图2，对方案进行具体步骤说明：

步骤1、检测到业务系统的流量负荷程度超过预设负荷值，确定业务系统的性能指标满足预设触发条件。

其中，为了避免业务系统中，每个业务服务器都需要与外部服务器建立通信连接才可传输数据所导致的性能负担较重且额外增加流量开销的问题。本申请可以在检测到业务系统的流量负载较大时，启动后续选举目标业务服务器的技术方案

一种方式中，业务系统的流量负荷程度可以由系统中每个业务服务器所消耗的流量负载总和来确定。作为示例的，流量负荷程度可以由每个业务服务器在与外部服务器搭建链路通道过程中所消耗的流量值，以及维持该链路通道的过程中所消耗的流量值来得到。

步骤2、检测到业务系统的当前业务处理数量超过预设数值，确定业务系统的性能指标满足预设触发条件。

一种方式中，业务系统的性能指标也可以由系统中每个业务服务器所负责的业务处理数量总和来确定。可以理解的，每个业务服务器被分配的业务数量越多，其需要与外部服务器搭建链路通道或维持链路通道的次数就会越多。因此在该过程中所消耗的流量以及计算资源便越大。因此在后续即可实施选举目标业务服务器的步骤。

一种方式中，本申请不对预设数值进行具体限定，例如可以为1000个，也可以为5000个等等。

步骤3、生成用于指示候选业务服务器反馈预设类型的性能指标的选举策略。

其中，预设类型包括流量需求类型、处理性能饱和度类型、服务器属性类型的至少一种。

步骤4、向业务系统下的各个候选业务服务器下发包含选举策略的选举指示信息。

其中，下发选举指示信息的步骤包括以下两种方式的其中一种：

第一种方式：

向候选业务服务器下发，用于指示由各个候选业务服务器之间自行选举出目标业务服务器的第一选举指示信息。

其中，对于该种方式下可以由各个候选业务服务器之间互相发送预设类型的性能指标。并以此选举出其中性能指标较高的候选业务服务器作为目标业务服务器。

结合图3，本申请以下以预设类型的性能指标为服务器属性类型中包括的服务器迭代版本为例进行说明，可以理解的，服务器迭代版本越高，其对应的处理性能最佳，因此其处理性能饱和度最低。

其中，每个候选业务服务器可以根据自身的迭代版本建立一个txid字段，可以理解的，该字段中标明了自身的版本信息。例如对于候选业务服务器A1来说，其自身的服务器迭代版本为1.0。那么其生成的txid字段即可为txid1。同样的，对于候选业务服务器A2来说，其自身的服务器迭代版本为2.0。那么其生成的txid字段即可为txid2。对于候选业务服务器A3来说，其自身的服务器迭代版本为3.0。那么其生成的txid字段即可为txid3。

进一步的，每个服务器将自身的txid字段+1后，发送给另外两个候选业务服务器。例如对于候选业务服务器A2来说，若其通过比较接收到的txid字段与自身的txid字段大小关系之后，若确定自身的txid字段较大，则可以把自身设置为目标业务服务器M。并将自身为目标业务服务器M的通知消息发送给另外两个候选业务服务器。

同样的，若候选业务服务器A2过比较接收到的txid字段与自身的txid字段大小关系之后，若确定自身的txid字段较小，则可以把自身设置为后续业务服务器S。并在后续等待其他后续业务服务器发送过来的通知消息。

第二种方式：

向候选业务服务器下发，用于指示由业务系统从各个候选业务服务器中选举出目标业务服务器的第二选举指示信息。

其中，对于该种方式下可以由各个候选业务服务器之间将预设类型的性能指标发送给系统，以使由系统统一接收到各个性能指标后，以此选举出其中性能指标较高的候选业务服务器作为目标业务服务器。

举例来说，每个候选业务服务器同样可以根据自身的流量需求建立一个txid字段，可以理解的，该字段中标明了自身在未来一段时间内的流量需求。例如对于候选业务服务器A1来说，其自身在未来一段时间内的流量需求为50G。那么其生成的txid字段即可为txid50。同样的，对于候选业务服务器A2来说，其自身在未来一段时间内的流量需求为500G。那么其生成的txid字段即可为txid500。对于候选业务服务器A3来说，自身在未来一段时间内的流量需求为100G。那么其生成的txid字段即可为txid100。

进一步的，系统可以通过比较接收到的txid字段确定候选业务服务器A1对应的流量需求较小，那么则可以把候选业务服务器A1设置为目标业务服务器M。

步骤5、基于各个候选业务服务器根据选举指示信息所反馈的性能指标，从多个候选业务服务器中选举出目标业务服务器，包括：

其中，选举出目标业务服务器的步骤包括以下三种方式之一：

第一种方式：

基于各个候选业务服务器的性能指标，从多个候选业务服务器中选举出，处理性能饱和度最低的目标业务服务器；

第二种方式：

基于各个候选业务服务器的性能指标，从多个候选业务服务器中选举出，与外部服务器的部署区域最近的目标业务服务器；或，

第三种方式：

基于各个候选业务服务器的性能指标，从多个候选业务服务器中选举出流量需求最小的目标业务服务器。

需要说明的是，本申请中的目标业务服务器可以为一个，也可以为小于候选业务服务器数量的多个。

步骤6、向目标业务服务器发送用于指示在第一预设时间段内，与候选业务服务器进行业务数据传输的第一传输指示消息。

步骤7、向其它业务服务器发送用于指示在第一预设时间段内，与目标业务服务器进行业务数据传输的第二传输指示消息。

步骤8、利用目标业务服务器，接收候选业务服务器通过近程通信方式传输的第一业务数据后，将第一业务数据通过远程通信方式传输给对应的外部服务器。

其中，为了减少业务系统中，每个业务服务器都需要与外部服务器建立通信连接才可传输数据所导致的性能负担较重且额外增加流量开销的问题。本申请采用了一种由各个业务服务器之间利用流量及性能开销较小的近程通信方式传输业务数据的技术方案。

在一方式中，近程通信方式可以包括蓝牙通信方式，ZigBee通信方式、NFC通信方式、lora通信方式以及局域网通信方式等等。

步骤9、利用目标业务服务器，接收外部服务器通过远程通信方式传输的第二业务数据后，将第二业务数据通过近程通信方式传输给对应的候选业务服务器。

其中，对于目标业务服务器与外部服务器的数据传输过程来说，即可通过包括4G通信方式，5G通信方式以及NB-Iot通信方式等的远程通信方式所实现。可以理解的，由于只有目标业务服务器与外部服务器进行数据传输，因此无论是搭建链路通道的数量，还是传输数据的数量，还是维持通道的时间都会较之前大幅缩小。因此不仅可以节省系统的整体流量开销。还可以减少多个业务服务器的计算性能损耗。

本申请中，可以在当检测到业务系统的性能指标满足预设触发条件时，向业务系统下的各个候选业务服务器下发选举指示信息，其中候选业务服务器为与外部服务器协同进行业务处理的服务器；基于各个候选业务服务器根据选举指示信息所反馈的性能指标，从多个候选业务服务器中选举出目标业务服务器；利用目标业务服务器，对业务系统中的业务进行处理；其中，目标业务服务器为业务系统下，唯一与外部服务器协同进行业务处理的服务器。

通过应用本申请的技术方案，可以实现一种从系统中选举出一个唯一与外部服务器进行数据传输的目标服务器。以使系统中的其他服务器通过资源开销较小的进程通信方式将业务数据传输给目标服务器之后，再由目标服务器统一将业务数据传输给对应的外部服务器。从而避免了相关技术中存在的，每个业务服务器都需要与外部服务器建立通信连接才可传输数据所导致的性能负担较重且额外增加流量开销的问题。

可选地，在基于本申请上述方法的另一个实施例中，所述检测到业务系统的性能指标满足预设触发条件，包括：

检测到所述业务系统的流量负荷程度超过预设负荷值，确定所述业务系统的性能指标满足所述预设触发条件；和/或，

检测到所述业务系统的当前业务处理数量超过预设数值，确定所述业务系统的性能指标满足所述预设触发条件。

可选地，在基于本申请上述方法的另一个实施例中，在所述确定所述业务系统的性能指标满足所述预设触发条件之后，还包括：

生成选举策略，所述选举策略用于指示所述候选业务服务器反馈预设类型的性能指标，其中，所述预设类型包括流量需求类型、处理性能饱和度类型、服务器属性类型的至少一种。

向所述业务系统下的各个候选业务服务器下发包含所述选举策略的选举指示信息。

可选地，在基于本申请上述方法的另一个实施例中，所述向所述业务系统下的各个候选业务服务器下发选举指示信息，包括：

向所述候选业务服务器下发，用于指示由各个候选业务服务器之间自行选举出所述目标业务服务器的第一选举指示信息；或，

向所述候选业务服务器下发，用于指示由所述业务系统从各个候选业务服务器中选举出所述目标业务服务器的第二选举指示信息

可选地，在基于本申请上述方法的另一个实施例中，所述基于各个候选业务服务器根据所述选举指示信息所反馈的性能指标，从多个所述候选业务服务器中选举出目标业务服务器，包括：

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出，处理性能饱和度最低的所述目标业务服务器；或，

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出，与所述外部服务器的部署区域最近的所述目标业务服务器；或，

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出流量需求最小的所述目标业务服务器。

可选地，在基于本申请上述方法的另一个实施例中，在所述从多个所述候选业务服务器中选举出目标业务服务器之后，还包括：

向所述目标业务服务器发送用于指示在第一预设时间段内，与所述候选业务服务器进行业务数据传输的第一传输指示消息；以及，

向所述其它业务服务器发送用于指示在所述第一预设时间段内，与所述目标业务服务器进行所述业务数据传输的第二传输指示消息；

其中，所述业务数据为所述候选业务服务器与所述外部服务器协同进行业务处理所需的信息。

可选地，在基于本申请上述方法的另一个实施例中，在所述向所述其它业务服务器发送用于指示在所述预设时间段内，与所述目标业务服务器进行所述业务数据传输的第二传输指示消息之后，还包括：

利用所述目标业务服务器，接收所述候选业务服务器通过近程通信方式传输的第一业务数据后，将所述第一业务数据通过远程通信方式传输给对应的所述外部服务器；以及，

利用所述目标业务服务器，接收所述外部服务器通过远程通信方式传输的第二业务数据后，将所述第二业务数据通过近程通信方式传输给对应的所述候选业务服务器。

通过应用本申请的技术方案，可以实现一种从系统中选举出一个唯一与外部服务器进行数据传输的目标服务器。以使系统中的其他服务器通过资源开销较小的进程通信方式将业务数据传输给目标服务器之后，再由目标服务器统一将业务数据传输给对应的外部服务器。从而避免了相关技术中存在的，每个业务服务器都需要与外部服务器建立通信连接才可传输数据所导致的性能负担较重且额外增加流量开销的问题。

可选的，在本申请的另外一种实施方式中，如图4所示，本申请还提供一种系统集群的业务处理装置。其中包括：

发送模块201，被配置为当检测到业务系统的性能指标满足预设触发条件时，向所述业务系统下的各个候选业务服务器下发选举指示信息，其中所述候选业务服务器为与外部服务器协同进行业务处理的服务器；

生成模块202，被配置为基于各个候选业务服务器根据所述选举指示信息所反馈的性能指标，从多个所述候选业务服务器中选举出目标业务服务器；

处理模块203，被配置为利用所述目标业务服务器，对所述业务系统中的业务进行处理；

其中，所述目标业务服务器为所述业务系统下，唯一与所述外部服务器协同进行业务处理的服务器。

通过应用本申请的技术方案，可以实现一种从系统中选举出一个唯一与外部服务器进行数据传输的目标服务器。以使系统中的其他服务器通过资源开销较小的进程通信方式将业务数据传输给目标服务器之后，再由目标服务器统一将业务数据传输给对应的外部服务器。从而避免了相关技术中存在的，每个业务服务器都需要与外部服务器建立通信连接才可传输数据所导致的性能负担较重且额外增加流量开销的问题。

在本申请的另外一种实施方式中，生成模块202，被配置执行的步骤包括：

检测到所述业务系统的流量负荷程度超过预设负荷值，确定所述业务系统的性能指标满足所述预设触发条件；和/或，

检测到所述业务系统的当前业务处理数量超过预设数值，确定所述业务系统的性能指标满足所述预设触发条件。

在本申请的另外一种实施方式中，生成模块202，被配置执行的步骤包括：

生成选举策略，所述选举策略用于指示所述候选业务服务器反馈预设类型的性能指标，其中，所述预设类型包括流量需求类型、处理性能饱和度类型、服务器属性类型的至少一种。

向所述业务系统下的各个候选业务服务器下发包含所述选举策略的选举指示信息。

在本申请的另外一种实施方式中，生成模块202，被配置执行的步骤包括：

向所述候选业务服务器下发，用于指示由各个候选业务服务器之间自行选举出所述目标业务服务器的第一选举指示信息；或，

向所述候选业务服务器下发，用于指示由所述业务系统从各个候选业务服务器中选举出所述目标业务服务器的第二选举指示信息。

在本申请的另外一种实施方式中，生成模块202，被配置执行的步骤包括：

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出，处理性能饱和度最低的所述目标业务服务器；或，

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出，与所述外部服务器的部署区域最近的所述目标业务服务器；或，

基于各个候选业务服务器的性能指标，从多个所述候选业务服务器中选举出流量需求最小的所述目标业务服务器。

在本申请的另外一种实施方式中，生成模块202，被配置执行的步骤包括：

向所述目标业务服务器发送用于指示在第一预设时间段内，与所述候选业务服务器进行业务数据传输的第一传输指示消息；以及，

向所述其它业务服务器发送用于指示在所述第一预设时间段内，与所述目标业务服务器进行所述业务数据传输的第二传输指示消息。

在本申请的另外一种实施方式中，生成模块202，被配置执行的步骤包括：

利用所述目标业务服务器，接收所述候选业务服务器通过近程通信方式传输的第一业务数据后，将所述第一业务数据通过远程通信方式传输给对应的所述外部服务器；以及，

利用所述目标业务服务器，接收所述外部服务器通过远程通信方式传输的第二业务数据后，将所述第二业务数据通过近程通信方式传输给对应的所述候选业务服务器。

本申请实施方式还提供一种电子设备，以执行上述系统集群的业务处理方法。请参考图5，其示出了本申请的一些实施方式所提供的一种电子设备的示意图。如图5所示，电子设备3包括：处理器300，存储器301，总线302和通信接口303，所述处理器300、通信接口303和存储器301通过总线302连接；所述存储器301中存储有可在所述处理器300上运行的计算机程序，所述处理器300运行所述计算机程序时执行本申请前述任一实施方式所提供的系统集群的业务处理方法。

其中，存储器301可能包含高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口303(可以是有线或者无线)实现该装置网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。

总线302可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。其中，存储器301用于存储程序，所述处理器300在接收到执行指令后，执行所述程序，前述本申请实施例任一实施方式揭示的所述数据识别的方法可以应用于处理器300中，或者由处理器300实现。

处理器300可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器300中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器300可以是通用处理器，包括处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器301，处理器300读取存储器301中的信息，结合其硬件完成上述方法的步骤。

本申请实施例提供的电子设备与本申请实施例提供的数据识别的方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施方式还提供一种与前述实施方式所提供的数据识别的方法对应的计算机可读存储介质，请参考图6，其示出的计算机可读存储介质为光盘40，其上存储有计算机程序(即程序产品)，所述计算机程序在被处理器运行时，会执行前述任意实施方式所提供的系统集群的业务处理方法。

需要说明的是，所述计算机可读存储介质的例子还可以包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

本申请的上述实施例提供的计算机可读存储介质与本申请实施例提供的数据识别的方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。

需要说明的是：

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下示意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。