业务处理方法及系统与流程

本申请涉及通信技术领域，尤其涉及业务处理方法及系统。

背景技术：

当出现客户端的请求量较大、服务端资源达到瓶颈等异常情况，服务端通常采用对低等级的业务进行一定的降级处理来保证核心业务的正常处理。例如存在业务a和业务b，a的优先级高于b，当服务端出现异常的情况下，针对a和b的请求到达服务端时，服务端针对业务a会继续进行后续的业务服务处理，而降低业务b的处理优先级，甚至可能直接放弃处理业务b，并且向客户端返回失败消息。

此种处理方式中，每一次业务请求都到达了服务端，对于用户而言，当没有返回期望结果的时候，可能会再次进行刷新重试，因此反而造成了大量的重复请求到达服务端。服务端对于每一次请求都需要开启线程进行响应，在服务端故障情况下，反而可能进一步增加服务端的处理压力。

技术实现要素：

为克服相关技术中存在的问题，本申请提供了业务处理方法及系统。

一种业务处理方法，用于客户端，预先针对不同业务，配置有每种业务对应的业务等级，所述方法包括：

获取待发送至服务端的针对目标业务的处理请求；

获取配置信息；

根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务；

根据判断结果确定是否将所述处理请求发送给所述服务端。

可选的，所述方法预先针对不同用户，配置有用户对应的用户等级；

所述方法还包括：

确定处理请求发起方对应的用户等级；

所述根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

可选的，所述用户等级根据如下一种或多种信息而确定：

用户是否为付费用户、用户是否为实名认证用户或用户的信用等级。

可选的，所述根据判断结果确定是否将所述处理请求发送给所述服务端，包括：

当确定所述服务端能够处理所述业务，将所述处理请求发送给服务端；

当确定所述服务端无法处理所述业务，响应于所述处理请求，输出处理失败相关信息。

可选的，所述业务等级和/或所述用户等级在用户账户首次登录时，从所述服务端获取。

可选的，在所述业务等级和/或所述用户等级需要更新时，通过服务端主动推送的方式获取需更新的业务等级和/或用户等级，并利用新获取的业务等级和/或所述用户等级进行更新。

可选的，所述获取配置信息，包括：

通过所述服务端主动推送的方式获取所述配置信息；或，

获取携带有所述配置信息的请求响应数据，通过所述请求响应数据获得所述处理能力信息。

可选的，所述服务端包括一台服务器或一套服务器集群。

可选的，所述配置信息包括业务降级阈值；

所述根据所述目标业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息还包括用户降级阈值；

所述根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

比较所述业务等级与所述业务降级阈值、比较所述用户等级与所述用户降级阈值，根据比较结果判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息包括用于指示服务端当前对于业务的处理能力信息；

可选的，所述配置信息包括用于指示服务端当前对于业务的处理能力信息，根据所述业务处理能力信息，确定是否发起所述判断所述服务端是否能够处理所述目标业务之操作。

一种业务处理方法，预先针对不同业务，配置有每种业务对应的业务等级，所述方法包括：

客户端获取待发送至服务端的针对目标业务的处理请求；

服务端获取配置信息，并提供给所述客户端；

客户端根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务；

客户端根据判断结果确定是否将所述处理请求发送给所述服务端。

可选的，所述服务端获取配置信息，并提供给所述客户端，包括：

所述服务端判断是否需要降级处理，在确定需要降级处理后，获取配置信息，并提供给所述客户端。

可选的，所述方法预先针对不同用户，配置有用户对应的用户等级；

所述方法还包括：

所述客户端确定处理请求发起方对应的用户等级；

所述客户端根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

客户端根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

可选的，所述用户等级根据如下一种或多种信息而确定：

用户是否为付费用户、用户是否为实名认证用户或用户的信用等级。

可选的，所述客户端根据判断结果确定是否将所述处理请求发送给所述服务端，包括：

当所述客户端确定所述服务端能够处理所述业务，将所述处理请求发送给服务端；

当所述客户端确定所述服务端无法处理所述业务，响应于所述处理请求，输出处理失败相关信息。

可选的，所述业务等级和/或所述用户等级在用户账户首次登录时，所述客户端从所述服务端获取。

可选的，在所述业务等级和/或所述用户等级需要更新时，所述服务端主动推送需更新的业务等级和/或用户等级给所述客户端，所述客户端利用新获取的业务等级和/或所述用户等级进行更新。

可选的，所述服务端获取配置信息，并提供给所述客户端，包括：

所述服务端获取配置信息，并主动推送给所述客户端；或，

所述服务端发送携带有所述配置信息的请求响应数据给所述客户端。

可选的，所述服务端包括一台服务器或一套服务器集群。

可选的，所述配置信息包括业务降级阈值；

所述根据所述目标业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息还包括用户降级阈值；

所述根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

比较所述业务等级与所述业务降级阈值、比较所述用户等级与所述用户降级阈值，根据比较结果判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息包括用于指示服务端当前对于业务的处理能力信息，根据所述业务处理能力信息，确定是否发起所述判断所述服务端是否能够处理所述目标业务之操作。

一种业务处理装置，预先针对不同业务，配置有每种业务对应的业务等级，所述装置包括：

请求获取模块，用于：获取待发送至服务端的针对目标业务的处理请求；

配置模块，用于：获取配置信息；

判断模块，用于：根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务；

请求阻挡模块，用于：根据判断结果确定是否将所述处理请求发送给所述服务端。

可选的，所述装置预先针对不同用户，配置有用户对应的用户等级；

所述装置还包括：

用户等级确定模块，用于：确定处理请求发起方对应的用户等级；

所述判断模块，还用于：

根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

可选的，所述用户等级根据如下一种或多种信息而确定：

用户是否为付费用户、用户是否为实名认证用户或用户的信用等级。

可选的，所述请求阻挡模块，还用于：

当确定所述服务端能够处理所述业务，将所述处理请求发送给服务端；

当确定所述服务端无法处理所述业务，响应于所述处理请求，输出处理失败相关信息。

可选的，所述业务等级和/或所述用户等级在用户账户首次登录时，从所述服务端获取。

可选的，在所述业务等级和/或所述用户等级需要更新时，通过服务端主动推送的方式获取需更新的业务等级和/或用户等级，并利用新获取的业务等级和/或所述用户等级进行更新。

可选的，所述配置模块，还用于：

通过所述服务端主动推送的方式获取所述配置信息；或，

获取携带有所述配置信息的请求响应数据，通过所述请求响应数据获得所述配置信息。

可选的，所述服务端包括一台服务器或一套服务器集群。

可选的，所述配置信息包括业务降级阈值；

所述判断模块，还用于：

比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息还包括用户降级阈值；

所述判断模块，还用于：

比较所述业务等级与所述业务降级阈值、比较所述用户等级与所述用户降级阈值，根据比较结果判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息包括用于指示服务端当前对于业务的处理能力信息；

所述判断模块还用于：根据所述业务处理能力信息，确定是否发起所述判断所述服务端是否能够处理所述目标业务之操作。

一种业务处理系统，预先针对不同业务，配置有每种业务对应的业务等级，所述系统包括客户端和服务端；

所述客户端用于获取待发送至服务端的针对目标业务的处理请求；

所述服务端用于获取配置信息，并提供给所述客户端；

所述客户端用于根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务；

所述客户端用于根据判断结果确定是否将所述处理请求发送给所述服务端。

可选的，所述服务端具体用于：判断是否需要降级处理，在确定需要降级处理后，获取配置信息，并提供给所述客户。

可选的，所述系统预先针对不同用户，配置有用户对应的用户等级；

所述客户端还用于确定处理请求发起方对应的用户等级；

所述客户端用于根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

所述客户端用于根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

可选的，所述用户等级根据如下一种或多种信息而确定：

用户是否为付费用户、用户是否为实名认证用户或用户的信用等级。

可选的，所述客户端用于根据判断结果确定是否将所述处理请求发送给所述服务端，包括：

当所述客户端确定所述服务端能够处理所述业务，将所述处理请求发送给服务端；

当所述客户端确定所述服务端无法处理所述业务，响应于所述处理请求，输出处理失败相关信息。

可选的，所述业务等级和/或所述用户等级在用户账户首次登录时，所述客户端从所述服务端获取。

可选的，在所述业务等级和/或所述用户等级需要更新时，所述服务端主动推送需更新的业务等级和/或用户等级给所述客户端，所述客户端利用新获取的业务等级和/或所述用户等级进行更新。

可选的，所述服务端用于获取配置信息，并提供给所述客户端，包括：

所述服务端用于获取配置信息，并主动推送给所述客户端；或，

所述服务端用于发送携带有所述配置信息的请求响应数据给所述客户端。

可选的，所述配置信息包括业务降级阈值；

所述客户端还用于：

比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息还包括用户降级阈值；

所述客户端还用于：

比较所述业务等级与所述业务降级阈值、比较所述用户等级与所述用户降级阈值，根据比较结果判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息包括用于指示服务端当前对于业务的处理能力信息；

所述客户端还用于：

根据所述业务处理能力信息，确定是否发起所述判断所述服务端是否能够处理所述目标业务之操作。

一种电子设备，包括：

处理器；

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

其中，所述处理器被配置为：

获取待发送至服务端的针对目标业务的处理请求；

获取用于指示服务端当前对于业务的处理能力信息；

根据所述业务对应的业务等级与所述处理能力信息，判断所述服务端是否能够处理所述目标业务；

根据判断结果确定是否将所述处理请求发送给所述服务端。

本申请的实施例提供的技术方案可以包括以下有益效果：

本申请实施例的业务处理方案，可以由客户端对处理请求进行降级处理，客户端获取配置信息，可以根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述业务，并根据判断结果确定是否将所述处理请求发送给所述服务端。因此，若服务端发生异常，可以自动筛选出某些重要性较低的业务处理请求，这些处理请求可以不发送给服务端，从而可以减少服务端的处理压力。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1a是本申请根据一示例性实施例示出的一种业务处理方法的应用场景示意图。

图1b是本申请根据一示例性实施例示出的一种业务处理方法的流程图。

图2a是本申请根据一示例性实施例示出的一种客户端与服务端对业务处理的示意图。

图2b是本申请根据一示例性实施例示出的另一种业务处理的应用场景示意图。

图3是本申请根据一示例性实施例示出的另一种业务处理方法的流程图。

图4是本申请根据一示例性实施例示出的一种业务处理装置的框图。

图5是本申请业务处理装置所在电子设备的一种硬件结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

相关技术中，对于客户端生成的针对某种业务的处理请求，处理请求会达到服务端侧，由服务端进行相应处理，并向客户端返回相应的数据。当出现客户端的请求量较大、服务端资源达到瓶颈等异常情况，服务端通常采用对低等级的业务进行一定的降级处理来保证核心业务的正常处理。对于被降低处理优先级的请求，服务端可能会直接放弃处理请求，并且向客户端返回失败消息。此种处理方式中，每一次业务请求都到达了服务端，对于用户而言，当没有返回期望结果的时候，可能会再次进行刷新重试，因此反而造成了大量的重复请求到达服务端。服务端对于每一次请求都需要开启线程进行响应，在服务端故障情况下，反而可能进一步增加服务端的处理压力。

本申请实施例通过的业务处理方案，可以由客户端对处理请求进行降级处理，客户端获取到配置信息，可以根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述业务，并根据判断结果确定是否将所述处理请求发送给所述服务端。因此，若服务端发生异常，可以自动筛选出某些重要性较低的业务处理请求，这些处理请求可以不发送给服务端，从而可以减少服务端的处理压力。接下来对本申请实施例进行详细说明。

如图1a所示，是本申请根据一示例性实施例示出的一种业务处理方法的应用场景示意图，图1a中包括服务方配置的服务端，图1a中为了示例方便，服务端以一个服务器的形式进行示意，实际应用中，服务方可以根据需要灵活配置多个服务器、服务器集群或者云服务平台等等。

图1a中还包括若干个用户及用户持有的电子设备，服务方提供的客户端可安装于智能手机、平板电脑、个人数字助理或个人计算机等多类电子设备中。服务方可以根据其业务需要，在客户端中提供针对一项或多项业务的业务入口，客户端可以检测用户对各业务入口的操作，根据用户操作生成相应的针对一项或多项业务的处理请求。

如图1b所示，是本申请根据一示例性实施例示出的一种业务处理方法的流程图，该方法可应用于图1a中的客户端中，该方法包括如下步骤：

在步骤102中，获取待发送至服务端的针对目标业务的处理请求。

在步骤104中，获取配置信息。

在步骤106中，根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

在步骤108中，根据判断结果确定是否将所述处理请求发送给所述服务端。

本实施例的业务处理方案，可以预先针对不同业务，配置有每种业务对应的业务等级。配置业务等级的目的，是为了区分不同类业务的重要性，以在服务端异常情况下，合理地选择某些较为重要的处理请求进行相应的业务处理，也即是，在服务端无法高效处理所有业务请求的情况下，重要性较高的业务请求将得到优先处理。

而业务等级的具体划分，可以根据实际的业务特点而灵活确定。举例来说，对于提供第三方支付服务的服务方，资金转移业务、资金查看业务或支付业务等业务的重要性是较高的，因此此类业务可以设置较高的等级，而服务窗或用户头像更新等业务的重要性较低，因此此类业务可以设置较低的等级。对于提供网购平台的服务方，订单生成、物品相关信息、支付等业务的重要性较高，因此此类业务可以设置较高的等级，而用户评论或查阅用户个人信息等业务的重要性较低，因此此类业务可以设置较低的等级。

实际应用中，服务方可以根据实际业务情况划分各种业务的业务等级，业务等级可以采用数字、字符或字符串等进行表示，并可以将各种业务对应的业务等级的相关信息进行存储。如下表格所示，示出了4种业务对应的业务等级，其中，业务等级采用数字1至3进行区分，数值高低与等级高低之间的关系，可以根据实际需要而灵活配置。

除了对不同业务的重要性进行区分，本申请还提供另一实施例，可以进一步对用户进行区分，使得对不同用户发起的业务请求的处理更为精细化。具体的，本实施例方案预先针对不同用户，配置有用户对应的用户等级。

所述方法还可包括：

确定处理请求发起方对应的用户等级；

所述根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

在一些应用场景中，服务方可能会采用实名认证、付费或信用等级等信息对不同用户进行区分，此种场景下，某些用户的处理请求可能需要优先保障。因此，本实施例采用用户等级对用户进行区分。实际应用中，服务方可以根据实际业务情况划分不同用户的用户等级，例如可以通过用户是否为付费用户、用户是否为实名认证用户或用户的信用等级。而用户等级可以采用数字、字符或字符串等进行表示，并可以将用户对应的用户等级的相关信息进行存储。如下表格所示，示出了4个用户对应的用户等级，其中，用户等级采用数字1至6进行区分，数值高低与等级高低之间的关系，可以根据实际需要而灵活配置。

另一方面，本实施例中的客户端可以获取配置信息，客户端基于配置信息决定处理请求是否发送给服务端，因此，配置信息的作用可以包括指示客户端是否执行启动对处理请求的决策、获知服务端当前的处理能力、如何决策处理请求是否发送给服务端等等。基于此，实际应用中配置信息可以有多种可能，接下来列举配置信息的几种可选实施方式。

第一种，在某些例子中，配置信息可以包括业务降级阈值。业务降级阈值可以表示当前服务端所能处理的部分重要的业务，客户端可以在业务降级阈值的指示下，确定当前服务端需要进行降级处理，从而进行对处理请求是否发送给服务端的决策。

具体的，所述根据所述目标业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务。

本实施例中，可以通过比较目标业务的业务等级与业务降级阈值的高低，确定目标业务的重要性高低，从而确定服务端是否能够处理该目标业务。举例来说，假设业务等级以数字表示，数字大小代表等级的高低(即业务的重要性高低)。业务降级阈值可以是某个数字，代表服务端当前所能处理的是高于该业务降级阈值的业务。客户端在该业务降级阈值的指示下，低于该业务降级阈值的业务的处理请求则可以决定不发送给服务端，以减少服务端的处理压力，而高于或等于该业务降级阈值的业务的处理请求则可以决定发送给服务端进行处理。

第二种，在某些例子中，还可能会对用户进行等级区分，因此所述配置信息还可以包括用户降级阈值。用户降级阈值可以表示当前服务端所能处理的部分重要的用户的业务，客户端可以在用户降级阈值的指示下，确定当前服务端需要进行降级处理，从而根据发起处理请求的用户的等级，以及所涉及的具体业务的等级，进行对处理请求是否发送给服务端的决策。

具体的，所述根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

比较所述业务等级与所述业务降级阈值、比较所述用户等级与所述用户降级阈值，根据比较结果判断所述服务端是否能够处理所述目标业务。

本实施例中，可以通过比较目标业务的业务等级与业务降级阈值的高低、以及比较发起处理请求的用户等级与用户等级阈值，进而确定目标业务的重要性高低，从而确定服务端是否能够处理该目标业务。本实施例结合了业务等级和用户等级对处理请求进行决策，具体的判断策略可以根据需要而灵活确定。举例来说，决策过程可以进行两次比较：“比较所述业务等级与所述业务降级阈值”和“比较所述用户等级与所述用户降级阈值”，可以是满足业务等级较高或用户等级较高中任一种的情况下，确定服务端能够处理该目标业务；也可以是满足业务等级较高，且用户等级较高的情况下，确定服务端能够处理该目标业务。

在其他例子中，还可以是在比较业务等级与所述业务降级阈值的差值、以及用户等级与所述用户降级阈值的差值，根据上述两个差值来确定服务端是否能够处理该目标业务。例如，假设业务等级高于所述业务降级阈值，两者差值是3个业务等级，而用户等级低于所述用户降级阈值的差值，两者差值是-2个用户等级，由于3与-2的和值仍大于0，因此确定服务端能够处理该目标业务。假设用户等级低于所述用户降级阈值的差值，两者差值是-4个用户等级，由于3与-4的和值小于0，因此确定服务端无法处理该目标业务。可以理解，本领域技术人员还可以结合实际的业务等级的配置、用户等级的配置、业务特点或决策需要等等灵活配置，本实施例对此不作限定。

第三种，配置信息可以包括用于指示服务端当前对于业务的处理能力信息，客户端可以根据所述业务处理能力信息，确定是否发起所述判断所述服务端是否能够处理所述目标业务之操作。具体的，处理能力信息可以是代表是否需要发起操作的标识，例如以“on”表示服务端当前处理压力较大，需要客户端发起上述业务分级处理的操作，以“off”表示服务端恢复正常，客户端可以停止上述操作。此种方式下，客户端在接收到标识后，根据标识的具体含义确定是否发起后续操作，并可以基于预配置的判断策略，决定处理请求是否发出。

在其他例子中，处理能力信息还可以包括服务端的负载、服务端已调用资源、服务端剩余资源或服务端当前对于业务的可处理等级等等。该配置信息可以由服务端提供给客户端，以供客户端获知服务端当前的处理能力，决定是否发起所述判断所述服务端是否能够处理所述目标业务之操作，在决定发起上述操作，还可以进一步决定哪些处理请求可以发送到服务端、哪些处理请求可以不发送。

实际应用中，可以根据需要预先配置多种判断策略，判断策略也可以作为配置信息中的一种，使客户端能根据业务对应的业务等级与配置信息，快速自动判断所述服务端是否能够处理该业务。举例来说，假设处理能力信息采用服务器负载值表示，处理策略可以是负载值低于某个数值时，表示服务器当前处理能力较好，有较多剩余的处理资源，客户端所有的业务请求都可以处理；负载值在某个较高数值范围时，表示服务器当前处理能力较低，剩余的处理资源不多，客户端可以自动判断出某些重要性较低的业务请求服务端可能无法处理。同理，假设处理能力信息相应采用其他信息表示，例如服务端已调用资源、服务端剩余资源或可处理等级等等，可以相应地设定不同配置信息与业务等级的相关关系，实际应用中本领域技术人员根据应用场景和需要而灵活配置，本实施例对此不作限定。

若结合用户等级进行决策，假设配置信息采用可处理等级表示，判断策略可以是可处理等级较低时，表示服务器当前处理能力较好，有较多剩余的处理资源，客户端所有用户、用户所有的业务请求都可以处理；可处理等级较高时，表示服务器当前处理能力较低，剩余的处理资源不多，客户端可以自动判断出某些重要性较低的用户、某些重要性较低的业务请求服务端可能无法处理，而某些等级较高的用户、等级较高的业务的处理请求则需要处理等等。实际应用中本领域技术人员可以根据应用场景和需要而灵活配置不同处理能力信息与业务等级、用户等级的相关关系，以及判断策略的具体方式，本实施例对此不作限定。

实际应用中，获取配置信息的方式也可以有多种实施方式，例如，可以由服务端预先提供给客户端，也可以是服务端在确定需要降级处理后提供给客户端。由前述分析可知，配置信息中也可以是包括有多类信息，在包括有多类信息的情况下，某类信息可以是预存在客户端本地，客户端从本地存储区域中读取获得，而某类信息可以是在需要的时候通过网络从服务端处获得。其中，从服务端处获得的方式，某些例子中，配置信息可以由服务端根据当前的处理能力自动生成并提供给客户端，在其他例子中，也可以由服务端的管理人员进行配置，通过服务端提供给客户端等等。

当根据判断结果确定服务端能够处理所述业务，客户端可以将所述处理请求发送给服务端，从而获得服务端对于该处理请求的反馈数据；若确定所述服务端无法处理所述业务，客户端可响应于所述处理请求，输出处理失败相关信息，该处理请求不会发送至服务端，从而可以降低服务端在异常情况下的处理压力。在某些例子中，该处理失败信息可以由客户端在电子设备的屏幕上采用可视化的方式进行输出，以提示用户当前的处理请求处理失败，服务端当前无法处理等等。

已有业务处理方案中，可能针对不同的用户或不同的业务，后台服务采用完全隔离的服务器，即不同的服务采用完全隔离的多套服务器集群，但多套服务器集群的情况，其成本太高，需要独立部署两套甚至多套服务器集群。而且随着业务的发展，可能不同业务之间会合并，因此会涉及到数据迁移、接口兼容性等问题，都会带来非常大的成本。而本实施例方案是由客户端决定请求是否发出，服务端无需进行决策，服务端无需配置多套隔离的服务器集群以面向不同业务的处理请求，因此本实施例的服务端可以包括一台服务器或一套服务器集群，从而可以显著减少成本，降低开发难度。

接下来再通过一实施例对本申请所提供的方案进行说明。如图2a所示，是本申请根据一示例性实施例示出的一种客户端与服务端对业务处理的示意图，图2b是本申请根据一示例性实施例示出的另一种业务处理的应用场景示意图。

实际应用中，每个客户端(app)可以根据实际的业务特性，区分出每种业务的被处理时的优先等级，本实施例采用业务等级进行描述。例如可以把业务等级分为10级，数值越低代表重要性越高、等级越高(不同的app可以自定义)。

对于用户，可选择地进行区分。例如当app有付费用户和免费用户的情况下，付费用户可能需要优先处理；当用户有实名认证和非实名认证的情况下，实名认证用户可能需要优先处理。对于用户的区分标准可以根据每个app的实际场景和应用特点而自定义。

设置上述业务等级和用户等级的原则，是假设服务端出现异常，则对于同一个业务，需要保证高等级的用户优先处理，同时对于同一个用户，需要保证高等级的业务优先处理。

服务端可以在数据库中存储相应的业务等级的配置信息和用户等级的配置信息。

服务端存储的业务等级和用户等级的配置信息，数据的变动可能不会很频繁，可以预存在app中，当用户账户首次登录时，app可以从服务端获取，提前预先加载到app本地。

如果后续该信息发生变化，例如用户的等级发生变化(比如该用户由免费用户升级为付费用户)，在所述业务等级和/或所述用户等级需要更新时，通过服务端主动推送的方式获取需更新的业务等级和/或用户等级，并利用新获取的业务等级和/或所述用户等级进行更新，具体的主动推送的方式，可以是长连接或短连接等。

通过上述方式，app可以预先将用户等级、业务等级的数据加载至电子设备中。在服务端的非故障时间，上述处理机制并不会造成多大压力。但当服务端发生故障的时候，可以不从服务端获取这一数据，避免在服务端故障时，因为获取数据而给服务端增加压力。

具体的业务处理流程，可以是用户需要访问业务1，客户端针对业务1组装相应的处理请求后，发送到客户端的网关层(网关层也即是客户端的一个功能模块，用于进行处理策略的判断，决定是否将处理请求发送给服务端)；网关层判断当前服务端有能力处理该业务，则将处理请求发送给服务端，并最终接收到服务端的响应数据，并在设备屏幕上进行展示。

服务端根据需要配置有服务端网关层，用于与客户端通信，接收客户端的处理请求，以及发送相应的响应数据给客户端。业务处理系统用于处理客户端的处理请求，生成处理请求所需的数据。分等级可用性开关模块用于获取或自动生成配置信息(如处理能力信息等)，该配置信息可以由该模块根据服务端的处理能力自动生成，也可以由服务端技术人员根据实际的处理能力而配置，并在需要的时候提供给客户端，以通知客户端是否需要执行相关操作。

其中，该配置信息，实际应用中可以采用多种方式传递至客户端。在某些例子中，服务端的分等级可用性开关模块将处理能力信息提供给服务端网关层，由服务端网关层直接通过长连接主动推送等方式推送给客户端；在其他例子中，还可以是服务端网关层存储在内存中，当需要向客户端发送请求响应数据时，将携带有处理能力信息的请求响应数据发送给客户端。

客户端可以获取到配置信息中的处理能力信息后，之后进行一步获取业务降级阈值或用户降级阈值等，根据预先配置的判断策略，利用业务等级、用户等级或配置信息等，判断服务端是否能够处理业务，并根据判断结果确定是否将所述处理请求发送给所述服务端，如果服务端无法处理该业务，则输出处理失败相关信息。

具体的，本实施例列举几种可选的判断策略，本实施例中用户等级为userlevel，业务等级为bizlevel，配置信息采用可处理等级targetlevel为例，数值越低表示等级越高。

方式一：双高等级保障模式

限制的方法为:userlevel<＝targetlevel并且bizlevel<＝targetlevel

即假设设置的targetlevel为2，那么只有用户等级为1、2的用户可以访问业务等级为1、2的业务。其它的请求客户端不会发送给服务端。

方式二：单等级保障模式

限制的方法为:userlevel<＝targetlevel或者bizlevel<＝targetlevel

即假设设置的targetlevel为2，那么用户等级为1、2的用户可以访问任何业务；业务等级为1、2的业务可以被任何用户访问。其它的请求客户端不会发送给服务端。

方式三：分等级阶梯保障模式

限制的方法为：userlevel+targetlevel<＝targetlevel

即假设设置的targetlevel＝4，那么用户等级1的用户，可以访问业务等级为1、2、3的业务；用户等级为3的用户可以访问业务等级为1的用户。其它的请求客户端不会发送给服务端。

如图3所示，是本申请根据一示例性实施例示出的另一种业务处理方法的流程图，本实施例在图2a所示实施例的基础上，结合了服务端的处理过程进行说明。该方法预先针对不同业务，配置有每种业务对应的业务等级，可以包括如下步骤：

在步骤302中，客户端获取待发送至服务端的针对目标业务的处理请求；

在步骤304中，服务端获取配置信息，并提供给所述客户端；

在步骤306中，客户端根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务；

在步骤308中，客户端根据判断结果确定是否将所述处理请求发送给所述服务端。

可选的，所述服务端获取配置信息，并提供给所述客户端，包括：

所述服务端判断是否需要降级处理，在确定需要降级处理后，获取配置信息，并提供给所述客户端。

可选的，所述方法预先针对不同用户，配置有用户对应的用户等级；

所述方法还包括：

所述客户端确定处理请求发起方对应的用户等级；

所述客户端根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

客户端根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

可选的，所述用户等级根据如下一种或多种信息而确定：

用户是否为付费用户、用户是否为实名认证用户或用户的信用等级。

可选的，所述客户端根据判断结果确定是否将所述处理请求发送给所述服务端，包括：

当所述客户端确定所述服务端能够处理所述业务，将所述处理请求发送给服务端；

当所述客户端确定所述服务端无法处理所述业务，响应于所述处理请求，输出处理失败相关信息。

可选的，所述业务等级和/或所述用户等级在用户账户首次登录时，所述客户端从所述服务端获取。

可选的，在所述业务等级和/或所述用户等级需要更新时，所述服务端主动推送需更新的业务等级和/或用户等级给所述客户端，所述客户端利用新获取的业务等级和/或所述用户等级进行更新。

可选的，所述服务端获取配置信息，并提供给所述客户端，包括：

所述服务端获取配置信息，并主动推送给所述客户端；或，

所述服务端发送携带有所述配置信息的请求响应数据给所述客户端。

可选的，所述服务端包括一台服务器或一套服务器集群。

可选的，所述配置信息包括业务降级阈值；

所述根据所述目标业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息还包括用户降级阈值；

所述根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

比较所述业务等级与所述业务降级阈值、比较所述用户等级与所述用户降级阈值，根据比较结果判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息包括用于指示服务端当前对于业务的处理能力信息；

在所述比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务前，所述方法包括：

根据所述处理能力信息确定所述业务降级阈值或用户降级阈值。

本实施例的详细内容可参考前述图2a所示实施例的描述，再次不再赘述。

与前述业务处理方法的实施例相对应，本申请还提供了业务处理装置、系统及其所应用的电子设备的实施例。

如图4所示，图4是本申请根据一示例性实施例示出的一种业务处理装置的框图，所述装置包括：

请求获取模块41，用于：获取待发送至服务端的针对目标业务的处理请求；

配置模块42，用于：获取配置信息；

判断模块43，用于：根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务；

请求阻挡模块44，用于：根据判断结果确定是否将所述处理请求发送给所述服务端。

可选的，所述装置预先针对不同用户，配置有用户对应的用户等级；

所述装置还包括：

用户等级确定模块，用于：确定处理请求发起方对应的用户等级；

所述判断模块，还用于：

根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

可选的，所述用户等级根据如下一种或多种信息而确定：

用户是否为付费用户、用户是否为实名认证用户或用户的信用等级。

可选的，所述请求阻挡模块，还用于：

当确定所述服务端能够处理所述业务，将所述处理请求发送给服务端；

当确定所述服务端无法处理所述业务，响应于所述处理请求，输出处理失败相关信息。

可选的，所述业务等级和/或所述用户等级在用户账户首次登录时，从所述服务端获取。

可选的，在所述业务等级和/或所述用户等级需要更新时，通过服务端主动推送的方式获取需更新的业务等级和/或用户等级，并利用新获取的业务等级和/或所述用户等级进行更新。

可选的，所述配置模块，还用于：

通过所述服务端主动推送的方式获取所述配置信息；或，

获取携带有所述配置信息的请求响应数据，通过所述请求响应数据获得所述配置信息。

可选的，所述服务端包括一台服务器或一套服务器集群。

可选的，所述配置信息包括业务降级阈值；

所述判断模块，还用于：

比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息还包括用户降级阈值；

所述判断模块，还用于：

比较所述业务等级与所述业务降级阈值、比较所述用户等级与所述用户降级阈值，根据比较结果判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息包括用于指示服务端当前对于业务的处理能力信息；

所述判断模块，还用于：

根据所述处理能力信息确定所述业务降级阈值或用户降级阈值。

相应的，本申请实施例还提供一种业务处理系统，预先针对不同业务，配置有每种业务对应的业务等级，所述系统包括客户端和服务端；

所述客户端用于获取待发送至服务端的针对目标业务的处理请求；

所述服务端用于获取配置信息，并提供给所述客户端；

所述客户端用于根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务；

所述客户端用于根据判断结果确定是否将所述处理请求发送给所述服务端。

可选的，所述系统预先针对不同用户，配置有用户对应的用户等级；

所述客户端还用于确定处理请求发起方对应的用户等级；

所述客户端用于根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务，包括：

所述客户端用于根据所述业务等级、所述用户等级与所述配置信息，判断所述服务端是否能够处理所述目标业务。

可选的，所述服务端具体用于：判断是否需要降级处理，在确定需要降级处理后，获取配置信息，并提供给所述客户端。

可选的，所述用户等级根据如下一种或多种信息而确定：

用户是否为付费用户、用户是否为实名认证用户或用户的信用等级。

可选的，所述客户端用于根据判断结果确定是否将所述处理请求发送给所述服务端，包括：

当所述客户端确定所述服务端能够处理所述业务，将所述处理请求发送给服务端；

当所述客户端确定所述服务端无法处理所述业务，响应于所述处理请求，输出处理失败相关信息。

可选的，所述业务等级和/或所述用户等级在用户账户首次登录时，所述客户端从所述服务端获取。

可选的，在所述业务等级和/或所述用户等级需要更新时，所述服务端主动推送需更新的业务等级和/或用户等级给所述客户端，所述客户端利用新获取的业务等级和/或所述用户等级进行更新。

可选的，所述服务端用于获取配置信息，并提供给所述客户端，包括：

所述服务端用于获取配置信息，并主动推送给所述客户端；或，

所述服务端用于发送携带有所述配置信息的请求响应数据给所述客户端。

可选的，所述服务端包括一台服务器或一套服务器集群。

可选的，所述配置信息包括业务降级阈值；

所述客户端还用于：

比较所述业务等级与所述业务降级阈值，判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息还包括用户降级阈值；

所述客户端还用于：

比较所述业务等级与所述业务降级阈值、比较所述用户等级与所述用户降级阈值，根据比较结果判断所述服务端是否能够处理所述目标业务。

可选的，所述配置信息包括用于指示服务端当前对于业务的处理能力信息；

所述客户端还用于：

根据所述处理能力信息确定所述业务降级阈值或用户降级阈值。

相应的，本申请实施例还提供一种电子设备，包括：

处理器；

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

其中，所述处理器被配置为：

获取待发送至服务端的针对目标业务的处理请求；

获取配置信息；

根据所述业务对应的业务等级与所述配置信息，判断所述服务端是否能够处理所述目标业务；

根据判断结果确定是否将所述处理请求发送给所述服务端。

本申请业务处理装置的实施例可以应用在电子设备上，例如个人计算机、智能手机等等。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在文件处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请业务处理装置所在电子设备的一种硬件结构图，除了图5所示的处理器510、内存530、网络接口520、以及非易失性存储器540之外，实施例中装置531所在的电子设备，通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

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

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。