CN107040566B

CN107040566B - 业务处理方法及装置

Info

Publication number: CN107040566B
Application number: CN201610833726.2A
Authority: CN
Inventors: 殷庆荣
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2016-09-19
Filing date: 2016-09-19
Publication date: 2020-01-31
Anticipated expiration: 2036-09-19
Also published as: CN107040566A

Abstract

本申请公开一种业务处理方法及装置，用于在利用集群处理业务过程中，提高业务的处理效率。所述方法包括：获取业务处理过程中的异常数量；根据获取的异常数量，确定针对所述业务的候选处理等级；根据所述设备确定的候选处理等级，以及所述集群内其他设备确定的其他候选处理等级，确定针对所述业务的处理等级；按照预设的针对所述处理等级的处理方式，对所述业务进行处理。

Description

业务处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种业务处理方法及装置。

背景技术

集群是一组相互独立的、通过高速网络互联的计算机(或称设备)，它们构成了一个组，并以单一系统的模式加以管理。通过这组计算机软件和/或硬件连接起来高度紧密地协作完成计算任务的计算机系统。相对于集群而言，业务请求的发起者，即输入方，可以称为外围业务。目前在多数的服务器侧，均通过集群来接收(外围业务输入的)业务请求，处理业务，并发送(输出)业务结果(给外围业务)。

现有技术在进行业务处理时如图1所示，当业务请求输入到集群后，该集群中的设备开始处理业务请求，在处理过程中，会根据处理情况判断是否发生大于预期处理时长、应用程序错误等异常情况，若未发生则输出业务结果；若发生，由于业务请求依旧输入到集群中，就会由于业务请求大量积压造成系统负载增加，从而导致响应变慢。若设备不出现故障，即使在响应慢的情况下也能够输出业务结果，但若长此以往，或极端情况下，可能导致设备(或整个集群)出现故障，最终致使集群不可用，所以一方面，现有技术利用集群处理业务时，会有较高几率出现集群不可用的情况，从而降低了业务的处理效率。另一方面，若未发生异常则只是按部就班的进行处理，从未考虑如何更加充分利用处理资源提高业务处理效率，所以也就降低了业务的处理效率。

发明内容

本申请实施例提供一种业务处理方法，用于在利用集群处理业务过程中，提高业务的处理效率。

本申请实施例提供一种业务处理装置，用于在利用集群处理业务过程中，提高业务的处理效率。

本申请实施例采用下述技术方案：

一种业务处理方法，应用于集群中一个设备，包括：

获取业务处理过程中的异常数量；

根据获取的异常数量，确定针对所述业务的候选处理等级；

根据所述设备确定的候选处理等级，以及所述集群内其他设备确定的其他候选处理等级，确定针对所述业务的处理等级；

按照预设的针对所述处理等级的处理方式，对所述业务进行处理。

优选地，根据获取的异常数量，确定针对所述业务的候选处理等级，包括：

根据预设时间周期内获取的异常数量，确定针对所述业务的候选处理等级。

优选地，根据预设时间周期内获取的异常数量，确定针对所述业务的候选处理等级，包括：

根据预设时间周期内的异常率与预设异常率阈值，确定针对所述业务的候选处理等级。

根据当前时间周期，与历史时间周期内分别获取的异常数量，确定针对所述业务的候选处理等级。

优选地，根据当前时间周期，与历史时间周期内分别获取的异常数量，确定针对所述业务的候选处理等级，包括：

根据当前时间周期内的平均异常数量与历史时间周期的平均异常数量，确定针对所述业务的候选处理等级。

根据当前时间周期中每次获取的时间点与异常数量对处理等级的影响，和/或当前时间周期的平均异常值与历史时间周期的平均异常值对处理等级的影响，确定针对所述业务的候选处理等级。

优选地，所述方法还包括：

当所述处理等级与针对所述业务的原始处理等级不同且低于所述原始处理等级时，确定所述业务的相关业务；

当确定出所述相关业务出现故障时，对所述相关业务进行监控；

当监控到所述相关业务的故障消除时，以所述原始处理等级更新所述候选处理等级。

优选地，所述集群针对所述业务，包括第一处理等级以及第二处理等级，所述第一处理等级高于所述第二处理等级。

优选地，按照预设的针对所述处理等级的处理方式，对所述业务进行处理，包括：

当确定对该业务进行降级处理后，通过降级处理方式对所述业务进行处理。

一种业务处理装置，应用于集群中一个设备，包括：获取单元、第一确定单元、第二确定单元以及处理单元，其中，

所述获取单元，获取业务处理过程中的异常数量；

所述第一确定单元，根据获取的异常数量，确定针对所述业务的候选处理等级；

所述第二确定单元，根据所述设备确定的候选处理等级，以及所述集群内其他设备确定的其他候选处理等级，确定针对所述业务的处理等级；

所述处理单元，按照预设的针对所述处理等级的处理方式，对所述业务进行处理。

优选地，所述第一确定单元，

优选地，所述装置还包括：检测单元，

优选地，所述集群针对所述业务，包括第一处理等级以及第二处理等级，

所述第一处理等级高于所述第二处理等级。

优选地，所述处理单元，

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：集群中的设备获取各自处理过程中的异常数量，并根据获取的异常数量各自确定候选处理等级，一个设备将自己的候选处理等级结合其他设备的候选处理等级，确定出最终的处理等级，并反映到业务处理中的处理方式。如果异常数量较多，也可以进行降级处理，而如果异常数量较少，则可以进行升级处理，通过提高或降低服务水平，达到降低集群出现不可用的几率，同时尽量满足不同的业务处理需求，提高处理资源的利用率，也就提高了业务的处理效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术提供的业务处理方法的示意图；

图2为本申请实施例1提供的业务处理方法的流程示意图；

图3为本申请实施例1提供的业务处理方法的示意图；

图4为本申请实施例1提供的确定处理等级的示意图；

图5为本申请实施例2提供的业务处理方法的流程示意图；

图6为本申请实施例2提供的业务处理方法的示意图；

图7为本申请实施例2提供的确定处理等级的示意图；

图8为本申请实施例3提供的业务处理装置的结构图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

如前所述，现有技术的业务处理流程如图1所示，只注重了具体的处理逻辑，但是如果集群(中的设备)长时间在较高系统负载的情况下运行，就会有较高的几率出现集群不可用的情况。所以如何降低集群出现不可用的几率，成为了亟待解决的问题。基于此缺陷，本申请提供了一种业务处理方法，用于降低集群出现不可用的几率，从而提高业务的处理效率。该方法的流程示意图如图1和图2所示，在一个集群中，可以按照预设的处理方式处理输入的业务请求，比如，就可以有两种处理等级，第一处理等级为当接收到业务请求后，立刻进行处理，而第二处理等级为当接收到业务请求后，先缓存，并在预设时间后进行处理，可以将第二处理等级看作是第一处理等级的降级处理，假设执行主体为集群中的一个设备，该方法包括下述步骤：

步骤11：获取业务处理过程中的异常数量。

当集群中的设备接收到业务请求后，便可以按照原始处理等级处理该业务请求，比如，原始处理等级可以为第一处理等级，那么就立刻按照正常业务处理流程处理该业务，又如原始处理等级可以为第二处理等级，则先将该请求进行缓存，并在缓存中排队，每隔5秒钟，获取预设个数的业务请求进行处理，等。本申请实施例中，以原始处理等级为第一处理等级为例，也就是先按照较高处理等级进行处理。

不管按照哪种处理等级处理业务请求，最终均会按照正常业务处理流程处理，而在处理过程中，就有可能出现如大于预期处理时长、应用程序错误等异常情况，比如业务请求中包含网页链接，但该网页链接实际是无法访问的，所以就会出现大于预期处理时长。当出现异常情况时，可以主动获取异常数量，也可以被动接收异常数量，具体地，获取频率方面，可以定时获取(比如每5秒获取一次)，也可以保持等待接收状态等。确定异常数量方面，可以是直接获取到，比如异常数量为10，也可以根据预定的规则进行计算，比如，有三类业务，为每类业务设置不同或不全相同的权重值，根据获取到的业务类型的数量以及分别对应的权重值，确定异常数量，具体比如，第一类业务、第二类业务和第三类业务的权重值分别为1、2和3，那么当获取到第一类业务、第二类业务和第三类业务的异常数量分别为3、5和6，那么总的异常数量就是3×1+5×2+6×3＝31。

步骤12：根据获取的异常数量，确定针对该业务的候选处理等级。

在步骤11中获取了异常数量，而异常数量可以反映设备对于该业务的处理情况，比如，可以根据异常数量的多或少，调节或保持原始处理等级，所以本步骤就可以根据获取到的异常数量，确定针对该业务的处理等级，由于确定的处理等级仅仅是集群中一个设备的确定结果，在后续还有“观察”其他设备的确定结果，所以本步骤中暂且称为候选处理等级。

具体地，上文已经提到，可以根据异常数量的多或少，调节或保持原始处理等级，所以可以引出第一种确定候选处理等级的方式：通过异常数量阈值，划分第一处理等级和第二处理等级，比如当异常数量突破1000次后，确定候选处理等级为第二处理等级，在步骤11中假设了以原始处理等级为第一处理等级，那么如果将候选处理等级确定为第二处理等级，则说明针对该业务的处理，需要降级。

在实际应用中，自从有了业务，那么随着时间的推移，异常数量就会只多不减，并且时间越久远，就越没有参考价值，利用有限的异常数量的数据进行确定候选处理等级即可。所以就有了第二种确定候选处理等级的方式：根据预设时间周期内获取的异常数量，确定针对改业务的候选处理等级。引入了时间周期的概念，原因在于时间越近的异常数量就越有参考价值，比如时间周期可以预设为1分钟，也可以通过异常数量阈值，划分第一处理等级和第二处理等级，具体比如，以原始处理等级为第一处理等级，如果最近1分钟内的异常数量超过异常数量阈值后，则认为需要降级。

在实际应用中，不同业务的正常异常数量会存在有多有少的参差不齐的情况，那么异常数量阈值就有较强的特殊性，所以为了使确定处理等级的标准更加标准化，可以通过第三种方式确定候选处理等级：根据预设时间周期内的异常率与预设异常率阈值，确定针对该业务的候选处理等级。比如，以原始处理等级为第一处理等级，如果最近1分钟内的异常率超过预设的异常率阈值，则认为需要降级。

在实际应用中，同样存在异常率会一直很高的情况(比如测试)，不管处理多少业务，均存在较高的异常率，所以只注重异常率依旧存在一定的特殊性，所以引入历史时间周期的概念，也就是不仅注重当前时间周期，还要注重历史时间周期，所以就有了第四种方式确定候选处理等级：根据当前时间周期，与历史时间周期内分别获取的异常数量，确定针对该业务的候选处理等级。当前时间周期就可以是指距离当前时刻最近的一个时间周期，比如时间周期以1分钟为例，那么当前时间周期即为距离当前时刻最近的1分钟，则历史时间周期即为当前时间周期之前的时间周期，比如当前时刻为21：19：00，那么当前时间周期就可以是21：18：00至21：19：00，前一个时间周期即为21：17：00至21：18：00。可以根据当前时间周期与前一个时间周期分别获取的异常数量的比值或大小关系，又或异常率的大小关系，确定候选处理等级。具体比如，如果当前时间周期的异常数量(异常率)远大于(比例超过10倍)前一时间周期的异常数量(异常率)时，进行降低，或者也可以根据当前时间周期的异常率分别与前一时间周期以及再前一时间周期内的异常率进行比较，如果满足预设条件则进行降低，否则不降低。

在实际应用中，平均值往往可以反映一段时间内的平均水平，所以还可以有第五种方式确定候选处理等级：根据当前时间周期内的平均异常数量与历史时间周期的平均异常数量，确定针对该业务的候选处理等级。具体地，在步骤11中已经介绍，获取的频率可以是定时获取(比如每5秒获取一次)，也可以保持等待接收状态等，并且在上文已经介绍了时间周期的概念，所以在一个时间周期内，可以有多个采集数据，比如时间周期为1分钟，每5秒获取一次异常数量，e为异常数量，那么可以有e₁＝12，e₂＝17，……，e₂₀＝9，所以平均异常数量就可以根据下述公式进行计算：

其中，n为获取次数，e_i为每次获取到的异常数量，为平均异常数量。

需要说明的是，这里的

为当前周期内，类似地，

为前一个时间周期内的平均异常数量，

为再前一个时间周期内的平均异常数量。具体的确定方式与上一种方式介绍的类似。

考虑到每次获取异常数量的时间均不同，并且离当前时刻越近，就越具有参考性，所以每次获取的时间点对处理等级是可以有影响的，并且当前时间周期与历史时间周期的平均异常值也可以对处理等级造成影响，所以就引出了第六种确定候选处理等级的方式：根据当前时间周期中每次获取的时间点与异常数量对处理等级的影响，和/或当前时间周期的平均异常值与历史时间周期的平均异常值对处理等级的影响，确定针对该业务的候选处理等级。

具体地，当前时间周期中每次获取的时间点与异常数量对处理等级的影响可以通过下述公式确定：

其中，

且，f_i为随时间递增的值，距离当前时刻越近f值越大。

具体地，当前时间周期的平均异常值与历史时间周期的平均异常值对处理等级的影响可以通过下述公式确定：

在实际应用中，可以将两种影响相加，并且添加若干影响系数，拓展为下述公式：

其中，α+β＝1；所以，如果出现其中一个为0，即为“或”的关系；m值为调节系数，可以调节当前时间周期的平均异常值与历史时间周期的平均异常值对处理等级的影响，m≥1，比如可以取m＝1.5，m值越小，当前时间周期的平均异常值与历史时间周期的平均异常值对处理等级的影响作用越大；p为放大系数，通常取奇数，p值越大，对应的影响作用就越大。

通过对w进行预设阈值并判断，决定是否降级或升级。

在实际应用中，这六种方式可以按照要求进行使用，也可以合并使用，比如在一种实施方式中，先通过第三种方式，确定预设时间周期内的异常率与预设异常率阈值的关系，如果大于预设异常率阈值，则通过第五种方式进一步确定当前时间周期内的平均异常数量与历史时间周期的平均异常数量的关系，如果当前时间周期内的平均异常数量不大于历史时间周期的平均异常数量的关系，则通过第六种方式确定w值，最终通过为w预设的阈值，确定候选处理等级。

步骤13：根据该设备确定的候选处理等级，以及该集群内其他设备确定的候选处理等级，确定针对该业务的处理等级。

在前两步骤中，具体介绍了一个设备如何确定出针对业务的候选处理等级，类似地，集群中的其他设备，也可以通过步骤11和步骤12确定针对该业务的候选处理等级，比如，针对同一个业务的业务请求，有10个设备共同处理，那么每个设备均可以在处理过程中，根据获取的异常数量确定候选处理等级，且每个设备可以将确定的结果发送到共享缓存中，以便其他设备可以获取到。

在本步骤中，这个设备即可从共享缓存中，获取其他设备对该业务的候选处理等级确定结果，并且根据自己确定的结果，综合确定出最终在业务处理过程中应用的处理等级。

具体地，确定的方式可以是“少数服从多数”或“多数服从少数”，又或“20％降级原则”，比如，当多数确定为降级(10个设备中的3个确定的候选处理等级第二处理等级)，那么就将处理等级确定为第二处理等级；又如，当少数确定为降级(10个设备中的只要有1个确定的候选处理等级第二处理等级)，那么就将处理等级确定为第二处理等级；还如，当少数确定为降级(10个设备中的只要有2个，即达到20％的设备确定的候选处理等级第二处理等级)，那么就将处理等级确定为第二处理等级。

在“少数服从多数”的情况下，可以避免由于单个或少数设备出现故障影响多数设备处理等级的情况。

在实际应用中，可以根据预设的时间周期，各设备定时更新确定出的候选处理等级，并在获取到其他设备定时更新的候选处理等级后，确定出最终的处理等级，参与决定的各设备可以均通过同一个确定策略，即确定候选处理等级的策略以及确定处理等级的策略一致。

步骤14：当确定对该业务进行降级处理后，通过降级处理方式对该业务进行处理。

在步骤13中确定出了处理等级，那么就可以按照预先对该处理等级设定的处理方式，对这个业务进行处理，比如确定对该业务进行降级处理，也就是由原来的第一处理等级，变更为第二处理等级，那么就不再按照较高处理等级进行处理，比如可以先将该业务的请求进行缓存，并在缓存中排队，每隔5秒钟，获取预设个数的业务请求进行处理。

采用实施例1提供的方法，集群中的设备在业务处理过程中，不断地通过自己对业务处理等级的决定以及其他设备对业务处理等级的决定，确定将要对该业务的处理方式，在本实施例中，以原业务处理等级为第一处理等级为例，集群中的设备在处理业务过程中，通过自己以及其他设备的降级决定确定是否需要降级处理，如果需要则按照降级处理的方式进行处理，则可以通过如限制单位时间内处理业务的个数等方式减小设备的处理压力，相比于现有技术，只注重处理逻辑的处理方式，本申请实施例引入处理等级以及降级处理，通过异常数量确定是否进行降级处理(即降低对业务的服务水平)，从而降低了集群出现不可用的几率，也就提高了业务的处理效率。

实施例2

如前所述，现有技术由于只注重处理逻辑，所以并未对业务进行处理方式的界定，在实际应用中，除了会有较高几率出现集群不可用的情况，还会出现由于系统空闲率较高，但依旧按部就班进行处理，未考虑如何更加充分利用处理资源，提高业务处理效率。在前文中已经提到了降级处理的方式，所以在实际应用中，也可以在如异常数量(异常率)变少(变低)时，进行升级处理，在实施例1中以两个等级为例，在实际应用中，还可以设定多个处理等级，满足不同的需求，所以在实施例1的基础上，且基于与实施例1相同的发明思路，本申请实施例提供另一种业务处理方法，用于降低集群出现不可用的几率的同时，通过升降业务处理等级，尽量满足不同的业务处理需求，同时提高处理资源的利用率，从而提高业务的处理效率。该方法的流程示意图如图5和图6所示，假设执行主体为集群中的一个设备，该方法包括下述步骤：

步骤21：获取业务处理过程中的异常数量。

与实施例1中步骤11类似，集群中的设备在对一个业务进行处理时，获取异常数量。

步骤22：根据获取的异常数量，确定针对该业务的候选处理等级。

与步骤12类似的，也可以通过六种方式(单独或结合)完成候选处理等级的确定，不同的是划分阈值(或规则)的制定，比如步骤12中可以通过一个阈值划分是否降级，本步骤需要通过两个阈值，划分三种候选处理等级，或三个阈值，划分四种候选处理等级，等。

步骤23：根据该设备确定的候选处理等级，以及该集群内其他设备确定的其他候选处理等级，确定针对该业务的处理等级。

与步骤22和步骤12的区别类似，由于步骤13是从两种处理等级中确定最终的处理等级，而本步骤可以从至少3中候选处理等级中确定最终的处理等级，所以可能需要更复杂的确定的方式，比如10个设备中有3种候选处理等级(高处理等级、中处理等级、低处理等级)，可以通过“20％最低级原则”确定，如果有两个设备确定出候选处理等级为低处理等级，那么就可以确定最终的处理等级为低处理等级。

步骤24：按照预设的针对该处理等级的处理方式，对该业务进行处理。

在步骤23中确定出了处理等级，本步骤就可以按照针对处理等级预设的处理方式，进行业务处理，比如，有三种处理等级，高处理等级、中处理等级、低处理等级，高处理等级对应的处理方式可以是每次处理100个业务请求；中处理等级对应的处理方式可以是每次处理50个业务请求；低处理等级对应的处理方式可以是每次处理10个业务请求。群集中的设备默认通过中处理等级进行处理，如果大部分设备出现异常数量很少，则可以升级处理，即升至高处理等级，充分利用处理资源，而当处理资源被其他业务占用，导致出现过多异常数量时，可以通过降级处理(降低一级或两级)，降低设备出现不可用的几率。

考虑到实际应用中，在对集群中的设备的性能有信心时，并且通过故障排查，确定出是外围业务出了问题，比如业务请求中包含登陆某个链接，但是由于这个链接的服务器出现问题，导致无法访问该链接，这完全是外围业务的问题，并非业务处理集群的问题，但是可能导致设备在处理过程中出现很多次异常，迫使经过步骤21至步骤24后，确定进行降级处理，而实际的情况是，如果这个链接(即外围业务修复后)是可以顺畅进行业务处理的，所以在一种实施方式中，该方法还可以包括

步骤25：当确定出的处理等级与针对该业务的原始处理等级不同且低于原始处理等级时，确定该业务的相关业务。

具体地，如果确定出的处理等级低于原始处理等级，则说明针对该业务进行了降级处理，上文已经介绍，有可能是由于外围业务导致的异常数量增加，所以就可以去确定该业务的相关业务，比如可以通过业务检测功能确定出业务请求包含的所有相关业务，比如以上文为例，业务请求中包含登陆某个链接，那么可以确定出相关业务为针对该链接的访问业务、还可能有其他相关业务。

步骤26：当确定出该相关业务出现故障时，对该相关业务进行监控。

确定出相关业务后，就可确定该业务出否出现了故障，比如访问业务出现无法访问的情况，则可以确定出该相关业务出现了故障，类似地，也可以对其他相关业务进行检测，在确定出相关业务出现故障时，对出现故障的相关业务进行监控，比如可以通过定时发送访问请求监控是否可以访问，等。

步骤27：当监控到该相关业务的故障消除时，以该原始处理等级更新该候选处理等级。

前文已经介绍，在对集群中的设备的性能有信心时，通过步骤25和步骤26确定并监控相关业务，那么在监控到相关业务的故障消除后，即可恢复正常的业务处理等级，也就是原始的处理等级，所以就可以以该原始处理等级更新该候选处理等级。此更新过程，可以无需设备进行确定候选处理等级，而由每个设备中的业务检测功能直接更新，更新后，集群中的设备就可以根据业务检测装置为自己更新的候选处理等级，以及其他设备的候选等级确定最终的处理等级。

采用实施例2提供的方法，在实施例1的基础上，集群中的设备获取各自处理过程中的异常数量，并根据获取的异常数量各自确定候选处理等级，一个设备将自己的候选处理等级结合其他设备的候选处理等级，确定出最终的处理等级，并反映到业务处理中的处理方式。如果异常数量较多，也可以进行降级处理，而如果异常数量较少，则可以进行升级处理，通过提高或降低服务水平，达到降低集群出现不可用的几率，同时尽量满足不同的业务处理需求，提高处理资源的利用率，也就提高了业务的处理效率。

实施例3

基于相同的发明构思，实施例3提供了一种业务处理装置，用于在利用集群处理业务过程中，提高业务的处理效率。图8为该装置的结构图，该装置包括：获取单元31、第一确定单元32、第二确定单元33以及处理单元34，其中，

获取单元31，可以获取业务处理过程中的异常数量；

第一确定单元32，可以根据获取的异常数量，确定针对所述业务的候选处理等级；

第二确定单元33，可以根据所述设备确定的候选处理等级，以及所述集群内其他设备确定的其他候选处理等级，确定针对所述业务的处理等级；

处理单元34，可以按照预设的针对所述处理等级的处理方式，对所述业务进行处理。

在一种实施方式中，所述第一确定单元32，可以

在一种实施方式中，该装置还包括：检测单元，可以

在一种实施方式中，所述集群针对所述业务，可以包括第一处理等级以及第二处理等级，所述第一处理等级高于所述第二处理等级。

在一种实施方式中，所述处理单元34，可以

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种业务处理方法，应用于集群中一个设备，其特征在于，包括：

获取业务处理过程中的异常数量；

根据获取的异常数量，确定针对所述业务的候选处理等级；

2.如权利要求1所述的方法，其特征在于，根据获取的异常数量，确定针对所述业务的候选处理等级，包括：

3.如权利要求2所述的方法，其特征在于，根据预设时间周期内获取的异常数量，确定针对所述业务的候选处理等级，包括：

4.如权利要求2所述的方法，其特征在于，根据预设时间周期内获取的异常数量，确定针对所述业务的候选处理等级，包括：

5.如权利要求4所述的方法，其特征在于，根据当前时间周期，与历史时间周期内分别获取的异常数量，确定针对所述业务的候选处理等级，包括：

6.如权利要求4所述的方法，其特征在于，根据当前时间周期，与历史时间周期内分别获取的异常数量，确定针对所述业务的候选处理等级，包括：

7.如权利要求1所述的方法，其特征在于，所述方法还包括：

8.如权利要求1所述的方法，其特征在于，所述集群针对所述业务，包括第一处理等级以及第二处理等级，所述第一处理等级高于所述第二处理等级。

9.如权利要求1所述的方法，其特征在于，按照预设的针对所述处理等级的处理方式，对所述业务进行处理，包括：

10.一种业务处理装置，应用于集群中一个设备，其特征在于，包括：获取单元、第一确定单元、第二确定单元以及处理单元，其中，

所述获取单元，获取业务处理过程中的异常数量；

11.如权利要求10所述的装置，其特征在于，所述第一确定单元，

12.如权利要求11所述的装置，其特征在于，所述第一确定单元，

13.如权利要求11所述的装置，其特征在于，所述第一确定单元，

14.如权利要求13所述的装置，其特征在于，所述第一确定单元，

15.如权利要求13所述的装置，其特征在于，所述第一确定单元，

16.如权利要求10所述的装置，其特征在于，所述装置还包括：检测单元，

17.如权利要求10所述的装置，其特征在于，所述集群针对所述业务，包括第一处理等级以及第二处理等级，所述第一处理等级高于所述第二处理等级。

18.如权利要求10所述的装置，其特征在于，所述处理单元，