任务执行方法、装置、设备及存储介质与流程

本公开实施例涉及计算机技术，尤其涉及一种任务执行方法、装置、设备及存储介质。

背景技术：

在大多数基于服务器/客户端的系统结构中，若客户端向服务器发起服务调用请求，则服务器会通过调度器将该请求加入线程池，由线程池来处理执行服务调用请求对应的一个或多个任务。

上述任务执行的方式过于单一，需要进行优化。

技术实现要素：

本公开实施例提供一种任务执行方法、装置、设备及存储介质，以优化任务执行方案。

第一方面，本公开实施例提供了一种任务执行方法，包括：

接收服务调用请求；

获取预先设置的多个任务的执行依赖关系信息；根据所述执行依赖关系信息生成所述多个任务的执行图；所述执行图用于描述所述多个任务的执行顺序，所述执行顺序包括并行执行和/或串行执行；

根据生成的所述执行图执行所述多个任务，得到服务调用结果。

进一步的，在接收到所述服务调用请求之后，所述方法还包括：

获取所述服务调用请求对应的请求上下文类；所述请求上下文类中包含所述多个任务分别对应的任务类中的上下文属性参数；

基于所述服务调用请求中包含的信息对所述请求上下文类进行实例化，得到请求上下文类对象；

根据生成的所述执行图执行所述多个任务，得到服务调用结果，包括：

根据所述执行图确定需要执行的当前任务；从所述请求上下文类对象中获取所述当前任务对应的上下文属性参数值；

根据所述上下文属性参数值和所述当前任务所依赖的其他任务的执行结果，执行所述当前任务所对应任务类中的运行函数，得到所述当前任务的执行结果；

返回执行根据所述执行图确定需要执行的当前任务的操作，直至所述执行图中的任务全部被执行完毕。

进一步的，在得到所述当前任务的执行结果之后，所述方法还包括：

基于所述当前任务的执行结果更新所述请求上下文类对象中的所述当前任务对应的上下文属性参数值；

在所述执行图中的任务全部被执行完毕之后，所述方法还包括：

基于所述请求上下文类对象生成服务调用结果，将所述服务调用结果反馈给所述服务调用请求的发送方。

进一步的，所述获取预先设置的多个任务的执行依赖关系信息，包括：

根据所述服务调用请求从预先配置的多个有向无环图dag描述文件中选取一个dag描述文件；

从选取的dag描述文件中获取所述多个任务的执行依赖关系信息。

进一步的，在接收到服务调用请求之后、获取预先设置的多个任务的执行依赖关系信息之前，所述方法还包括：

将所述服务调用请求输入给预先生成的服务处理对象，以使所述服务处理对象根据所述服务调用请求执行所述获取预先设置的多个任务的执行依赖关系信息、根据所述执行依赖关系信息生成所述多个任务的执行图、根据生成的所述执行图执行所述多个任务的操作。

进一步的，生成所述服务处理对象，包括：

获取服务接口定义语言idl文件、脚本文件、dag描述文件和任务文件；

将所述服务idl文件、所述dag描述文件和所述任务文件，输入给所述脚本文件，通过运行所述脚本文件得到服务处理对象；

保存生成的所述服务处理对象。

进一步的，所述通过运行所述脚本文件得到服务处理对象，包括：

运行所述脚本文件后，得到服务源代码文件、服务处理类、资源管理器和请求上下文类；

通过对所述服务源代码文件、服务处理类、资源管理器和请求上下文类进行编译，得到服务处理程序；

在启动所述服务处理程序时，通过调用服务适配函数适配服务源代码文件，通过调用服务封装函数加载适配的服务源代码文件，得到生成的服务处理对象。

第二方面，本公开实施例还提供了一种任务执行装置，该装置包括：

请求接收模块，用于接收服务调用请求；

执行图生成模块，用于获取预先设置的多个任务的执行依赖关系信息；根据所述执行依赖关系信息生成所述多个任务的执行图；所述执行图用于描述所述多个任务的执行顺序，所述执行顺序包括并行执行和/或串行执行；

结果获取模块，根据生成的所述执行图执行所述多个任务，得到服务调用结果。

进一步的，所述装置还包括：

上下文类获取模块，用于在接收到所述服务调用请求之后，获取所述服务调用请求对应的请求上下文类；所述请求上下文类中包含所述多个任务分别对应的任务类中的上下文属性参数；

对象生成模块，用于基于所述服务调用请求中包含的信息对所述请求上下文类进行实例化，得到请求上下文类对象；

所述结果获取模块，包括：

参数获取子模块，用于根据所述执行图确定需要执行的当前任务；从所述请求上下文类对象中获取所述当前任务对应的上下文属性参数值；

函数执行子模块，用于根据所述上下文属性参数值和所述当前任务所依赖的其他任务的执行结果，执行所述当前任务所对应任务类中的运行函数，得到所述当前任务的执行结果；

返回执行子模块，用于返回执行根据所述执行图确定需要执行的当前任务的操作，直至所述执行图中的任务全部被执行完毕。

进一步的，所述结果获取模块还包括：

参数更新子模块，在得到所述当前任务的执行结果之后，用于基于所述当前任务的执行结果更新所述请求上下文类对象中的所述当前任务对应的上下文属性参数值；

所述结果获取模块还包括：

消息反馈模块，用于在所述执行图中的任务全部被执行完毕之后，基于所述请求上下文类对象生成服务调用结果，将所述服务调用结果反馈给所述服务调用请求的发送方。

进一步的，所述执行图生成模块，具体用于：

根据所述服务调用请求从预先配置的多个有向无环图dag描述文件中选取一个dag描述文件；

从选取的dag描述文件中获取所述多个任务的执行依赖关系信息。

进一步的，所述装置还包括：

请求输入模块，用于在接收到服务调用请求之后、获取预先设置的多个任务的执行依赖关系信息之前，将所述服务调用请求输入给预先生成的服务处理对象，以使所述服务处理对象根据所述服务调用请求执行所述获取预先设置的多个任务的执行依赖关系信息、根据所述执行依赖关系信息生成所述多个任务的执行图、根据生成的所述执行图执行所述多个任务的操作。

进一步的，所述请求输入模块，具体还包括：

文件获取子模块，用于获取服务接口定义语言idl文件、脚本文件、dag描述文件和任务文件；

文件输入子模块，用于将所述服务idl文件、所述dag描述文件和所述任务文件，输入给所述脚本文件，通过运行所述脚本文件得到服务处理对象；

对象保存子模块，用于保存生成的所述服务处理对象。

进一步的，所述文件输入子模块，具体用于：

运行所述脚本文件后，得到服务源代码文件、服务处理类、资源管理器和请求上下文类；

通过对所述服务源代码文件、服务处理类、资源管理器和请求上下文类进行编译，得到服务处理程序；

在启动所述服务处理程序时，通过调用服务适配函数适配服务源代码文件，通过调用服务封装函数加载适配的服务源代码文件，得到生成的服务处理对象。

第三方面，本公开实施例还提供了一种计算机设备，该设备包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本公开实施例中任一所述的任务执行方法。

第四方面，本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本公开实施例中任一所述的任务执行方法。

本公开实施例通过在接收到服务调用请求时，获取预先设置的多个任务的执行依赖关系信息，根据该执行依赖关系信息生成多个任务的执行图，以描述多个任务的执行顺序，再根据该执行图执行多个任务，最终得到服务调用结果，利用预先设置的依赖关系信息来构建任务执行图，任务执行方案得到了优化，使得可以仅通过改变任务之间的依赖关系信息，就可以实现对任务执行顺序的修改，而不需要重新编写整个服务处理程序，实现了节省资源，提高服务程序生成效率的效果。

附图说明

图1a是本公开实施例一提供的一种任务执行方法的流程示意图；

图1b是本公开实施例一适用的一种执行图的执行顺序示意图；

图2是本公开实施例二提供的一种任务执行方法的流程示意图；

图3a是本公开实施例三提供的一种任务执行方法的流程示意图；

图3b是本公开实施例三提供的一种服务处理对象的生成结构示意图；

图4是本公开实施例四提供的一种任务执行装置的结构示意图；

图5是本公开实施例五提供的一种计算机设备的结构示意图。

具体实施方式

下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本公开相关的部分而非全部结构。

下述各实施例中，每个实施例中同时提供了可选特征和示例，实施例中记载的各个特征可进行组合，形成多个可选方案，不应将每个编号的实施例仅视为一个技术方案。

实施例一

图1a为本公开实施例一提供的一种任务执行方法的流程示意图。该方法可适用于根据客户端发送的服务调用请求实现相应服务的情况，该方法可以由任务执行装置来执行，该装置可由硬件和/或软件组成，并一般可集成在服务器以及所有包含服务处理功能的计算机设备中。具体包括如下：

s110、接收服务调用请求。

本实施例主要是基于客户端向服务器发送服务调用请求，服务器根据该服务调用请求处理完成相应的任务处理的应用场景，其中，服务调用请求可以是针对服务器中预设的服务功能之一，由客户端向服务器发起的请求。例如，服务调用请求可以是客户端向服务器发起的文章推荐服务的调用请求，以使服务器为该客户端提供文章推荐结果。

示例性的，服务器在接收到服务调用请求后，可根据服务调用请求所对应的服务类型，得到所需执行的多个任务。以thrift服务框架为例，本实施例中提到的任务为executor，包含同步和异步两种运行方式，对外暴露统一的folly::future<int>run(std::shared_ptr<context>ctx)接口。内部分别调用intpre(ctx)->intsync(ctx)->intpost(ctx)或intpre(ctx)->folly::future<int>async(ctx)->intpost(ctx)两条路径。每个pre/sync/async/post都是虚函数，可以被派生类覆盖。executor设置上下文属性参数ctx来传递数据，同时内部不维护状态，以保证线程安全。

s120、获取预先设置的多个任务的执行依赖关系信息；根据执行依赖关系信息生成多个任务的执行图；该执行图用于描述多个任务的执行顺序，执行顺序包括并行执行和/或串行执行。

其中，执行依赖关系信息包含服务中多个任务执行时各任务所依赖的执行条件，基于该执行条件，可生成该多个任务对应的执行图，以描述多个任务的执行顺序，该执行顺序包括并行执行和/或串行执行，在此不作限定。例如，图1b所示，接收到的服务调用请求所对应的服务需要执行的任务包括第一任务11、第二任务12、第三任务13、第四任务14以及第五任务15，若获取的预先设置的执行依赖关系信息为：第二任务12和第三任务13的执行依赖于第一任务11的执行结果，第四任务14的执行依赖于第三任务13的执行结果，第五任务15的执行依赖于第二任务12和第四任务14的执行结果，则可自动生成如图1b所示的执行图，其中，首先执行的是第一任务11，由于第二任务12和第三任务13之间没有依赖关系，因此第二任务12与第三任务13并行执行，在第三任务13执行结束后执行第四任务14，最后，在第二任务12和第四任务14均执行结束后执行第五任务15。

由于不同的服务调用请求可对应于不同的服务类型，而不同的服务类型所对应需要执行的任务也不尽相同，因此，本实施例采用在服务调用请求对应的服务类型中，针对多个所需执行的任务，预先设置相应的执行依赖关系信息的方式，来确定任务的执行顺序，在需要对任务的执行顺序进行修改时，仅需要更改执行依赖关系信息即可，进而无需开发人员对该服务类型对应的整个服务处理程序进行重新编写，节省了资源，提高了服务程序生成效率。

可选的，获取预先设置的多个任务的执行依赖关系信息，包括：根据服务调用请求从预先配置的多个有向无环图(dag)描述文件中选取一个dag描述文件；从选取的dag描述文件中获取多个任务的执行依赖关系信息。

其中，dag(directedacyclicgraph，有向无环图)描述文件用于记录特定服务类型对应所需执行的多个任务之间的执行依赖关系信息。示例性的，当收到服务调用请求后，可根据服务调用请求对应的服务类型，选择与该类型相匹配的dag描述文件，也可根据dag描述文件的排列顺序，选择该服务调用请求对应顺序位的dag描述文件，或者根据服务调用请求对应的服务版本，选择与该服务版本相匹配的dag描述文件，进而从选取的dag描述文件中解析出该服务对应所需执行的多个任务之间的执行依赖关系信息。

s130、根据生成的执行图执行多个任务，得到服务调用结果。

本实施例中，由于生成的执行图中描述了任务之间的执行顺序，因此可根据该执行图确定各任务的执行顺序，进而根据该执行顺序执行各个任务。以thrift服务框架为例，libengine是executor运行的容器，内部将多个executor串行或并行组合新的executor，执行其run方法即可完成整个执行图中各任务的执行。在服务调用请求所对应多个任务均执行完毕，则可得到服务调用结果。

举一个实际例子，针对文章推荐服务，实现该服务可以有多种方法，比如通过如下任务执行路径可以实现该服务：任务1(获取文章)->任务2(筛选文章)->任务3(文章排序)->任务4(插入热点文章)；还可以通过另一种任务执行路径可以实现该服务：任务1(获取文章)->任务4(插入热点文章)->任务2(筛选文章)->任务3(文章排序)。

现有技术中，在按照第一种任务执行路径生成服务处理程序后，若需要按照第二种任务执行路径实现服务，则需要根据第二种任务执行路径重新生成服务处理程序，耗时耗力，效率低下；而本实施例则不需要重新生成服务处理程序，只需通过修改dag描述文件或新增dag描述文件，将第一种任务执行路径对应的执行依赖关系信息，修改为第二种任务执行路径对应的执行依赖关系信息，就可以根据新的执行依赖关系信息生成能够反映新的任务执行顺序的执行图，并按照执行图执行多个任务，得到服务调用结果，节省了资源，提高了效率。

本实施例的技术方案，通过在接收到服务调用请求时，获取预先设置的多个任务的执行依赖关系信息，根据该执行依赖关系信息生成多个任务的执行图，以描述多个任务的执行顺序，再根据该执行图执行多个任务，最终得到服务调用结果，利用预先设置的依赖关系信息来构建任务执行图，任务执行方案得到了优化，使得可以仅通过改变任务之间的依赖关系信息，就可以实现对任务执行顺序的修改，而不需要重新编写整个服务处理程序，实现了节省资源，提高服务程序生成效率的效果。

实施例二

图2为本公开实施例二提供的一种任务执行方法的流程示意图。本实施例以上述实施例中各个可选方案为基础进行具体化，提供了可选的任务执行方法，具体是，在接收到服务调用请求之后，所述方法还包括：获取服务调用请求对应的请求上下文类；基于服务调用请求中包含的信息对请求上下文类进行实例化，得到请求上下文类对象。具体包括如下：

s210、接收服务调用请求。

s220、获取服务调用请求对应的请求上下文类，请求上下文类中包含多个任务分别对应的任务类中的上下文属性参数。

本实施例中，不同的服务类型可对应于不同的请求上下文类(requestcontext)，请求上下文类中包含有其所属服务类型对应需要执行的多个任务的上下文属性参数ctx，通过该多个任务的上下文属性参数，可对应传递任务执行时所需的参数值和/或传递任务执行结果值，以适配不同的服务功能。

示例性的，可先根据服务调用请求确定其所属的服务类型，再根据该服务类型获取相对应的请求上下文类，其中，初始状态下，也即还未对请求上下文类进行实例化的情况下，请求上下文类中包含的上下文属性参数没有具体的取值。

s230、基于服务调用请求中包含的信息对请求上下文类进行实例化，得到请求上下文类对象。

其中，服务调用请求中包含的信息可以包括：客户端的用户名、地理位置、ip地址等。对请求上下文类进行实例化的过程具体可以是，将所述服务调用请求中包含的字段信息填充到请求上下文类中，例如，将请求上下文类中包含的每个上下文属性参数中的基础字段，使用服务调用请求中相应的字段信息进行按需赋值。填充之前请求上下文类中包含的上下文属性参数没有具体的取值，填充之后就会具体的取值，也即请求上下文类对象中包含有与该服务调用请求相对应的上下文属性参数。

s240、获取预先设置的多个任务的执行依赖关系信息；根据执行依赖关系信息生成多个任务的执行图；执行图用于描述多个任务的执行顺序，执行顺序包括并行执行和/或串行执行。

可选的，上述步骤s220-s230可以在s240之前执行，也可以在s240之后执行，在此不作限定。

s250、根据执行图确定需要执行的当前任务；从请求上下文类对象中获取当前任务对应的上下文属性参数值。

由于每个任务在执行时需要依赖其所对应的上下文属性参数的取值，因此，在执行当前任务时，需要从请求上下文类对象中获取相应的上下文属性参数值。例如，在如图1b所示的执行图中，请求上下文类对象中包含的上下文属性参数有ctx1、ctx2、ctx3、ctx4以及ctx5，分别对应于第一任务11、第二任务12、第三任务13、第四任务14以及第五任务15，则若执行图中当前需要执行的任务为第三任务13，则可从请求上下文类对象中获取相应的上下文属性参数ctx3，以作为执行第三任务13所需的必要条件之一。

s260、根据上下文属性参数值和当前任务所依赖的其他任务的执行结果，执行当前任务所对应任务类中的运行函数，得到当前任务的执行结果。

示例性的，在如图1b所示的执行图中，若当前任务为第三任务13，则可将第三任务13对应获取的上下文属性参数值ctx3，以及第三任务13所依赖的第一任务11的执行结果，作为第三任务13所对应任务类中的运行函数的输入值，并执行该运行函数，例如run函数，进而可得到第三任务13的执行结果。

可选的，在得到当前任务的执行结果之后，方法还包括：基于当前任务的执行结果更新请求上下文类对象中的当前任务对应的上下文属性参数值。

其中，更新方法可以是将当前任务对应的上下文属性参数值，直接替换为当前任务的执行结果所对应的取值，以便在执行依赖于当前任务执行结果的下一任务时可直接调用该上下文属性参数值，作为下一任务执行时所需的当前任务的执行结果。

s270、确定执行图中的任务是否全部被执行完毕，若是，则执行s280；若否，则返回执行s250。

示例性的，例如图1b所示的执行图中，若当前任务为第三任务13，其后还有未执行的其他任务，则可确定执行图中的任务并未全部被执行完毕，此时，可返回s250继续将第四任务14作为当前任务来执行，直至第五任务15执行完毕，则可确定执行图中的任务全部被执行完毕，并将第五任务15执行得到的执行结果作为服务调用结果。

s280、获取服务调用结果。

可选的，在执行图中的任务全部被执行完毕之后，该方法还包括：基于请求上下文类对象生成服务调用响应消息，将服务调用响应消息反馈给服务调用请求的发送方。

示例性的，当执行图中的任务全部被执行完毕，由于请求上下文类对象中包含的上下文属性参数值已被更新为最后一个任务执行完毕后所得到的服务调用结果，因此，可根据该请求上下文类对象生成相应的服务调用响应消息，该服务调用响应消息中可包括携带有服务调用结果的请求上下文类对象，从而将该服务调用响应消息反馈给该客户端，也即服务调用请求的发送方，以完成服务调用功能。

本实施例的技术方案，通过获取服务调用请求对应的请求上下文类，并基于服务调用请求中包含的信息对该请求上下文类进行实例化，以得到与该服务调用请求对应的请求上下文类对象，进而根据预先设置的多个任务的执行依赖关系信息生成多个任务的执行图，按照该执行图中各个任务的执行顺序来执行任务，在执行当前任务时，从请求上下文类对象中获取对应的上下文属性参数值，并根据该上下文属性参数值以及所依赖的其他任务的执行结果，执行运行函数，以生成当前任务的执行结果，如此循环，直至执行图中的任务全部被执行完毕，利用请求上下文类对象中包含的上下文属性参数值，实现了各个任务之间的调用，同时也利用了任务之间的执行依赖关系信息易于更改的特性，使得在对任务执行顺序进行更改时操作更加简单，节省了资源，提高了服务程序生成效率。

实施例三

图3a为本公开实施例三提供的一种任务执行方法的流程示意图。本实施例以上述实施例中各个可选方案为基础进行具体化，提供了可选的任务执行方法，具体是，在接收到服务调用请求之后、获取预先设置的多个任务的执行依赖关系信息之前，所述方法还包括：将服务调用请求输入给预先生成的服务处理对象。具体包括如下：

s310、接收服务调用请求。

s320、将服务调用请求输入给预先生成的服务处理对象。

其中，服务处理对象可以是对服务调用请求进行处理时，服务器所提供的服务处理入口，例如thrift服务框架中的thriftservicehandler。服务处理对象具体可以用于根据服务调用请求执行获取预先设置的多个任务的执行依赖关系信息、根据执行依赖关系信息生成多个任务的执行图、根据生成的执行图执行多个任务的操作。

在thrift服务框架中，客户端可通过执行rpcfunction(remoteprocedurecallfunction，远程过程调用函数)，以将服务调用请求输入给服务器中预先生成的服务处理对象。其中，不同的服务类型可对应于不同的服务处理对象。

可选的，生成服务处理对象，包括：获取服务idl文件、脚本文件、dag描述文件和任务文件；将服务idl文件、dag描述文件和任务文件，输入给脚本文件，通过运行脚本文件得到服务处理对象；保存生成的服务处理对象。

其中，服务idl(interfacedefinitionlanguage，接口定义语言)文件是一个接口文件，该文件中包含该服务类型对应的服务需求信息(比如服务的输入是什么、输出是什么)、输入输出的规范和字段定义信息等。脚本文件是指生成器，是依据一定的代码格式编写的可执行文件，用来进行任务的批量处理(具体指生成代码)。任务文件中包含各任务对应的任务类的描述信息，例如，描述信息包含任务类所对应的上下文属性参数以及运行函数等。

以thrift服务框架为例，thriftservicehandler中，每一个服务idl文件，也即thriftidl，都会编译生成一个api::thriftservicehandler以接入内部服务化平台。在得到服务处理对象时，可通过executorstore来存储、检索、提供命令行和restful接口，同时提供应用示例和帮助文档，以提高executor的代码复用率。

可选的，通过运行脚本文件得到服务处理对象，包括：运行脚本文件后，得到服务源代码文件、服务处理类、资源管理器和请求上下文类；通过对服务源代码文件、服务处理类、资源管理器和请求上下文类进行编译，得到服务处理程序；在启动服务处理程序时，通过调用服务适配函数适配服务源代码文件，通过调用服务封装函数加载适配的服务源代码文件，得到生成的服务处理对象。

以thrift服务框架为例，运行脚本文件后，得到的服务源代码文件可以是thriftinterface，通过对该服务源代码文件进行编译，可将人类可读的计算机语言指令翻译成为计算机可以执行的二进制指令。运行脚本文件后，得到的服务处理类，属于未被实例化的服务处理对象，而得到的资源管理器(resourcemanager)，可用于管理该服务类型对应所需执行的多个任务executor，其中注册有该服务所需的全部任务executor对应的信息，例如每个任务所属任务类所对应的上下文属性参数以及运行函数，同时，还生成有请求上下文类(requestcontext)，其中包含有该上下文属性参数。

示例性的，在编译得到服务处理程序后，在启动该服务处理程序时，可通过调用服务适配函数(serviceadaptor)确定该服务类型对应的服务源代码文件(thriftinterface)，再通过调用thrift服务中的封装函数(libtimetomb)对该服务源代码文件进行封装，最终得到服务处理对象。其中，封装函数(libtimetomb)可通过gflags设置端口，线程数，日志名，配置文件等，并向该封装函数(libtimetomb)提供相应的服务源代码文件(thriftinterface)即可执行相应的主函数流程。具体的，thrift服务框架中服务处理对象(thriftservicehandler)的生成过程如图3b所示。

s330、获取预先设置的多个任务的执行依赖关系信息；根据执行依赖关系信息生成多个任务的执行图；执行图用于描述多个任务的执行顺序，执行顺序包括并行执行和/或串行执行。

s340、根据生成的执行图执行多个任务，得到服务调用结果。

本实施例的技术方案，通过将接收到的服务调用请求输入给预先生成的服务处理对象，以使所述服务处理对象根据该服务调用请求执行获取预先设置的多个任务的执行依赖关系信息、根据执行依赖关系信息生成多个任务的执行图、根据生成的执行图执行多个任务的操作，从而最终得到服务调用结果，实现了服务处理对象的快速生成，使得当任务执行顺序发生改变时，也能够根据修改后的执行依赖关系信息快速生成相应的服务处理对象，来处理服务调用请求，从而无需开发人员重新编写整个服务处理程序，节省了人力物力资源，提高了任务执行顺序的修改效率。

实施例四

图4为本公开实施例四提供的一种任务执行装置的结构示意图。参考图4，任务执行装置包括：请求接收模块410、执行图生成模块420以及结果获取模块430，下面对各模块进行具体说明。

请求接收模块410，用于接收服务调用请求；

执行图生成模块420，用于获取预先设置的多个任务的执行依赖关系信息；根据所述执行依赖关系信息生成所述多个任务的执行图；所述执行图用于描述所述多个任务的执行顺序，所述执行顺序包括并行执行和/或串行执行；

结果获取模块430，根据生成的所述执行图执行所述多个任务，得到服务调用结果。

本实施例提供的任务执行装置，通过在接收到服务调用请求时，获取预先设置的多个任务的执行依赖关系信息，根据该执行依赖关系信息生成多个任务的执行图，以描述多个任务的执行顺序，再根据该执行图执行多个任务，最终得到服务调用结果，利用预先设置的依赖关系信息来构建任务执行图，任务执行方案得到了优化，使得可以仅通过改变任务之间的依赖关系信息，就可以实现对任务执行顺序的修改，而不需要重新编写整个服务处理程序，实现了节省资源，提高服务程序生成效率的效果。

进一步的，所述装置还可以包括：

上下文类获取模块，用于在接收到所述服务调用请求之后，获取所述服务调用请求对应的请求上下文类；所述请求上下文类中包含所述多个任务分别对应的任务类中的上下文属性参数；

对象生成模块，用于基于所述服务调用请求中包含的信息对所述请求上下文类进行实例化，得到请求上下文类对象；

结果获取模块430，可以包括：

参数获取子模块，用于根据所述执行图确定需要执行的当前任务；从所述请求上下文类对象中获取所述当前任务对应的上下文属性参数值；

函数执行子模块，用于根据所述上下文属性参数值和所述当前任务所依赖的其他任务的执行结果，执行所述当前任务所对应任务类中的运行函数，得到所述当前任务的执行结果；

返回执行子模块，用于返回执行根据所述执行图确定需要执行的当前任务的操作，直至所述执行图中的任务全部被执行完毕。

可选的，结果获取模块430还可以包括：

参数更新子模块，在得到所述当前任务的执行结果之后，用于基于所述当前任务的执行结果更新所述请求上下文类对象中的所述当前任务对应的上下文属性参数值；

结果获取模块430还可以包括：

消息反馈模块，用于在所述执行图中的任务全部被执行完毕之后，基于所述请求上下文类对象生成服务调用结果，将所述服务调用结果反馈给所述服务调用请求的发送方。

可选的，执行图生成模块420，具体可以用于：

根据所述服务调用请求从预先配置的多个有向无环图dag描述文件中选取一个dag描述文件；

从选取的dag描述文件中获取所述多个任务的执行依赖关系信息。

可选的，所述装置还可以包括：

请求输入模块，用于在接收到服务调用请求之后、获取预先设置的多个任务的执行依赖关系信息之前，将所述服务调用请求输入给预先生成的服务处理对象，以使所述服务处理对象根据所述服务调用请求执行所述获取预先设置的多个任务的执行依赖关系信息、根据所述执行依赖关系信息生成所述多个任务的执行图、根据生成的所述执行图执行所述多个任务的操作。

可选的，所述请求输入模块，具体还可以包括：

文件获取子模块，用于获取服务idl文件、脚本文件、dag描述文件和任务文件；

文件输入子模块，用于将所述服务idl文件、所述dag描述文件和所述任务文件，输入给所述脚本文件，通过运行所述脚本文件得到服务处理对象；

对象保存子模块，用于保存生成的所述服务处理对象。

可选的，所述文件输入子模块，具体可以用于：

运行所述脚本文件后，得到服务源代码文件、服务处理类、资源管理器和请求上下文类；

通过对所述服务源代码文件、服务处理类、资源管理器和请求上下文类进行编译，得到服务处理程序；

在启动所述服务处理程序时，通过调用服务适配函数适配服务源代码文件，通过调用服务封装函数加载适配的服务源代码文件，得到生成的服务处理对象。

上述产品可执行本公开任意实施例所提供的方法，具备执行方法相应的功能模块和有益效果。

实施例五

图5为本公开实施例五提供的一种计算机设备的结构示意图，如图5所示，本实施例提供的一种计算机设备，包括：处理器51和存储器52。该计算机设备中的处理器可以是一个或多个，图5中以一个处理器51为例，所述计算机设备中的处理器51和存储器52可以通过总线或其他方式连接，图5中以通过总线连接为例。

本实施例中计算机设备的处理器51中集成了上述实施例提供的任务执行装置。此外，该计算机设备中的存储器52作为一种计算机可读存储介质，可用于存储一个或多个程序，所述程序可以是软件程序、计算机可执行程序以及模块，如本公开实施例中任务执行方法对应的程序指令/模块(例如，附图4所示的任务执行装置中的模块，包括：请求接收模块410、执行图生成模块420以及结果获取模块430)。处理器51通过运行存储在存储器52中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述方法实施例中任务执行方法。

存储器52可包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据设备的使用所创建的数据等。此外，存储器52可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器52可进一步包括相对于处理器51远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

并且，当上述计算机设备所包括一个或者多个程序被所述一个或者多个处理器51执行时，程序进行如下操作：

接收服务调用请求；获取预先设置的多个任务的执行依赖关系信息；根据执行依赖关系信息生成多个任务的执行图；执行图用于描述多个任务的执行顺序，执行顺序包括并行执行和/或串行执行；根据生成的执行图执行多个任务，得到服务调用结果。

实施例六

本公开实施例六还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被任务执行装置执行时实现如本公开实施例一提供的任务执行方法，该方法包括：接收服务调用请求；获取预先设置的多个任务的执行依赖关系信息；根据执行依赖关系信息生成多个任务的执行图；执行图用于描述多个任务的执行顺序，执行顺序包括并行执行和/或串行执行；根据生成的执行图执行多个任务，得到服务调用结果。

当然,本公开实施例所提供的一种计算机可读存储介质,其上存储的计算机程序被执行时不限于实现如上所述的方法操作,还可以实现本公开任意实施例所提供的任务执行方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本公开可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read-onlymemory,rom)、随机存取存储器(randomaccessmemory,ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述的方法。

值得注意的是，上述任务执行装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本公开的保护范围。

注意，上述仅为本公开的较佳实施例及所运用技术原理。本领域技术人员会理解，本公开不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本公开的保护范围。因此，虽然通过以上实施例对本公开进行了较为详细的说明，但是本公开不仅仅限于以上实施例，在不脱离本公开构思的情况下，还可以包括更多其他等效实施例，而本公开的范围由所附的权利要求范围决定。