一种业务请求的处理方法及装置

技术领域

本发明涉及金融科技(Fintech)领域，尤其涉及一种业务请求的处理方法及装置。

背景技术

随着计算机技术的发展，越来越多的技术(例如：区块链、云计算或大数据)应用在金融领域，传统金融业正在逐步向金融科技转变，大数据技术也不例外，但由于金融、支付行业的安全性、实时性要求，也对大数据技术中业务请求的处理提出了更高的要求。

现有技术中，拦截器组件用于对业务请求进行拦截处理，如对业务请求的网络地址验证、拦截未登录用户和审计日志等。具体的，任一业务活动的拦截器组件配置由用户自定义配置，针对业务活动中的业务请求，调用拦截器组件，对业务请求进行拦截。

目前，任一业务活动的多个拦截器组件对于业务请求来说，均是串行调用，例如，购物活动中的交易请求，包括两个安全拦截器组件A和B，对交易请求进行安全拦截和一个支付拦截器组件C提供支付通道，拦截器组件调用顺序为A，B，C。

然而，上述技术方案中，对于支付拦截器组件C来说，需要在安全拦截器组件A和B调用完成，且业务请求通过后，再进行调用，保证支付安全。但对于安全拦截器组件A和B来说，用于验证业务请求的安全性，可以不需要考虑调用顺序，即不需要进行串行调用，可以对拦截器组件A和B并行调用，串行调用会导致拦截器组件的调用时间长，使业务处理请求时间长，效率低。

因此，现需要一种拦截器组件调用方法，减小拦截器组件调用时间，从而缩短对业务请求的拦截时间，提升业务请求处理的效率。

发明内容

本发明实施例提供一种业务请求的处理方法及装置，用于减小拦截器组件调用时间，从而缩短对业务请求的拦截时间，提升业务请求处理的效率。

第一方面，本发明实施例提供业务请求的处理方法，包括：

业务系统接收业务请求；

所述业务系统根据所述业务请求中的设定因素，确定所述业务请求的业务保护条件；所述业务保护条件用于确保业务请求的执行响应满足设定要求；

所述业务系统根据历史业务请求执行状况判断所述业务请求是否满足所述业务保护条件；若满足，则获取拦截器任务层级链；所述拦截器任务层级链是针对所述业务系统中的所有拦截器组件按照执行顺序划分为不同层级，且同一层级中的各拦截器组件之间无依赖关系；

所述业务系统按照所述拦截器任务层级链，依次调用各层级的拦截器组件，确定所述业务请求是否需要被拦截；

所述业务系统在所述业务请求未被所述拦截器任务层级链中的各拦截器组件拦截后，执行所述业务请求的业务逻辑。

上述技术方案中，拦截器任务层级链包括多个层级，重要的是，同一层级之间的各拦截器组件之间无依赖关系，也就是说，同一层级的各拦截器组件可以并发调用，以此减小拦截器组件调用时间，从而缩短对业务请求的拦截时间，提升业务请求处理的效率，并且，通过拦截器任务层级链具有可配置化、组件化和移植化的性能，便于业务系统的使用。

本发明中的历史业务请求执行状况，用于实时的确定业务请求的处理状况，即成功与否，以便用户实时知悉，提升用户的业务请求体验。通过设定因素和业务保护条件，对业务请求进行资源保护，具体的，在业务请求满足业务保护条件时，则确定所述业务请求资源保护通过，即允许执行所述业务请求，以此提升了对业务请求处理的安全性，其中，历史业务请求执行状况是根据该任务请求之前的所有业务请求确定的，即不包括该业务请求的执行状况。

可选的，所述业务请求中的设定因素包括以下至少一项：接口、商户和渠道；

所述业务保护条件包括以下至少一项：请求响应时间超过时间阈值；业务请求的滑动窗口失败率超过失败率阈值；业务请求的数量超过请求数阈值。

上述技术方案中，设定因素包括接口、商户和渠道，因为现有技术中仅是通过接口对业务请求进行资源保护，而本申请还对商户和渠道进行资源保护，实现在商户和渠道上差异化的资源保护，以此细化对业务请求保护的粒度性。

可选的，业务请求若满足所述业务保护条件，则获取拦截器任务层级链，包括：

所述业务系统判断所述业务请求是否超过请求数阈值；若否，则获取所述拦截器任务层级链；

若是，则确定所述业务请求的滑动窗口失败率，并在确定所述业务请求的响应时间未超过时间阈值和所述业务请求的滑动窗口失败率未超过失败率阈值时，获取所述拦截器任务层级链。

上述技术方案中，通过请求数阈值来防止因业务请求的数量过少，导致的滑动窗口失败率过大问题，避免业务系统错误的确定业务请求的执行状况，通过业务请求的滑动窗口失败率和时间阈值来确定当前业务请求是否过于拥挤，防止业务系统雪崩。

可选的，确定所述业务请求的滑动窗口失败率，包括：

所述业务系统基于所述业务请求时刻的滑动窗口，确定所述滑动窗口中各小窗口的业务请求失败率；

将所述各小窗口的业务请求失败率的和确定为所述业务请求的滑动窗口失败率。

上述技术方案中，滑动窗口也就是业务请求时刻的时间窗口，确定滑动的时间窗口内的失败率，用于提升对时间窗口内失败率的准确性，即提升对当前业务请求判断的准确性。

可选的，所述方法还包括：

所述业务系统根据历史业务请求执行状况确定所述业务请求未满足所述业务保护条件时，收集所述业务请求的异常执行状况，更新所述历史业务请求执行状况；所述异常执行情况包括所述业务请求的响应时间超过时间阈值和所述业务请求的滑动窗口失败率超过失败率阈值；

所述业务系统根据所述异常执行状况对所述设定因素确定限流策略；所述限流策略包括预设限流算法。

上述技术方案中，在业务请求为满足业务保护条件时，证明当前的业务请求过于拥挤，需要通过一定的策略来降低业务请求的数量，通过业务请求的异常执行状况，自动确定对应的限流策略，并执行，以实现限流的自动化性，且限流策略是针对设定因素中的接口、商户和渠道，以此细化对业务请求保护的粒度性。

可选的，执行所述业务请求的业务逻辑之前，还包括：

所述业务系统根据所述业务请求的类型，根据执行所述业务请求的接口确定所述业务请求是否满足隔离条件；所述接口中预设有否进行线程资源隔离的方法；

若满足，则对所述业务请求的线程资源进行隔离。

上述技术方案中，通过业务请求的类型确定执行业务请求的接口，接口中预设线程资源隔离方法或非线程资源隔离方法，通过确定执行业务请求的接口来确定所述业务请求是否需要进行线程资源隔离，实现对业务请求的差异化，即业务请求的重要程度区分，避免重要的业务请求执行失败或者延迟。

可选的，所述拦截器任务层级链通过如下方式获得，包括：

所述业务系统在启动后，获取具有注解的各拦截器组件；

所述业务系统根据各拦截器组件之间的依赖关系，构建有向无环图；

所述业务系统根据所述有向无环图，确定所述拦截器任务层级链。

上述技术方案中，通过注解确定各拦截器组件之间的关联关系，即针对任一拦截器组件，确定与该拦截器组件具有依赖关系的其他拦截器组件，以此可以构建出有向无环图，然后根据有向无环图的方向确定拦截器任务层级链，进而确定出无依赖关系的各层级拦截器组件，以便实现并行调用拦截器组件，减小拦截器组件调用时间。

可选的，所述业务系统按照所述拦截器任务层级链，依次调用各层级的拦截器组件，包括：

针对任一待调用层级的拦截器组件，确定所述待调用层级的前一层级的拦截器组件是否调用完成；所述前一层级是所述拦截器任务层级链中与所述待调用层级相邻的前一层；

若是，则并行调用所述待调用层级中的拦截器组件；

确定所述待调用层级是否具有后一层级的拦截器组件；所述后一层级是所述拦截器任务层级链中与所述待调用层级相邻的后一层；

若具有，则更新所述待调用层级为所述后一层级。

上述技术方案中，通过层级来调用拦截器组件，既保证拦截器组件的在调用顺序上的前后依赖性，又可以减小拦截器组件调用时间，从而缩短对业务请求的拦截时间，提升业务请求处理的效率。

第二方面，本发明实施例提供一种业务请求的处理装置，包括：

接收模块，用于接收业务请求；

处理模块，用于根据所述业务请求中的设定因素，确定所述业务请求的业务保护条件；所述业务保护条件用于确保业务请求的执行响应满足设定要求；

根据历史业务请求执行状况判断所述业务请求是否满足所述业务保护条件；若满足，则获取拦截器任务层级链；所述拦截器任务层级链是针对所述业务系统中的所有拦截器组件按照执行顺序划分为不同层级，且同一层级中的各拦截器组件之间无依赖关系；

按照所述拦截器任务层级链，依次调用各层级的拦截器组件，确定所述业务请求是否需要被拦截；

在所述业务请求未被所述拦截器任务层级链中的各拦截器组件拦截后，执行所述业务请求的业务逻辑。

可选的，所述业务请求中的设定因素包括以下至少一项：接口、商户和渠道；

所述业务保护条件包括以下至少一项：请求响应时间超过时间阈值；业务请求的滑动窗口失败率超过失败率阈值；业务请求的数量超过请求数阈值。

可选的，所述处理模块具体用于：

判断所述业务请求是否超过请求数阈值；若否，则获取所述拦截器任务层级链；

若是，则确定所述业务请求的滑动窗口失败率，并在确定所述业务请求的响应时间未超过时间阈值和所述业务请求的滑动窗口失败率未超过失败率阈值时，获取所述拦截器任务层级链。

可选的，所述处理模块具体用于：

基于所述业务请求时刻的滑动窗口，确定所述滑动窗口中各小窗口的业务请求失败率；

将所述各小窗口的业务请求失败率的和确定为所述业务请求的滑动窗口失败率。

可选的，所述处理模块还用于：

根据历史业务请求执行状况确定所述业务请求未满足所述业务保护条件时，收集所述业务请求的异常执行状况，更新所述历史业务请求执行状况；所述异常执行情况包括所述业务请求的响应时间超过时间阈值和所述业务请求的滑动窗口失败率超过失败率阈值；

根据所述异常执行状况对所述设定因素确定限流策略；所述限流策略包括预设限流算法。

可选的，所述处理模块还用于：

执行所述业务请求的业务逻辑之前，根据所述业务请求的类型，根据执行所述业务请求的接口确定所述业务请求是否满足隔离条件；所述接口中预设有否进行线程资源隔离的方法；

若满足，则对所述业务请求的线程资源进行隔离。

可选的，所述处理模块具体用于：

获取具有注解的各拦截器组件；

根据各拦截器组件之间的依赖关系，构建有向无环图；

根据所述有向无环图，确定所述拦截器任务层级链。

可选的，所述处理模块具体用于：

针对任一待调用层级的拦截器组件，确定所述待调用层级的前一层级的拦截器组件是否调用完成；所述前一层级是所述拦截器任务层级链中与所述待调用层级相邻的前一层；

若是，则并行调用所述待调用层级中的拦截器组件；

确定所述待调用层级是否具有后一层级的拦截器组件；所述后一层级是所述拦截器任务层级链中与所述待调用层级相邻的后一层；

若具有，则更新所述待调用层级为所述后一层级。

第三方面，本发明实施例还提供一种计算机设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述业务请求的处理方法。

第四方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行上述业务请求的处理方法。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种系统架构示意图；

图2为本发明实施例提供的一种业务请求的处理方法的流程示意图；

图3为本发明实施例提供的一种固定窗口的示意图；

图4为本发明实施例提供的一种滑动窗口的示意图；

图5为本发明实施例提供的一种令牌桶算法的示意图；

图6为本发明实施例提供的一种判断流程的示意图；

图7为本发明实施例提供的一种有向无环图的示意图；

图8为本发明实施例提供的一种查找异常注册表的示意图；

图9为本发明实施例提供的一种业务请求的处理装置的结构示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

现有技术中，对于业务活动配置的多个拦截器组件均是串行调用，然而，在某种业务活动中，存在多个拦截器组件之间无依赖关系，如，不同的安全性验证手段不同(拦截器组件A用于验证业务请求的网络地址是否是公开的，拦截器组件B用于验证业务请求的网络地址是否是合法的等)，针对不同的安全性验证，所调用的拦截器组件不同，但拦截器组件A与拦截器组件B之间不存在业务依赖关系，即无需考虑拦截器组件A与拦截器组件B的调用顺序，不需要进行串行调用，可以对两个拦截器并行调用。

同理，对于某些拦截器组件来说，存在依赖关系，如业务请求为支付请求，需要先对支付请求进行安全性验证(拦截器组件A和拦截器组件B)，再对支付请求进行支付密码是否正确进行验证(拦截器组件C用于验证支付请求的支付密码是否正确)，则拦截器组件C与拦截器组件A和拦截器组件B存在依赖关系，即存在调用先后关系，进一步地，需要先调用拦截器组件A和拦截器组件B，再调用拦截器组件C。

因此，现需要一种业务请求处理中拦截器组件调用方法，减小拦截器组件调用时间，从而缩短对业务请求的拦截时间，提升业务请求处理的效率。

图1示例性的示出了本发明实施例所适用的一种系统架构，该系统架构包括客户端110、拦截调度器120、资源保护器130、拦截注册器140、配置管理器150、状态收集器160和异常调度器170。

其中，客户端110用于发送业务请求，客户端110可以为终端(如手机、笔记本等)、服务器等，在此不做具体限定。

拦截调度器120，用于将业务请求发送至资源保护器130，在资源保护器确定所述业务请求满足业务保护条件后，请求拦截注册器140，在拦截注册器140中调用拦截器任务层级链，然后按照拦截器任务层级链，依次调用各层级的拦截器组件，并在业务请求未被拦截器任务层级链中的各拦截器组件拦截后，执行业务请求的业务逻辑。

资源保护器130，用于根据业务请求历史执行状况判断业务请求是否满足业务保护条件。

拦截注册器140，用于根据具有注解的各拦截器组件，构建有向无环图，确定拦截器任务层级链，得到各拦截器组件之间的依赖关系。

配置管理器150，用于向资源保护器提供设定因素，包括接口、商户和渠道的时间阈值、失败率阈值和请求数阈值。

状态收集器160，用于确定业务请求历史执行状况，包括请求响应时间、业务请求的滑动窗口失败率和业务请求的数量。

异常调度器170，用于确定执行失败的业务请求的异常原因，并将异常原因返回值客户端110。

需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。

基于上述描述，图2示例性的示出了本发明实施例提供的一种业务请求的处理方法的流程示意图，该流程可由业务请求的处理装置执行。

如图2所示，该流程具体包括：

步骤210，业务系统接收业务请求。

本发明实施例中，业务请求针对的是某一业务活动的业务请求，如购物活动的支付请求、使用网页或APP的登录请求等。

步骤220，所述业务系统根据所述业务请求中的设定因素，确定所述业务请求的业务保护条件。

本发明实施例中，业务保护条件用于确保业务请求的执行响应满足设定要求。

步骤230，所述业务系统根据历史业务请求执行状况判断所述业务请求是否满足所述业务保护条件；若满足，则获取拦截器任务层级链。

本发明实施例中，所述拦截器任务层级链是针对所述业务系统中的所有拦截器组件按照执行顺序划分为不同层级，且同一层级中的各拦截器组件之间无依赖关系。

步骤240，所述业务系统按照所述拦截器任务层级链，依次调用各层级的拦截器组件，确定所述业务请求是否需要被拦截。

本发明实施例中，对于拦截器组件的调用，是根据拦截器任务层级链的层级顺序确定的。

步骤250，所述业务系统在所述业务请求未被所述拦截器任务层级链中的各拦截器组件拦截后，执行所述业务请求的业务逻辑。

本发明实施例中，业务请求未被拦截器任务层级链中的各拦截器组件拦截，证明业务请求验证通过，允许执行业务请求的业务逻辑。

在步骤220中，在接收业务请求之后，需要对业务请求进行资源保护判断，具体的，业务系统根据业务请求中的设定因素，确定业务请求的业务保护条件；其中，业务保护条件用于确保业务请求的执行响应满足设定要求。

本发明实施例中，设定因素，包括接口、商户和渠道，也就是说，针对于不同的设定因素，可以设置不同的保护条件，并不局限于针对不同的接口设置对应的保护条件。

在步骤230中，历史业务请求执行状况指的是当前业务请求时刻的滑动窗口失败率，相当于针对业务请求时刻，该时刻的滑动时间窗口的失败率，以及历史业务请求数量，以使业务系统确定出当前业务请求的数量。如历史业务请求数量为50，则当前业务请求为第51个业务请求。

其中，业务保护条件包括以下至少一项：请求响应时间超过时间阈值；业务请求的滑动窗口失败率超过失败率阈值；业务请求的数量超过请求数阈值。

具体的，业务系统判断业务请求是否超过请求数阈值；若否，则获取拦截器任务层级链；若是，则确定业务请求的滑动窗口失败率，并在确定业务请求的响应时间未超过时间阈值和业务请求的滑动窗口失败率未超过失败率阈值时，获取拦截器任务层级链。

在本发明实施例中，请求数阈值用于防止业务系统在冷启动阶段，因业务请求的数量小，导致在计算滑动窗口失败率或请求响应时间时，基数小而发生的滑动窗口失败率过大，或请求响应时间过长，例如，当业务请求的数量为10时，若其中出现一次业务请求失败，则滑动窗口失败率为10％，若业务请求的数量为100时，若其中出现两次业务请求失败，则滑动窗口失败率为2％。需要说明的是，冷启动指的是重新启动。

因此，在本发明实施例中，在业务请求量未超过请求数阈值时，则确定业务请求满足业务保护条件。

在一种可实施的方式中，窗口失败率可以使用固定窗口来确定，图3示例性的示出了一种固定窗口的示意图，如图3所示，假设失败率阈值为1分钟内1％，固定窗口的时间为1分钟，则在固定窗口的1分钟内，确定固定窗口失败率。

但是，固定窗口存在容错缺点，例如，两个相邻固定窗口，第一固定窗口内请求量为1000次，前59s失败0次，最后1s失败次数为9次，则第一固定窗口失败率为0.9％，第二固定窗口内请求量为1000次，前1s失败次数为8次，后59s失败0次，则第二固定窗口失败率为0.8％。从而可以确定出，第一固定窗口的末尾时刻和第二固定窗口的初始时刻易出现实际超过失败率阈值，易导致系统雪崩的情况。

在本发明实施例中，窗口失败率通过滑动窗口来确定，具体的，业务系统基于业务请求时刻的滑动窗口，确定滑动窗口中各小窗口的业务请求失败率；将各小窗口的业务请求失败率的和确定为所述业务请求的滑动窗口失败率。

举例来说，图4示例性的示出了一种滑动窗口的示意图，如图4所示，将滑动窗口时段划分为多个小窗口时段，以小窗口时段的向下一时刻滑动，针对任一时刻，根据多个小窗口时段内的业务请求总数量和业务请求失败数，确定业务请求的滑动窗口失败率。

举例来说，滑动窗口的时间为1分钟，将滑动窗口细分为6各小窗口，每个小窗口10秒，以上述图3实例为基础，假设在第一滑动窗口最后的小窗口(相当于第一固定窗口的最后10秒)失败率为0.9％，第二滑动窗口最后的小窗口失败率为0.8％，则第二滑动窗口失败率为1.7％，以此可以避免上述固定窗口出现的问题，提升确定窗口失败率是否超过失败率阈值的准确性。

在另一种可实施的方式中，针对于滑动窗口，还可以将滑动窗口的QPS(Query PerSecond，每秒查询率)来作为业务保护条件，如滑动窗口的QPS小于查询阈值，在此不做过多的限定。

在本发明实施例中在确定业务请求不满足业务保护条件时，根据预设的限流算法对业务请求进行限流，以此实现资源保护。

具体的，业务系统根据历史业务请求执行状况确定业务请求未满足业务保护条件时，收集业务请求的异常执行状况，更新历史业务请求执行状况；异常执行情况包括业务请求的响应时间超过时间阈值和业务请求的滑动窗口失败率超过失败率阈值；根据异常执行状况对设定因素确定限流策略；其中，限流策略包括预设限流算法。

例如，限流算法为令牌桶算法、计数器算法、滑动窗口算法和漏桶算法等，在此不做具体限定。

以令牌桶算法为例，图5示例性的示出了一种令牌桶算法的示意图，如图5所示，按照预设限流参数的QPS生成令牌到令牌桶内，业务系统在接收到业务请求之后，在令牌桶内获取业务请求的令牌，若获取成功，则执行业务请求的业务逻辑，否则，不对所述业务请求进行处理。

以滑动窗口算法为例，可以通过增加或减少滑动窗口中的小窗口数量来对设定因素进行限流，即改变了历史业务请求执行状况，以此来确定业务请求是否需要进行限流。

对于业务请求的请求响应时间，在业务请求的请求响应时间未超过时间阈值时，继续确定当前业务请求时间的滑动窗口失败率是否超过失败率阈值，若未超过，则确定业务请求满足业务保护条件。

在另一种可实施的方式中，对于业务请求的资源保护，也可以不使用业务保护条件，可以直接根据预设的限流算法对业务请求进行资源保护，如上述令牌桶算法，在此不做具体限定。

为了更好的阐述上述业务保护条件的技术方案，图6示例性的示出了一种判断流程的示意图，如图6所示，包括：

步骤610，接收业务请求。

步骤620，判断业务请求是否超过请求数阈值，若是，则执行步骤630，否则执行步骤650。

例如，请求数阈值为100，当前业务请求数为50，即该业务请求为第50个业务请求，则确定该业务请求未超过请求数阈值。

步骤630，判断业务请求是否超过时间阈值，若是，则执行步骤660，否则执行步骤640。

在确定当前业务请求数超过请求数阈值后，确定该业务请求的请求响应时间是否超过了时间阈值，例如该业务请求的请求响应时间为50毫秒，时间阈值为1秒。则该业务请求的请求响应时间未超过时间阈值。

步骤640，判断业务请求是否超过失败率阈值，若是，则执行步骤660，否则执行步骤650。

在确定当前业务请求数未超过时间阈值后，确定该业务请求当前时间的滑动窗口失败率是否超过了失败率阈值，例如，该业务请求当前时间的滑动窗口失败率为1.7％，失败率阈值为1％。则该业务请求的滑动窗口失败率超过了失败率阈值。

步骤650，获取拦截器任务层级链。

步骤660，限流保护。

确定预设的限流策略，即预设的限流算法，进行资源保护。

本发明实施例中，时间阈值、失败率阈值和请求数阈值可以是程序员根据经验预设的值，如时间阈值1秒，失败率阈值为1％，请求数阈值为100等。

针对于设定因素，包括接口、商户和渠道，也就是说，针对于不同的设定因素，可以设置不同的时间阈值、失败率阈值和请求数阈值，以下述表1进行举例。

表1

有上述表1可以看出，对于不同接口、商户和渠道的业务请求，其对应的业务保护条件不同，在业务请求未满足业务保护条件时，执行限流策略(令牌桶算法)。

需要说明的是，针对不同的设定因素，限流策略中的限流值可以是不同的，结合上述表1进行举例，针对“接口C1+商户M1+渠道D1”的令牌桶限流算法的限流值为“QPS＝300”，针对“接口C2+商户M2+渠道D2”的令牌桶限流算法的限流值为“QPS＝100”。

针对同一设定因素，不同的异常执行状况可以触发不同的限流策略，结合上述表1进行举例，针对“接口C1+商户M1+渠道D1”，若针对时间阈值未满足业务保护条件时，则执行限流值为“QPS＝200”的令牌桶限流算法。若针对失败率阈值未满足业务保护条件时，则执行限流值为“QPS＝400”的令牌桶限流算法。

在步骤230中，拦截器任务层级链是根据各拦截器组件中预设的注解确定的，具体的，业务系统在启动后，获取具有注解的各拦截器组件，根据各拦截器组件之间的依赖关系，构建有向无环图；根据有向无环图，确定拦截器任务层级链。

进一步地，针对任一拦截器组件的注解，在调用顺序关系上确定与拦截器组件相邻的上一拦截器组件和下一拦截器组件，即与拦截器组件具有依赖关系的其他拦截器组件，得到各拦截器的有向无环图；有向无环图用于表征各拦截器的调用顺序和各拦截器之间的依赖关系。

举例说明，图7示例性的示出了一种有向无环图的示意图，如图7所示，拦截器组件包括拦截器组件A、拦截器组件B、拦截器组件C和拦截器组件D，各拦截器组件的依赖关系分别为，A→B，A→C，A→D，B→D，C→D，由此可以确定，拦截器组件A为第一层级，拦截器组件B和C为第二层级，拦截器组件D为第三层级，其中，后一层的拦截器组件对相邻的前一层的拦截器组件具有依赖关系(如拦截器组件B对拦截器组件A具有依赖关系)，同一层级的拦截器组件之间不具有依赖关系(如拦截器组件B对拦截器组件C不具有依赖关系)，由此可以确定出拦截器任务层级链，拦截器任务层级链可以体现为levelList[0]＝{A},levelList[1]＝{B,C},levelList[2]＝{D}。

在步骤240中，在调用拦截器任务层级链中的各拦截器组件时，是根据拦截器任务层级链层级确定的，具体的针对任一待调用层级的拦截器组件，业务系统确定待调用层级的前一层级的拦截器组件是否调用完成；前一层级是所述拦截器任务层级链中与所述待调用层级相邻的前一层；若是，则并行调用所述待调用层级中的拦截器组件；

业务系统确定待调用层级是否具有后一层级的拦截器组件；后一层级是拦截器任务层级链中与所述待调用层级相邻的后一层；若具有，则更新所述待调用层级为所述后一层级。

以上述图7进行举例，首先将首顺序的层级(第一层级)确定为待调用层级，然后确定第一层级的前一层级拦截器是否调用完成，因为第一层级没有前一层级，因此，默认为第一层级的前一层级拦截器调用完成，然后在确定第一层级是否具有后一层级(第二层级)，在确定有第二层级后，将第二层级更新为待调用层级，然后确定第二层级的上一层极(第一层级)中各拦截器组件是否调用完成，若是，则并行调用第二层级中的各拦截器组件。

在第二层级中的各拦截器组件调用完成后，确定第二层级是否具有后一层级(第三层级)，直至确定待调用层级不具有后一层极。

针对任一层级的各拦截器组件，在调用时，并行调用，如对于第二层级的拦截器组件B和拦截器组件C，在调用时，并行调用拦截器组件B和拦截器组件C，实现减小拦截器组件调用时间，从而缩短对业务请求的拦截时间，提升业务请求处理的效率。

需要说明的是，在确定拦截器组件是否调用完成时，在一种可实施的方式中，可以在拦截器组件调用完成后，在拦截器任务层级链中对该拦截器组件打上标签，用于表征以调用完成。

在本发明实施例中，针对任一拦截器组件，在拦截器组件调用完成后，将该拦截器组件在拦截器任务层级链中移除，在任一层级中，若层级中无拦截器组件，则表征该层级以调用完成。

在步骤250中，执行业务请求的业务逻辑之前，还需要确定业务请求的类型，以此判断是否对业务请求进行资源隔离。

具体的，业务系统根据所述业务请求的类型，确定所述业务请求是否满足隔离条件，若满足，则对所述业务请求的线程资源进行隔离。

进一步地，业务系统根据所述业务请求的类型，确定执行所述业务请求的接口；所述接口中预设有否进行线程资源隔离的方法。

本发明实施例中，业务请求的类型可以包括支付请求、查询请求、登陆请求等，在此不做限定。

以支付请求为例，在业务请求为查询请求时，确定执行支付请求的接口为第二接口，第二接口中设有非线程资源隔离方法。在业务请求为支付请求时，确定执行支付请求的接口为第一接口，第一接口中设有线程资源隔离方法，以此实现对支付请求的资源隔离。

在执行业务请求的业务逻辑时，若发生执行异常，则通过异常调取器查找预设的异常注册表，图8示例性的示出了一种查找异常注册表的示意图，如图8所示，异常注册表中存储有预设的异常原因(如响应超时，支付失败等)，在查找到对应的异常原因后，则将异常原因反馈至客户端，是客户端知悉异常原因，在为查找到对应的异常原因时，则业务系统发出告警信息，以使程序员处理该异常，并向客户端反馈预设信息。

基于相同的技术构思，图9示例性的示出了本发明实施例提供的一种业务请求的处理装置的结构示意图，该装置可以执行业务请求的处理方法的流程。

如图9所示，该装置具体包括：

接收模块910，用于接收业务请求；

处理模块920，用于在所述业务请求需调用拦截器组件时，获取拦截器任务层级链；所述拦截器任务层级链是针对所述业务系统中的所有拦截器组件按照执行顺序划分为不同层级，且同一层级中的各拦截器组件之间无依赖关系；

按照所述拦截器任务层级链，依次调用各层级的拦截器组件，确定所述业务请求是否需要被拦截；

在所述业务请求未被所述拦截器任务层级链中的各拦截器组件拦截后，执行所述业务请求的业务逻辑。

可选的，所述处理模块920还用于：

执行所述业务请求的业务逻辑之后，收集所述业务请求的执行状况；

接收业务请求之后，获取拦截器任务层级链之前，根据所述业务请求中的设定因素，确定所述业务请求的业务保护条件；所述业务保护条件用于确保业务请求的执行响应满足设定要求；

根据业务请求历史执行状况判断所述业务请求是否满足所述业务保护条件；

若满足，则获取拦截器任务层级链。

可选的，所述业务请求中的设定因素包括以下至少一项：接口、商户和渠道；

所述业务保护条件包括以下至少一项：请求响应时间超过时间阈值；业务请求的滑动窗口失败率超过失败率阈值；业务请求的数量超过请求数阈值。

可选的，所述处理模块920还用于：

执行所述业务请求的业务逻辑之前，根据所述业务请求的类型，确定所述业务请求是否满足隔离条件，若满足，则对所述业务请求的线程资源进行隔离。

可选的，所述处理模块920具体用于：

根据所述业务请求的类型，确定执行所述业务请求的接口；所述接口中预设有否进行线程资源隔离的方法。

可选的，所述处理模块920具体用于：

获取具有注解的各拦截器组件；

根据各拦截器组件之间的依赖关系，构建有向无环图；

根据所述有向无环图，确定所述拦截器任务层级链。

可选的，所述处理模块920具体用于：

针对任一待调用层级的拦截器组件，确定所述待调用层级的前一层级的拦截器组件是否调用完成；所述前一层级是所述拦截器任务层级链中与所述待调用层级相邻的前一层；

若是，则并行调用所述待调用层级中的拦截器组件；

确定所述待调用层级是否具有后一层级的拦截器组件；所述后一层级是所述拦截器任务层级链中与所述待调用层级相邻的后一层；

若具有，则更新所述待调用层级为所述后一层级。

基于相同的技术构思，本发明实施例还提供一种计算机设备，包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行上述业务请求的处理方法。

基于相同的技术构思，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使计算机执行上述业务请求的处理方法。

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

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

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

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

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。