CN105589748A - 一种业务请求处理方法及装置 - Google Patents

Abstract

本申请涉及计算机技术领域，尤其涉及一种业务请求处理方法及装置，用以解决现有技术中执行业务请求的处理时长较长，CPU利用率较低的问题。本申请实施例提供的一种业务请求处理方法包括：获取接收的业务请求的拓扑结构信息；所述拓扑结构信息包括所述业务请求对应的各个业务环节之间的依赖关系信息；根据所述业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的业务环节集合；其中，所述拓扑结构信息包括执行所述业务请求时需要执行的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节；并行执行确定的所述业务环节集合中的各业务环节。

Description

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

技术领域

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

背景技术

随着网络技术的发展，用户通过网络获取各种业务请求的需求越来越多。同一业务请求通常包括多个业务环节，各个业务环节之间有的相互之间具有依赖关系，有的则不具有依赖关系。

目前，针对需要执行多个业务环节的业务请求，为了保证各业务环节执行逻辑上的顺序关系，一般都采用单线程处理方式，也即采用单线程依次执行各个业务环节。比如，针对某个业务请求，共需要执行4个业务环节，其中，业务环节4需要依赖于业务环节1～3的执行结果，业务环节2和3需要依赖于业务环节1的执行结果，业务环节2和3之间不具有依赖关系，在单线程处理方式下，需要顺次执行业务环节1、2、3和4，或者顺次执行业务环节1、3、2和4。

在上述单线程处理方式下，得到业务请求的最终的执行结果的处理时长是执行上述各种业务环节的处理时长的总和。显然，在这种处理方式下，执行业务请求的处理时长较长，中央处理器(CentralProcessingUnit，CPU)利用率较低。

发明内容

本申请实施例提供一种业务请求处理方法，用以解决现有技术中执行业务请求的处理时长较长，CPU利用率较低的问题。

本申请实施例提供的一种业务请求处理方法，包括：

根据业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的业务环节集合；其中，所述拓扑结构信息包括执行所述业务请求时需要执行的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节；

并行执行确定的所述业务环节集合中的各业务环节。

可选地，并行执行确定的所述业务环节集合中的各业务环节，包括：

针对所述业务环节集合中的每一个业务环节，从存储的业务环节队列中，提取出该业务环节的执行逻辑；

为所述业务环节集合中的每一个业务环节分别分配一个空闲状态下的工作线程，并控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节。

可选地，控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节，包括：

针对每一个工作线程，控制该工作线程执行：

若执行该业务环节时需要依赖于之前执行其它业务环节后输出的业务消息，则从消息邮局中获取执行该业务环节所需的业务消息；所述消息邮局用于存储执行完各业务环节后输出的业务消息；

基于获取的业务消息，和该工作线程负责的业务环节的执行逻辑，执行该业务环节。

可选地，并行执行确定的所述业务环节集合中的各业务环节之后，还包括：

若根据所述业务请求的拓扑结构信息，确定需要在执行完所述业务环节集合之后，执行与所述业务环节集合具有依赖关系的所述业务请求的下一个业务环节，则

针对所述业务环节集合中的任一业务环节，在控制为该业务环节分配的工作线程执行完该业务环节后，判断该业务环节是否为所述业务环节集合中最后一个被执行完的业务环节；

若是，则控制为所述任一业务环节分配的工作线程执行所述下一个业务环节。

可选地，判断所述任一业务环节是否为所述业务环节集合中最后一个被执行完的业务环节之后，还包括：

若确定该业务环节不是所述业务环节集合中最后一个被执行完的业务环节，则针对所述业务请求，判断当前是否存在与所述业务环节集合不具有依赖关系的其它待执行的业务环节；

若存在，则控制为所述任一业务环节分配的工作线程执行所述其它待执行的业务环节；否则，判断当前是否存在其它业务请求待执行的的业务环节；

若存在，则控制为所述任一业务环节分配的工作线程执行所述其它业务请求待执行的业务环节，否则，释放所述工作线程。

本申请实施例提供的一种业务请求处理装置，包括：

确定模块，用于根据业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的所述业务请求的业务环节集合；其中，所述拓扑结构信息包括执行所述业务请求时需要执行的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节；

执行模块，用于并行执行确定的所述业务环节集合中的各业务环节。

本申请实施例可以根据各业务请求的拓扑结构所指示的各业务环节之间的依赖关系，将能够并行执行的业务环节并行执行，从而可以减少执行业务请求的处理时长，提高业务执行效率及CPU利用率。

附图说明

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

图2为“产品推荐”业务请求的拓扑结构示意图；

图3为本申请实施例二提供的业务请求处理方法流程图；

图4为本申请实施例提供的进行业务请求处理的系统结构示意图；

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

图6(a)为各工作线程执行业务环节的示意图之一；

图6(b)为各工作线程执行业务环节的示意图之二；

图7为本申请实施例提供的业务请求处理装置结构示意图。

具体实施方式

本申请实施例的基本思想是：在接收到业务请求后，根据该业务请求的拓扑结构信息，确定执行该业务请求时需要执行的各个业务环节之间的依赖关系，在执行该业务请求的过程中，基于这种依赖关系以及当前对该业务请求的处理进度，确定当前能够并行执行的业务环节集合，该业务环节集合可以包括多个相互之间不具有依赖关系的业务环节，并行执行这些相互之间不具有依赖关系的业务环节，串行执行相互之间具有依赖关系的业务环节。可见，本申请实施例可以根据各业务请求的拓扑结构所指示的各业务环节之间的依赖关系，将能够并行执行的业务环节并行执行，从而可以减少执行业务请求的处理时长，提高业务执行效率及CPU利用率。

下面结合说明书附图对本申请实施例作进一步详细描述。

如图1所示，为本申请实施例一提供的业务请求处理方法流程图，包括以下步骤：

S101：根据业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的业务环节集合；其中，所述拓扑结构信息包括执行所述业务请求时需要执行的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节。

在具体实施过程中，可以预先根据不同的业务请求的处理流程，存储该业务请求的拓扑结构信息，该拓扑结构信息可以是基于有向无环图的模式存储的执行该业务请求时需要执行的各个业务环节之间的依赖关系信息。这里，两个业务环节之间具有依赖关系是指一个业务环节的执行需要依赖于另一个业务环节的执行结果。如图2所示，为“产品推荐”这个业务请求的拓扑结构示意图。从该业务请求的拓扑结构中可以看出，对各个业务环节的执行顺序是：首先执行业务请求解析，在业务请求解析之后，需要执行：获取标签(tag)信息、获取推荐历史记录和获取协同信息，在获取tag信息和获取推荐历史记录之后，需要访问基于tag的搜索引擎，在获取推荐历史记录和获取协同信息之后，需要访问基于协同的搜索引擎；最后，将访问基于tag的搜索引擎的执行结果和访问基于协同的搜索引擎的执行结果进行合并，得到用户请求的“产品推荐”的结果。这里，tag信息包括基于关键词提取的各种产品信息，如用户的收藏记录、购买记录、精品库中的产品信息等等；推荐历史记录包括之前向用户推荐过的产品信息；协同信息包括其它用户分享的各种推荐产品信息等；访问基于tag的搜索引擎主要执行从获取的tag信息中过滤掉推荐历史记录中已有的产品信息，访问基于协同的搜索引擎主要执行从获取的协同信息中过滤掉推荐历史记录中已有的产品信息。可见，获取tag信息、获取推荐历史记录和获取协同信息这三个业务环节之间不具有相互依赖关系，而访问基于tag的搜索引擎需要依赖于获取tag信息和获取推荐历史记录这两个业务环节的执行结果，访问基于协同的搜索引擎需要依赖于获取推荐历史记录和获取协同信息这两个业务环节的执行结果；这里的依赖关系包括直接依赖关系和间接依赖关系，直接依赖关系是指执行顺序上相邻的业务环节之间的依赖关系，比如，访问基于tag的搜索引擎需要直接依赖于获取tag信息和获取推荐历史记录这两个业务环节的执行结果；间接依赖关系是指执行顺序上不相邻的业务环节之间的依赖关系，比如，访问基于tag的搜索引擎需要间接依赖于业务请求解析的执行结果。

该步骤中，基于业务请求的拓扑结构信息，以及当前针对该业务请求的处理进度(比如执行到了哪个或哪几个业务环节)，确定当前能够执行的一个或多个相互之间不具有依赖关系的业务环节，将这一个或多个业务环节作为一个业务环节集合并行执行。比如，针对图2所示“产品推荐”这个业务请求，在执行完业务请求解析这个业务环节后，需要执行：获取标签(tag)信息、获取推荐历史记录和获取协同信息这三个业务环节，根据图2所示拓扑图可知，这三个业务环节之间不具有依赖关系，可以并行执行，因此可以将这三个业务环节作为一个业务环节集合并行执行。在执行完这三个业务环节后，由于访问基于tag的搜索引擎和访问基于协同的搜索引擎这两个业务环节之间也不具有依赖关系，因此，可以基于上述获取标签(tag)信息、获取推荐历史记录和获取协同信息这三个业务环节的执行结果，并行执行访问基于tag的搜索引擎和访问基于协同的搜索引擎这两个业务环节。

S102：并行执行确定的所述业务环节集合中的各业务环节。

该步骤中，可以为所述业务环节集合中的每一个业务环节分配一个工作线程，控制各工作线程并行执行其对应的业务环节。

为了提高本申请方案的通用性和易实施性，减少代码编写维护的复杂度，本申请实施例可以将各个业务环节的执行逻辑分别存储起来，对各个业务环节进行整体调度，在调度到每一个业务环节时，提取出该业务环节的执行逻辑执行该业务环节。下面，通过实施例二对该实施方式作进一步说明。

如图3所示，为本申请实施例二提供的业务请求处理方法流程图，包括以下步骤：

S301：根据业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的业务环节集合；其中，所述拓扑结构信息包括执行所述业务请求时需要执行的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节。

S302：针对所述业务环节集合中的每一个业务环节，从存储的业务环节队列中，提取该业务环节的执行逻辑。

这里，业务环节的执行逻辑也即该业务环节的执行流程(或称执行代码)。该步骤中，在根据获取的拓扑结构信息，以及当前对所述业务请求的处理进度，确定出当前能够并行执行的业务环节集合后，针对该业务环节集合中的每一个业务环节，从业务环节队列中提取出该业务环节的执行逻辑。

S303：为所述业务环节集合中的每一个业务环节分别分配一个空闲状态下的工作线程，并控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节。

该步骤中，将每一个业务环节分配给一个空闲的工作线程，每一个工作线程基于自己负责的业务环节的执行逻辑执行该业务环节。

除了执行逻辑外，在具体执行每一个业务环节时，可能需要用到与该业务环节具有依赖关系的上一个业务环节的执行结果，也即执行完上一个业务环节后输出的业务消息，这就需要各业务环节之间进行消息交互，在本申请实施例中，各业务环节之间可以通过消息邮局交互消息。

具体地，S303中，控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节，包括：

针对每一个工作线程，控制该工作线程执行：

若执行该业务环节时需要依赖于之前执行其它业务环节后输出的业务消息，则从消息邮局中获取执行该业务环节所需的业务消息；所述消息邮局用于存储执行完各业务环节后输出的业务消息；

基于获取的业务消息，和该工作线程负责的业务环节的执行逻辑，执行该业务环节。

在具体实施过程中，在执行某个业务环节时，可能需要依赖于在执行该业务环节之前执行其它业务环节后输出的业务消息(也即执行结果)，这时，可以从消息邮局中提取出执行之前的业务环节后输出的业务消息。相应地，为了支持后续业务环节的执行，每执行完一个业务环节，可以将执行完该业务环节后输出的业务消息存储至所述消息邮局中。

比如，在图2中，在执行“访问基于tag的搜索引擎”这个业务环节时，需要“获取tag信息”和“获取推荐历史记录”这两个业务环节输出的业务消息，在执行“访问基于协同的搜索引擎”这个业务环节时，需要“获取推荐历史记录”和“获取协同信息”这两个业务环节输出的业务消息。

如图4所示，为本申请实施例进行业务请求处理的系统结构示意图。与上述实施例对应，可以将本申请实施例概括为五个系统角色之间的交互执行，这五个角色分别是存储各业务请求的拓扑结构信息的依赖配置管理41、存储各业务环节的执行逻辑的业务环节队列42、基于业务请求的拓扑结构信息以及执行进度为各个工作线程分派任务的调度器43、以及包括各个工作线程的线程池44、为各个业务环节提供交互消息的消息邮局45。其中，线程池44中当前处于空闲状态的各个工作线程向调度器43请求分派处理任务；调度器43可以从依赖配置管理41中获取接收的业务请求的拓扑结构信息，根据该拓扑结构信息和当前业务的处理进度，确定出当前需要执行的一个或多个业务环节，并从业务环节队列42中获取前需要执行的这一个或多个业务环节的执行逻辑，将每一个业务环节的执行逻辑调度给当前处于空闲状态的工作线程；工作线程基于负责的业务环节的执行逻辑执行该业务环节，除此之外，如有需要，可以从消息邮局45中获取执行该业务环节所需的、之前执行完的业务环节的执行结果(即执行之前的业务环节后输出的业务消息)。

在具体实施过程中，对于无法并行执行的业务环节，可以尽量控制同一个工作线程来执行，以减少上下文的切换开销。下面通过实施例三作进一步说明。

如图5所示，为本申请实施例三提供的业务请求处理方法流程图，包括以下步骤：

S501：根据业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的所述业务请求的业务环节集合；其中，所述拓扑结构信息包括所述业务请求对应的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节。

S502：针对所述业务环节集合中的每一个业务环节，从存储的业务环节队列中，提取该业务环节的执行逻辑。

S503：为所述业务环节集合中的每一个业务环节分别分配一个空闲状态下的工作线程，并控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节；其中，每一个工作线程在执行各自负责的业务环节时，若需要依赖于之前执行其它业务环节后输出的业务消息，则从消息邮局中获取执行该业务环节所需的业务消息，基于获取的业务消息，和该工作线程负责的业务环节的执行逻辑，执行该业务环节。

S504：根据所述业务请求的拓扑结构信息，确定需要在执行完所述业务环节集合之后，执行与所述业务环节集合具有依赖关系的所述业务请求的下一个业务环节。

S505：针对所述业务环节集合中的任一业务环节，在控制为该业务环节分配的工作线程执行完该业务环节后，判断该业务环节是否为所述业务环节集合中最后一个被执行完的业务环节，若是，进入S506，否则，进入S507。

S506：控制为所述任一业务环节分配的工作线程执行所述下一个业务环节。

在S505和S506中，由负责所述业务环节集合中最后一个被执行完的业务环节的工作线程，执行依赖于该业务环节集合的执行结果的下一个业务环节，这样，该工作线程可以串行执行不具有依赖关系的业务环节，减少了上下文切换开销。在控制该工作线程执行所述下一个业务环节时，与上述执行步骤类似，首先提取出所述下一个业务环节的执行逻辑，控制该工作线程基于所述下一个业务环节的执行逻辑，以及在有需要时获取的执行其它业务环节后输出的业务消息，执行所述下一个业务环节。

S507：针对所述业务请求，判断当前是否存在与所述业务环节集合不具有依赖关系的其它待执行的业务环节；若存在，则进入S508，否则进入S509。

S508：控制为所述任一业务环节分配的工作线程执行所述其它待执行的业务环节。

在具体实施过程中，若所述任一业务环节不是所述业务环节集合中最后一个被执行完的业务环节，且该业务环节所对应的业务请求中还存在其它与所述业务环节集合不具有依赖关系的待执行的业务环节，则控制执行该任一业务环节的工作线程在执行完该任一业务环节后，继续执行该业务请求中与所述业务环节集合不具有依赖关系的其它业务环节。

S509：判断当前是否存在其它业务请求待执行的业务环节；若存在，则进入S510，否则，进入S511。

S510：控制为所述任一业务环节分配的工作线程执行所述其它业务请求待执行的业务环节。

在具体实施过程中，若所述任一业务环节不是所述业务环节集合中最后一个被执行完的业务环节，并且该业务环节所对应的业务请求中已不存在与所述业务环节集合不具有依赖关系的待执行的业务环节，则控制执行该任一业务环节的工作线程在执行完该任一业务环节后，执行其它业务请求的业务环节。

S511：释放所述工作线程。

如图6(a)和图6(b)所示，某个业务请求对应p1、p2、p3和p4四个业务环节，其中，p2、p3依赖于p1的执行结果，p4依赖于p2和p3的执行结果。针对该业务请求，总共可以采用两个工作线程来执行，首先，由工作线程1来执行p1，在执行完p1后，可以继续由工作线程1来执行p2，由工作线程2来执行p3。若在p2和p3中，p3先执行完，则由工作线程1在执行完p2后，继续执行p4，工作线程2去执行其它业务请求，如图6(a)所示。若在p2和p3中，p2先执行完，则由工作线程2在执行完p3后，继续执行p4，工作线程1去执行其它业务请求，如图6(b)所示。

基于同一发明构思，本申请实施例中还提供了一种与业务请求处理方法对应的业务请求处理装置，由于该装置解决问题的原理与本申请实施例业务请求处理方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

如图7所示，为本申请实施例提供的业务请求处理装置结构示意图，包括：

确定模块71，用于根据业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的所述业务请求的业务环节集合；其中，所述拓扑结构信息包括执行所述业务请求时需要执行的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节。

执行模块72，用于并行执行确定的所述业务环节集合中的每一个业务环节。

可选地，所述执行模块72具体用于：

针对所述业务环节集合中的每一个业务环节，从存储的业务环节队列中，提取出该业务环节的执行逻辑；为所述业务环节集合中的每一个业务环节分别分配一个空闲状态下的工作线程，并控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节。

可选地，所述执行模块72具体用于：

针对每一个工作线程，控制该工作线程执行：

若执行该业务环节时需要依赖于之前执行其它业务环节后输出的业务消息，则从消息邮局中获取执行该业务环节所需的业务消息；所述消息邮局用于存储执行完各业务环节后输出的业务消息；基于获取的业务消息，和该工作线程负责的业务环节的执行逻辑，执行该业务环节。

可选地，所述执行模块72还用于：

若根据所述业务请求的拓扑结构信息，确定需要在执行完所述业务环节集合之后，执行与所述业务环节集合具有依赖关系的所述业务请求的下一个业务环节，则

针对所述业务环节集合中的任一业务环节，在控制为该业务环节分配的工作线程执行完该业务环节后，判断该业务环节是否为所述业务环节集合中最后一个被执行完的业务环节；

若是，则控制为所述任一业务环节分配的工作线程执行所述下一个业务环节。

可选地，所述执行模块72还用于：

若确定该业务环节不是所述业务环节集合中最后一个被执行完的业务环节，则针对所述业务请求，判断当前是否存在与所述业务环节集合不具有依赖关系的其它待执行的业务环节；

若存在，则控制为所述任一业务环节分配的工作线程执行所述其它待执行的业务环节；否则，判断当前是否存在其它业务请求待执行的的业务环节；

若存在，则控制为所述任一业务环节分配的工作线程执行所述其它业务请求待执行的业务环节，否则，释放所述工作线程。

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

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

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

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

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

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

Claims (10)

1.一种业务请求处理方法，其特征在于，该方法包括：

根据业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的业务环节集合；其中，所述拓扑结构信息包括执行所述业务请求时需要执行的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节；

并行执行确定的所述业务环节集合中的各业务环节。

2.如权利要求1所述的方法，其特征在于，并行执行确定的所述业务环节集合中的各业务环节，包括：

针对所述业务环节集合中的每一个业务环节，从存储的业务环节队列中，提取出该业务环节的执行逻辑；

为所述业务环节集合中的每一个业务环节分别分配一个空闲状态下的工作线程，并控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节。

3.如权利要求2所述的方法，其特征在于，控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节，包括：

针对每一个工作线程，控制该工作线程执行：

若执行该业务环节时需要依赖于之前执行其它业务环节后输出的业务消息，则从消息邮局中获取执行该业务环节所需的业务消息；所述消息邮局用于存储执行完各业务环节后输出的业务消息；

基于获取的业务消息，和该工作线程负责的业务环节的执行逻辑，执行该业务环节。

4.如权利要求2或3所述的方法，其特征在于，并行执行确定的所述业务环节集合中的各业务环节之后，还包括：

若根据所述业务请求的拓扑结构信息，确定需要在执行完所述业务环节集合之后，执行与所述业务环节集合具有依赖关系的所述业务请求的下一个业务环节，则

针对所述业务环节集合中的任一业务环节，在控制为该业务环节分配的工作线程执行完该业务环节后，判断该业务环节是否为所述业务环节集合中最后一个被执行完的业务环节；

若是，则控制为所述任一业务环节分配的工作线程执行所述下一个业务环节。

5.如权利要求4所述的方法，其特征在于，判断所述任一业务环节是否为所述业务环节集合中最后一个被执行完的业务环节之后，还包括：

若确定该业务环节不是所述业务环节集合中最后一个被执行完的业务环节，则针对所述业务请求，判断当前是否存在与所述业务环节集合不具有依赖关系的其它待执行的业务环节；

若存在，则控制为所述任一业务环节分配的工作线程执行所述其它待执行的业务环节；否则，判断当前是否存在其它业务请求待执行的的业务环节；

若存在，则控制为所述任一业务环节分配的工作线程执行所述其它业务请求待执行的业务环节，否则，释放所述工作线程。

6.一种业务请求处理装置，其特征在于，该装置包括：

确定模块，用于根据业务请求的拓扑结构信息，以及当前对所述业务请求的处理进度，确定当前能够并行执行的所述业务请求的业务环节集合；其中，所述拓扑结构信息包括执行所述业务请求时需要执行的各个业务环节之间的依赖关系信息；所述业务环节集合包含一个业务环节或包含多个相互之间不具有依赖关系的业务环节；

执行模块，用于并行执行确定的所述业务环节集合中的各业务环节。

7.如权利要求6所述的装置，其特征在于，所述执行模块具体用于：

针对所述业务环节集合中的每一个业务环节，从存储的业务环节队列中，提取出该业务环节的执行逻辑；为所述业务环节集合中的每一个业务环节分别分配一个空闲状态下的工作线程，并控制各工作线程分别基于各自负责的业务环节的执行逻辑，并行执行各自负责的业务环节。

8.如权利要求7所述的装置，其特征在于，所述执行模块具体用于：

针对每一个工作线程，控制该工作线程执行：

若执行该业务环节时需要依赖于之前执行其它业务环节后输出的业务消息，则从消息邮局中获取执行该业务环节所需的业务消息；所述消息邮局用于存储执行完各业务环节后输出的业务消息；基于获取的业务消息，和该工作线程负责的业务环节的执行逻辑，执行该业务环节。

9.如权利要求7或8所述的装置，其特征在于，所述执行模块还用于：

若根据所述业务请求的拓扑结构信息，确定需要在执行完所述业务环节集合之后，执行与所述业务环节集合具有依赖关系的所述业务请求的下一个业务环节，则

针对所述业务环节集合中的任一业务环节，在控制为该业务环节分配的工作线程执行完该业务环节后，判断该业务环节是否为所述业务环节集合中最后一个被执行完的业务环节；

若是，则控制为所述任一业务环节分配的工作线程执行所述下一个业务环节。

10.如权利要求9所述的装置，其特征在于，所述执行模块还用于：

若确定该业务环节不是所述业务环节集合中最后一个被执行完的业务环节，则针对所述业务请求，判断当前是否存在与所述业务环节集合不具有依赖关系的其它待执行的业务环节；

若存在，则控制为所述任一业务环节分配的工作线程执行所述其它待执行的业务环节；否则，判断当前是否存在其它业务请求待执行的的业务环节；

若存在，则控制为所述任一业务环节分配的工作线程执行所述其它业务请求待执行的业务环节，否则，释放所述工作线程。