CN107679817B - 工作流执行方法及相关设备 - Google Patents

Abstract

本申请提供了一种应用在工作流服务端上的工作流执行方法，该方法中，工作流服务端并未参与工作流实例的执行过程，而仅仅保存工作流实例的基本信息，既提高了工作流实例的执行效率也保证了工作流实例执行的稳定性。为了与应用在工作流服务端的工作流执行方法相对应，本申请还提供了应用在工作流客户端的工作流执行方法。另外，本申请还提供了工作流客户端、工作流服务端、及工作流执行系统，用以保证所述方法在实际中的应用及实现。

Description

工作流执行方法及相关设备

技术领域

本申请涉及工作流技术领域，更具体地，是工作流执行方法及相关设备。

背景技术

工作流，属于一种计算机支持的协同工作流程。具体地，工作流可以被拆分为多个任务，例如，一个工作流为创建虚拟机，其中包括两个任务，分别为分配硬件资源及分配网络资源。按照预设的执行顺序依次完成每个任务，则认为完成了一个工作流。

目前，工作流的执行方式主要包括两种，分别是在单台机器上定义及执行工作流、以及由服务器对工作流的执行过程进行调度。然而，前者工作流执行稳定性不够，后者工作流执行效率较低。

发明内容

有鉴于此，本申请提供了一种应用在工作流服务端的工作流执行方法，用以在工作流实例的执行效率及稳定性二者之间实现平衡。为了与应用在工作流服务端的工作流执行方法相对应，本申请还提供了一种应用在工作流客户端的工作流执行方法。另外，本申请还提供了工作流客户端、工作流服务端、及工作流执行系统，用以保证所述方法在实际中的应用及实现。

为实现所述目的，本申请提供的技术方案如下：

一种工作流执行方法，包括：

工作流客户端创建工作流实例后，将所述工作流实例的基本信息上传至工作流服务端，并执行所述工作流实例；其中，所述基本信息包括所述工作流实例的元数据及初始状态；

所述工作流服务端接收所述工作流实例的基本信息并进行存储，以及若监测到所述工作流客户端未成功执行所述工作流实例，依据所述基本信息，重新调度所述工作流实例。

可选地，工作流执行方法还包括：

所述工作流客户端将所述工作流实例的执行状态上传至所述工作流服务端；

所述工作流服务端接收所述执行状态并进行存储。

可选地，所述工作流实例包括多个任务，该方法还包括：

所述工作流客户端将所述任务的执行结果上传至所述工作流服务端；

所述工作流服务端接收所述执行结果并进行存储。

可选地，所述工作流服务端若监测到所述工作流客户端未成功执行所述工作流实例，则依据所述基本信息，重新调度所述工作流实例，包括：

所述工作流服务端若监测到所述工作流客户端执行所述工作流实例的多个任务中的目标任务的时长超过对应的时长阈值且所述目标任务的数量超过预设任务阈值，则依据存储的所述基本信息，将所述工作流实例重新分配至其他工作流客户端执行。

可选地，所述工作流服务端若监测到所述工作流客户端未成功执行所述工作流实例，则依据所述基本信息，重新调度所述工作流实例，包括：

所述工作流服务端若监测到所述工作流客户端不可用，则依据存储的所述基本信息，将所述工作例客户端上执行的所有工作流实例重新分配至其他工作流客户端执行。

一种工作流执行方法，应用于工作流服务端，该方法包括：

接收工作流客户端上传的工作流实例的基本信息；其中，所述基本信息包括所述工作流实例的元数据及初始状态；

存储所述基本信息。

可选地，在所述存储所述基本信息之后，还包括：

向所述工作流客户端返回存储结果；其中，所述存储结果为成功的情况下，用于触发所述工作流客户端执行所述工作流实例。

可选地，所述工作流实例包括多个任务，相应地，该方法还包括：

存储所述工作流客户端上传的所述任务的执行结果。

可选地，每个所述任务具有各自的时长阈值；相应地，该方法还包括：

若所述工作流客户端执行所述多个任务中的目标任务的时长超过对应的时长阈值且所述目标任务的数量超过预设任务阈值，则依据存储的所述基本信息，将所述工作流实例重新分配至其他工作流客户端执行。

可选地，应用在工作流服务端的工作流执行方法还包括：

若监测到所述工作流客户端不可用，则依据存储的所述基本信息，将所述工作例客户端上执行的所有工作流实例重新分配至其他工作流客户端执行。

可选地，所述工作流服务端为工作流服务集群中的一服务节点，所述工作流服务集群中包含主服务节点及多个从服务节点；

相应地，所述存储所述基本信息，包括：

在所述工作流服务端为所述主服务节点的情况下，控制各个所述从服务节点存储所述基本信息；

在所述工作流服务端为所述从服务节点的情况下，在所述从服务节点本地存储所述基本信息，并向所述主服务节点发送存储通知，以触发所述主服务节点将所述基本信息存储至其他从服务节点。

一种工作流执行方法，应用于工作流客户端，该方法包括：

创建工作流实例后，将所述工作流实例的基本信息上传至工作流服务端，所述基本信息包括所述工作流实例的元数据及初始状态；

执行所述工作流实例；

将所述工作流实例的执行结果上传至所述工作流服务端。

可选地，所述执行所述工作流实例包括：

接收所述工作流服务端存储所述工作流实例的基本信息的存储结果；

在所述存储结果为成功的情况下，执行所述工作流实例。

可选地，所述工作流实例包括多个任务；相应地，在执行所述工作流实例时，该方法还包括：

将所述任务的执行结果上传至所述工作流服务端。

一种工作流服务端，包括：

基本信息接收单元，用于接收工作流客户端上传的工作流实例的基本信息，所述基本信息包括所述工作流实例的元数据及初始状态；

基本信息存储单元，用于存储所述基本信息。

可选地，工作流服务端还包括：

存储结果返回单元，用于向所述工作流客户端返回存储结果；其中，所述存储结果为成功的情况下，用于触发所述工作流客户端执行所述工作流实例。

可选地，所述工作流实例包括多个任务，相应地，该工作流服务端还包括：

任务执行结果存储单元，用于存储所述工作流客户端上传的所述任务的执行结果。

可选地，每个所述任务具有各自的时长阈值；相应地，该工作流服务端还包括：

第一调度单元，用于若所述工作流客户端执行所述多个任务中的目标任务的时长超过对应的时长阈值且所述目标任务的数量超过预设任务阈值，则将所述工作流实例重新分配至其他工作流客户端执行。

可选地，工作流服务端还包括：

第二调度单元，用于若监测到所述工作流客户端不可用，则将所述工作例客户端上执行的所有工作流实例重新分配至其他工作流客户端执行。

可选地，所述工作流服务端为工作流服务集群中的一服务节点，所述工作流服务集群中包含主服务节点及多个从服务节点；

相应地，所述基本信息存储单元包括：

第一存储子单元，用于在所述工作流服务端为所述主服务节点的情况下，控制各个所述从服务节点存储所述基本信息；

第二存储子单元，用于在所述工作流服务端为所述从服务节点的情况下，在所述从服务节点本地存储所述基本信息，并向所述主服务节点发送存储通知，以触发所述主服务节点将所述基本信息存储至其他从服务节点。

一种工作流客户端，包括：

基本信息上传单元，用于创建工作流实例后，将所述工作流实例的基本信息上传至工作流服务端，所述基本信息包括所述工作流实例的元数据及初始状态；

工作流实例执行单元，用于执行所述工作流实例；

执行状态上传单元，用于将所述工作流实例的执行状态上传至所述工作流服务端。

可选地，所述工作流实例执行单元包括：

存储结果接收子单元，用于接收所述工作流服务端存储所述工作流实例的基本信息的存储结果；

工作流实例执行子单元，用于在所述存储结果为成功的情况下，执行所述工作流实例。

可选地，所述工作流实例包括多个任务；相应地，工作流客户端还包括：

执行结果上传单元，用于在执行所述工作流实例时，将所述任务的执行结果上传至所述工作流服务端。

一种工作流执行系统，包括：

工作流客户端，用于创建工作流实例后，将所述工作流实例的基本信息上传至工作流服务端，执行所述工作流实例；

所述工作流服务端，用于接收所述工作流实例的基本信息并进行存储，以及若监测到所述工作流客户端未成功执行所述工作流实例，依据所述基本信息，重新调度所述工作流实例。

由以上技术方案可知，本申请提供了一种应用在工作流服务端上的工作流执行方法，该方法中，工作流服务端并未参与工作流实例的执行过程，而仅仅保存工作流实例的基本信息，既提高了工作流实例的执行效率也保证了工作流实例执行的稳定性。

附图说明

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

图1为本申请提供的工作流执行系统的一个具体示例图；

图2为本申请提供的应用在工作流服务端及工作流客户端上的工作流执行方法的流程图；

图3为本申请提供的应用在工作流服务端上的工作流执行方法实施例1的流程图；

图4为本申请提供的工作流服务端在出错情况下重新调度工作流实例的流程图；

图5为本申请提供的应用在工作流客户端上的工作流执行方法实施例1的流程图；

图6为本申请提供的工作流服务端实施例1的结构示意图；

图7为本申请提供的工作流服务端实施例2的结构示意图；

图8为本申请提供的工作流客户端实施例1的结构示意图；

图9为本申请提供的工作流执行系统的结构示意图。

具体实施方式

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

为了保证工作流执行方法在实际中的应用及实现，本申请提供了一种工作流执行系统。参见图1，其示出了工作流执行系统的一个具体示例。如图1所示，工作流执行系统可以包括：多个工作流服务端及多个工作流客户端。其中，多个工作流服务端属于一工作流服务集群，该工作流服务集群可以是使用分布式技术部署的服务集群。

任意一工作流服务端与任意一工作流客户端可以作为一对设备，用来实现工作流执行方法。

参见图2，其示出了应用在某一对工作流服务端及工作流客户端上的工作流执行方法的具体流程。

如图2所示，该工作流执行方法的具体流程可以包括：步骤S21～步骤S26。

步骤S21：工作流客户端向工作流服务端上传工作流实例的基本信息。

具体地，工作流客户端上定义有工作流，工作流可以被拆分为多个任务，工作流客户端在执行该工作流前，首先需要将工作流的各个任务实例化，实例化后的任务可以组成工作流实例。

为了帮助理解，以下打比方说明工作流及工作流实例之间的关系。

将工作流比作做家务，家务包括打扫卫生和洗衣服。工作流的实例化，即将做家务具体分配给某个人，并且为其规定打扫卫生及洗衣服的具体内容，如打扫卫生的时间、负责打扫哪些地方的卫生、洗衣服的时间、洗哪些衣服等等。工作流经过上述具体限定后便可以称为一个工作流实例。

当然，一个工作流可以实例化为不同的工作流实例，就比如，上述做家务的工作可以分配给不同的人去完成，并且为不同的人规定不同的具体内容。

工作流实例的基本信息，可以包括工作流实例的元数据及初始状态。其中，工作流实例的元数据用来表示该工作例实例的基本属性，如包括哪些任务、任务执行的先后顺序、该任务的具体内容。工作流实例的初始状态，即该工作流实例在被执行前的状态。在一个具体示例中，该初始状态可以包括初始执行状态(即未执行)及初始执行的上下文。

步骤S22：工作流服务端存储基本信息。

工作流服务端接收到工作流客户端上传的基本信息后，在工作流服务端本地存储该基本信息。当然，该工作流服务端所在的工作流服务集群中的其他服务节点也可以存储该基本信息，具体的实现方式可以参见下文详细说明，此处并不赘述。

现有的单机版的工作流执行设备，从工作流的定义到执行均在单台的设备上完成，容灾性能较差。然而，本申请中，工作流客户端上的工作流实例的基本信息可以被保存至工作流服务端，这样，可以实现轻量且较为稳定的工作流客户端，且若工作流服务端监测到工作流客户端未成功执行工作流实例，可以根据工作流服务端上保存的基本信息，实现工作流的重新调度。

步骤S23：工作流服务端向工作流客户端返回存储结果。

可以理解的是，工作流服务端存储基本信息时，可能成功也可能失败。将成功或失败的存储结果返回工作流客户端。若存储结果为成功，该存储结果还用于触发工作流客户端执行工作流实例。

步骤S24：工作流客户端判断存储结果为成功还是失败，若为成功，工作流客户端执行步骤S25，若为失败，则结束流程。

工作流客户端在实例化工作流后，将工作流实例的基本信息保存至工作流服务端。工作流服务端若未保存成功，则向工作流客户端返回保存失败的信息，工作流客户端接收到该保存失败的信息后，结束流程。

步骤S25：工作流客户端执行工作流实例。

工作流客户端在工作流服务端成功存储基本信息的情况下，才执行工作流实例。当然，工作流客户端还可以在上传基本信息后，便执行工作流实例，以提高工作流实例执行的高效性。

其中，工作流实例中包括多个任务，该多个任务具有预设的执行方式如并行执行或串行执行等，并且任务的具体内容也已经被预先设置，因此，工作流客户端按照预先设置，执行工作流实例即可。

现有的服务化版工作流执行系统中，客户端每个任务的执行均由服务器调度分配。该种执行方式的工作流执行效率较低，并且实现复杂度较高。然而，本实施例中，工作流客户端执行工作流实例时，并不需要工作流服务端的调度，而均是由自身完成的，该种工作流执行方式效率更高且实现方式简单。

步骤S26：工作流客户端向工作流服务端上传工作流实例的执行状态，该执行状态为成功或失败。

虽然，工作流服务端并未参与工作流客户端执行工作流实例的过程，但是，工作流客户端需要将工作流实例的执行状态(工作流实例的最终完成情况)返回工作流服务端保存。工作流服务端保存的执行状态，以供工作流客户端进行查询。

综上所述，与单机版的工作流执行方法相比，本实施例中，工作流客户端将工作流实例的基本信息发送至工作流服务端保存，基本信息用于出错时的重新调度，从而提高了工作流客户端的容灾性，也保证了工作流实例的成功执行。

与服务化版的工作流执行方法相比，本实施例中，工作流服务端并未对工作流客户端执行工作流实例的过程进行调度，而是由工作流客户端独立执行工作流实例。可见，本实施例中的工作流实例的执行效率较高。

结合图1中的工作流服务端1及工作流客户端1，对本申请的技术方案进行举例说明。

工作流客户端1上预先存储的一个工作流定义是，创建虚拟机。此工作流定义包括：分配资源、分配网络、创建防火墙等几个任务。

工作流客户端1接收到用户创建虚拟机的请求后，确定与创建虚拟机相关的信息，如虚拟机名称、用户名称、所在安全组ID、所在集群、虚拟机配置等。

工作流客户端1根据上述信息及创建虚拟机的工作流定义，建立一个创建虚拟机的工作流实例。

工作流实例建立后，工作流客户端1将该工作流实例的基本信息，即虚拟机名称、用户名称、所在安全组ID、所在集群、虚拟机配置等发送至工作流服务端1进行存储。在工作流客户端1未能成功执行该工作流实例时，工作流服务端1可以使用存储的基本信息，将该工作流实例重新调度至其他工作流客户端如工作流客户端2上执行，以提高工作流客户端1的容灾性。

工作流服务端1属于工作流服务集群中的一个节点，其可以将接收到的基本信息同步到该集群中的其他节点上，以保证该集群的各个节点上数据的一致性。

需要说明的是，与现有技术相比，工作流客户端1上传基本信息后，并不等待工作流服务端1的调度，直接独立地在本地执行该工作流实例的每个任务。这样，既可以减轻工作流服务端的调度负担，还可以保证工作流实例的高效执行。

工作流客户端1每执行完一个任务后，可以将任务的执行结果上传到工作流服务端1，当然，为了执行效率，也可以选择不上传。

另外，工作流服务端1可以监测工作流客户端1的工作流实例执行过程，若发现工作流客户端1掉线或者执行超时，则工作流服务端1会将该工作例实例重新调度给其他工作流客户端，以使其他的工作流客户端执行该工作流实例。

以上从工作流执行系统的角度介绍了工作流执行方法，以下分别说明应用在工作流服务端及工作流客户端上的工作流执行方法。

参见图3，其示出了应用在工作流服务端上的工作流执行方法实施例1的流程。如图3所示，本实施例可以具体包括步骤S31～步骤S33。

步骤S31：接收工作流客户端上传的工作流实例的基本信息；其中，基本信息包括工作流实例的元数据及初始状态。

如上述步骤S21的说明，工作流实例的元数据用来表示该工作例实例的基本属性，工作流实例的初始状态即表示该工作流实例在被执行前的状态。在一个具体示例中，初始状态可以具体包括初始执行状态(即未执行)及初始执行的上下文。

步骤S32：存储基本信息。

具体地，在存储过程中，工作流服务端可以使用一致性算法完成对基本信息的一致性及持久化处理。一致性算法主要应用在分布式场景中。具体地，在分布式系统中，为保证每个节点执行相同的命令序列，需要在每一条指令上执行“一致性算法”以使每个节点执行的指令一致。一致性算法可以是但不限定于raft算法，raft算法主要是在保证在分布式的条件下，所有的节点可以执行相同的命令序列，并达到一致的状态。

使用一致性算法可以将基本信息存储到工作流服务集群的多个服务节点中，且保证各个服务节点均能成功存储该基本信息。这样，工作流客户端在任意一服务节点上读取基本信息时，并不会出现脏读现象。需要说明的是，该协议为现有的协议，本申请并未对其进行改进。

需要说明的是，保存在工作流服务端的基本信息可以在工作流实例执行过程中出现问题后，用于工作流服务端重新对该工作流实例进行调度，从而保证工作流实例的稳定执行。

步骤S33：向工作流客户端返回存储结果。

若存储结果为成功，则可用于触发工作流客户端执行工作流实例。或者，工作流服务端也可以并不向工作流客户端返回存储结果，这样，可以进一步减少工作流服务端与工作流客户端之间的交互，实现更加轻量化的工作流服务端。

又或者，工作流服务端向工作流客户端返回存储结果，但工作流客户端并不依赖于存储结果来执行工作流实例。换句话说，工作流客户端向工作流服务端上传基本信息后，并不需等待工作流服务端对基本信息的存储结果，便可以执行工作流实例。

需要说明的是，有关步骤S31～步骤S33的说明可以参见上述应用在工作流执行系统的说明，此处并不赘述。

由以上的技术方案可知，本实施例提供了一种应用在工作流服务端上的工作流执行方法，该方法中，工作流服务端并未参与工作流实例的执行过程，而仅仅保存工作流实例的基本信息，既提高了工作流实例的执行效率也保证了工作流实例执行的稳定性。

如上述图1所示，工作流服务端可以是工作流服务集群中的一个服务节点，该工作流服务集群中可以包括多个服务节点，此些服务节点中某一个服务节点作为主服务节点，其他可以作为从服务节点。

工作流服务集群可以是应用分布式技术的集群，该多个服务节点可以使用分布式技术对数据进行备份，可以理解的是，为了保证对外提供数据的一致性，需要将数据同步保存至各个从服务节点中。在本申请的具体应用场景中，数据即指的是工作流客户端上传的数据，该数据可以称为工作流实例数据，其中可以包括但不限定于：工作流实例的基本信息、工作流实例的执行状态。

工作流实例数据接收者的不同，则存储工作流实例数据的方式不同。

若接收到工作流实例数据的工作流服务端是主服务节点，则该工作流服务端控制每个从服务节点均在本地存储工作流实例数据。

若接收到工作流实例数据的工作流服务端是从服务节点，则该工作流服务端在本地存储工作流实例数据，并且向主服务节点发送存储通知，该存储通知用于触发主服务节点将基本信息存储在每个其他从服务节点上。

以上两种存储方式中，工作流服务端会在每个从服务节点上均存储工作流实例数据，从而可以保证工作流客户端在每个服务节点上访问的工作流实例数据不会出现错误，保证了数据的一致性。

在实际应用中，工作例实例可以包括多个任务，工作流客户端可以每执行一个任务，便将任务的执行结果上传至工作流服务端。根据实际的执行情况，执行结果可以是成功或者失败。

这样，工作流客户端上传的数据不仅包括工作流实例的基本信息、工作流实例的执行状态，还可以包括工作流实例中任务的执行结果。工作流服务端存储该执行结果，以供工作流客户端的后续查询。或者，在执行结果为失败的情况下，工作流服务端可以重新调度该工作流实例，以保证工作流实例的成功执行。

当然，工作流客户端可以不必上传每个任务的执行结果，而是根据预先设置，上传某个或某些任务的执行结果，以提高工作流执行效率。

具体地，参见图4，其示出了工作流服务端在出错情况下重新调度工作流实例的流程。如图4所示，该流程可以具体包括步骤S41～步骤S43。

步骤S41：对工作流客户端执行工作流实例的过程进行监测；若工作流客户端不可用，则执行步骤S42；若工作流客户端执行目标任务的时长超过预设时长阈值且目标任务的数量超过预设任务阈值，则执行步骤S43。

其中，工作流服务器监测到工作流客户端未成功执行工作流实例的情况可能以下两种情况之一：工作流客户端不可用、工作流客户端执行任务的时长超过预设时长阈值且超过预设时长阈值的任务的个数也超过预设任务阈值。出现以上两种情况中的任意一种，则工作流服务端会重新调度工作流实例。情况不同，工作流服务端重新调度的方式也不同，具体参见步骤S42及步骤S43。

工作流服务端可以监测工作流客户端的连接心跳，若发现连接心跳丢失，且丢失时长超过预设时长，则可以确定工作流客户端处于不可用状态。此种情况下，需要执行步骤S42。当然，工作流客户端的不可用状态并非仅指掉线，还可以是本领域技术人员可以理解的其他状态如故障等。

另外，工作流服务端可以预先为每个任务均设置各自所对应的时长阈值，设置的时长阈值可以相同也可以不同。工作流服务端监测工作流客户端执行任务的时长，若发现工作流客户端执行某个任务所用的时长超过预设的时长阈值，则表示该任务出现错误。为了便于描述，可以将该出现错误的任务称为目标任务。并且，判断目标任务的数量是否达到预设任务阈值，若达到，则需要执行步骤S43。若未达到，则可以触发本工作流客户端重新执行该工作流实例。

步骤S42：将工作流客户端上执行的所有工作流实例重新分配至工作流客户端之外的其他工作流客户端执行。

前已述及，工作流实例的基本信息包括工作流实例的元数据，根据该元数据，可以确定掉线的该工作流客户端上所执行的工作流实例为哪个工作流实例。从而，工作流服务端可以根据基本信息，将该基本信息表示的工作流实例分配给其他工作流客户端。具体实现可以有以下几种方式。

在一个示例中，工作流服务端可以根据基本信息建立工作流实例，并将该工作流实例发送给其他工作流客户端执行。

在另一示例中，工作流服务端可以将基本信息发送给工作流客户端，以使工作流客户端根据该基本信息建立工作流实例并执行。

在又一示例中，工作流服务端可以在确定其他工作流客户端后，指示该其他工作流客户端从步骤S41中的工作流客户端处获取该基本信息表示的工作流实例并执行。

工作流客户端上执行的工作流实例可以并未一个，在有多个的情况下，则将工作流客户端上所有的工作流实例均分配至其他的工作流客户端执行。

步骤S43：将工作流实例重新分配至工作流客户端之外的其他工作流客户端执行。

在目标任务出现问题的情况下，只需将出现问题的工作流实例分配至其他工作流客户端执行即可。因此，可以根据预先存储的工作流实例的基本信息中的元数据，确定出出现问题的工作流实例为哪个工作流实例，并根据该工作流实例的基本信息中的执行上下文等内容，将该工作流实例重新分配至其他工作流客户端执行。

由以上的技术方案可知，本申请提供的工作流执行方法，并不参与工作流实例的正常执行过程，只有在工作流实例执行出现问题时，才会对工作流实例重新调度。

以上介绍了应用在工作流服务端上的工作流执行方法，以下对应用在工作流客户端上的工作流执行方法进行说明。

参见图5，其示出了应用在工作流客户端上的工作流执行方法实施例1的流程。如图5所示，该工作流执行方法实施例1可以具体包括步骤S51～S54。

步骤S51：创建工作流实例后，将工作流实例的基本信息上传至工作流服务端存储。

基本信息包括工作流实例的元数据及初始状态。

工作流客户端上可以定义工作流，工作流在执行前，需要被实例化。工作流被实例化后，工作流客户端将工作流实例的基本信息上传至工作流服务端保存。

步骤S52：接收工作流服务端的存储结果。

工作流服务端存储基本信息后的存储结果可以返回工作流客户端。该存储结果可能是成功，也可能是失败。

步骤S53：在存储结果为成功的情况下，执行工作流实例。

当然，工作流客户端上传工作流的基本信息后，也可以并不根据基本信息的存储结果，来决定是否执行工作流实例。因此，在另一个示例中，工作流客户端向工作流服务端上传基本信息后，便执行工作流实例。这样，可以保证工作流实例执行过程的流畅性。

步骤S54：将工作流实例的执行状态上传至工作流服务端。

需要说明的是，有关本实施例的说明可以参见上文有关应用在工作流执行系统上的工作流执行方法及应用在工作流服务端上的工作例执行方法，此处并不赘述。

当然，工作流客户端在执行工作流的各个任务时，还可以将任务的执行结果上传至工作流服务端存储。具体地，可以每执行一个任务，便上传该任务的执行结果。根据实际执行情况，该执行结果可以是成功或失败。

以下对本申请提供的工作流执行装置进行介绍，需要说明的是，下文有关工作流执行装置的说明可以参见上文提供的工作流执行方法，以下并不赘述。

与上述应用在工作流服务端的工作流执行方法实施例1相对应，本申请提供了一种工作流服务端实施例1。如图6所示，该工作流服务端实施例1可以具体包括：基本信息接收单元61、基本信息存储单元62及存储结果返回单元63。

基本信息接收单元61，用于接收工作流客户端上传的工作流实例的基本信息；其中，基本信息包括工作流实例的元数据及初始状态；

基本信息存储单元62，用于存储基本信息；

存储结果返回单元63，用于向工作流客户端返回存储结果；其中，存储结果为成功的情况下，用于触发工作流客户端执行工作流实例。

由以上的技术方案可知，本实施例提供的工作流服务端并未参与工作流实例的执行过程，而仅仅保存工作流实例的基本信息，既提高了工作流实例的执行效率也保证了工作流实例执行的稳定性。

另一种工作流服务端可以包括，基本信息接收单元61及基本信息存储单元62。缺省存储结果返回单元63，可以实现更加轻量化的工作流服务端。

在实际应用中，如图1所示，工作流服务端可以为工作流服务集群中的一服务节点，工作流服务集群中包含主服务节点及多个从服务节点；

相应地，基本信息存储单元62可以具体包括：第一存储子单元及第二存储子单元。

第一存储子单元，用于在工作流服务端为主服务节点的情况下，控制各个从服务节点存储基本信息；

第二存储子单元，用于在工作流服务端为从服务节点的情况下，在从服务节点本地存储基本信息，并向主服务节点发送存储通知，以触发主服务节点将基本信息存储至其他从服务节点。

在实际应用中，工作流实例包括多个任务，相应地，工作流服务端还可以包括：任务执行结果存储单元。

任务执行结果存储单元，用于存储工作流客户端上传的任务的执行结果。

进一步地，每个任务具有各自的时长阈值；相应地，参见图7所示的工作流服务端实施例2的结构，该工作流服务端在图6所示的工作流服务端实施例1的基础上，还可以具体包括：第一调度单元64及第二调度单元65。

第一调度单元64，用于若所述工作流客户端执行所述多个任务中的目标任务的时长超过对应的时长阈值且所述目标任务的数量超过预设任务阈值，则将所述工作流实例重新分配至其他工作流客户端执行。

第二调度单元65，用于若监测到所述工作流客户端不可用，则将所述工作例客户端上执行的所有工作流实例重新分配至其他工作流客户端执行。

见图8，其示出了工作流客户端实施例1的结构。如图8所示，该工作流客户端可以具体包括：基本信息上传单元81、工作流实例执行单元82及执行状态上传单元83。

基本信息上传单元81，用于创建工作流实例后，将工作流实例的基本信息上传至工作流服务端，基本信息包括工作流实例的元数据及初始状态；

工作流实例执行单元82，用于执行工作流实例；

执行状态上传单元83，用于将工作流实例的执行状态上传至工作流服务端。

具体地，工作流实例执行单元可以包括：存储结果接收子单元、及工作流实例执行子单元。

存储结果接收子单元，用于接收工作流服务端存储工作流实例的基本信息的存储结果；

工作流实例执行子单元，用于在存储结果为成功的情况下，执行工作流实例。

可以理解的是，工作流实例包括多个任务；相应地，工作流客户端还可以具体包括：执行结果上传单元。

执行结果上传单元，用于在执行工作流实例时，将任务的执行结果上传至工作流服务端。

见图9，其示出了工作流执行系统的一种结构示意。如图9所示，工作流执行系统具体包括：工作流服务端及多个工作流客户端(工作流客户端1、工作流客户端2……工作流客户端N)。

以工作流客户端1为例，说明工作流客户端的具体结构，其他工作流客户端参照此结构，并不赘述。

工作流客户端1可以具体包括基本信息上传单元81、及工作流实例执行单元82。工作流服务端可以具体包括基本信息接收单元61、基本信息存储单元62、第一调度单元64、及第二调度单元65。

具体地，工作流客户端1与工作流服务端通过网络相连后，工作流客户端1的基本信息上传单元81可以与工作流服务器的基本信息接收单元61通信。基本信息上传单元81用于创建工作流实例后，将工作流实例的基本信息上传至工作流服务器，基本信息接收单元61用于接收所述基本信息。

在工作流服务端一侧，基本信息存储单元62与基本信息接收单元61相连，用于存储基本信息接收单元61接收到的基本信息。存储的基本信息可以用于第一调度单元64及第二调度单元65的重新调度。

其中，第一调度单元64，用于若工作流客户端1执行多个任务中的目标任务的时长超过对应的时长阈值且目标任务的数量超过预设任务阈值，则将工作流实例重新分配至其他工作流客户端执行。

第二调度单元65，用于若监测到工作流客户端1不可用，则将工作例客户端1上执行的所有工作流实例重新分配至其他工作流客户端执行。

以上工作流执行系统中，工作流客户端对工作流实例的执行并不需要工作流服务端，减少了工作流客户端与工作流服务端的交互，提高了工作流实例的执行效率。另外，工作流服务端可以存储基本信息，基本信息用于在工作流实例执行失败后，重新分配工作流实例至其他工作流客户端，从而在提高工作流实例执行效率的基础上，还可以进一步提高工作流实例成功执行的可能性，进而提供工作流执行系统的稳定性。

需要说明的是，在以上结构示例中，工作流服务端缺省存储结果返回单元63，这样，工作流实例执行单元82对工作流实例的执行可以并不依赖于存储结果，而是在基本信息上传单元81上传基本信息后，便执行工作流实例。

此种结构可以减少工作流服务端与工作流客户端之间的交互，实现更加轻量化的工作流服务端，并且可以提高工作流实例的执行效率。

工作流执行系统其他可实现的结构中，工作流服务端还可以包括存储结果返回单元63，其用于将存储结果返回工作流客户端。基于此，工作流客户端中的工作流实例执行单元82，可以接收存储结果，且在执行工作流实例前，判断存储结果为成功还是失败，若为成功则执行工作流实例。

此种结构可以保证在工作流实例的基本信息存储成功的情况下，才触发工作流实例的执行，避免工作流实例由于基本信息存储失败从而重新执行的情况，提高了工作流执行系统的稳定性。

以下对工作流服务端的第一调度单元64执行的重新调度方案进行详细说明。

为了实现工作流服务端第一调度单元64对工作流实例的重新调度，在具体实施中，工作流客户端在上述工作流客户端1的基础上，还可以进一步包括执行结果上传单元84。

工作流客户端中的执行结果上传单元84用于将工作流实例中每个任务的执行结果(成功或者失败)上传至工作流服务端。

在一种实现方式中，工作流服务端中的第一调度单元64可以记录每个任务的执行结果的接收时间。除首个任务以外，任一任务的执行时长可以通过该任务的执行结果的接收时间与前一任务的执行结果的接收时间获得，即将该任务的执行结果的接收时间与前一任务的执行结果的接收时间作差，以得到该任务的执行时长。

需要说明的是，由于工作流客户端上传工作流实例的基本信息后，便开始执行工作流实例。因此，工作流实例中首个任务的执行时长可以通过该任务的接收时间与基本信息的接收时间获得，即将首个任务的执行结果的接收时间与基本信息的接收时间作差，以得到首个任务的执行时长。

第一调度单元64每当获得任务的执行时长后，便判断任务的执行时长是否超过预设时长阈值，若超过预设时长阈值，为了便于描述，可以将执行时长超过预设时长阈值的任务称为目标任务。统计目标任务的总数，并判断目标任务的总数是否超出预设任务阈值，若超过预设任务阈值，则可以将工作流实例重新分配至其他工作流客户端执行。

以上工作流服务端的第一调度单元64，需要记录任务的执行结果的接收时间，并依据接收时间来判断是否需要对工作流实例进行重新调度。当然，除了此种实现方式，第一调度单元64还可以通过以下其他方式实现。

在另一种实现方式中，工作流客户端中的执行结果上传单元84在上传任务的执行结果时，还可以上传任务的执行时长。

这样，第一调度单元64并不需要计算任务的执行时长，直接将执行结果上传单元84上传的任务的执行时长与预设时长阈值进行比较即可，为了便于描述，可以将执行时长超过预设时长阈值的任务称为目标任务。统计目标任务的总数，并判断目标任务的总数是否超出预设任务阈值，若超过预设任务阈值，则可以将该工作流实例重新分配至其他工作流客户端执行。

相较于第一种实现方式，第二种实现方式中，工作流客户端中的执行结果上传单元84计算任务的执行时长并上传至工作流服务端的第一调度单元64。工作流服务端的第一调度单元64直接使用执行结果上传单元84上传的任务的执行时长进行重新调度，可见，工作流客户端的实现方式简单。

需要说明的是，以上两种实现方式中，用于作为比较依据的预设时长阈值可以是一个，也可以是多个。在一个预设时长阈值的情况下，第一调度单元64将所有的任务的执行时长与该同一预设时长阈值进行比较；在多个预设时长阈值的情况下，每个任务的执行时长具有各自所对应的预设时长阈值，第一调度单元64将任务的执行时长与该任务所对应的预设时长阈值进行比较。

以上工作流服务端中的第一调度单元64针对某个工作流实例而言，在该工作流实例的执行过程出现问题的情况下，将该工作流实例重新分配至其他工作流客户端执行。

工作流客户端可能执行多个工作流实例，若工作例客户端出现不可用的情况，则工作流服务端的第二调度单元65可以对工作流客户端上所有的工作流实例进行重新调度。

以下对工作流服务端的第二调度单元65进行详细说明。

具体地，第二调度单元65可以监测工作流服务端与工作流客户端的连接心跳，若发现连接心跳丢失，且丢失时长超过预设时长，则可以确定工作流客户端处于不可用状态。进而，工作流服务端将该工作流客户端上执行的所有工作流实例重新分配至该工作流客户端之外的其他工作流客户端执行。

需要说明的是，工作流服务端上存储有工作流实例的基本信息，第一调度单元64或第二调度单元65在重新分配工作流实例至其他工作流客户端时，可以将存储的基本信息发送至其他工作流客户端，其他工作流实例根据基本信息重新执行工作流实例。

以上图9所示的工作流客户端还可以进一步包括执行状态上传单元83，其用于将工作流实例的执行状态上传至工作流服务端。其中，执行状态可以包括工作流实例的最终执行结果，工作流服务端存储执行状态以供后续查询。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括上述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (24)

1.一种工作流执行方法，其特征在于，包括：

工作流客户端将工作流的各个任务实例化以创建工作流实例，并所述工作流实例的基本信息上传至工作流服务端，并独立执行所述工作流实例；其中，所述基本信息包括所述工作流实例的元数据及初始状态；所述工作流是计算机支持的协同工作流程；

所述工作流服务端接收所述工作流实例的基本信息并进行存储，以及若监测到所述工作流客户端未成功执行所述工作流实例，则依据所述基本信息，重新调度所述工作流实例。

2.根据权利要求1所述的工作流执行方法，其特征在于，还包括：

所述工作流客户端将所述工作流实例的执行状态上传至所述工作流服务端；

所述工作流服务端接收所述执行状态并进行存储。

3.根据权利要求1所述的工作流执行方法，其特征在于，所述工作流实例包括多个任务，该方法还包括：

所述工作流客户端将所述任务的执行结果上传至所述工作流服务端；

所述工作流服务端接收所述执行结果并进行存储。

4.根据权利要求1所述的工作流执行方法，其特征在于，所述工作流服务端若监测到所述工作流客户端未成功执行所述工作流实例，则依据所述基本信息，重新调度所述工作流实例，包括：

所述工作流服务端若监测到所述工作流客户端执行所述工作流实例的多个任务中的目标任务的时长超过对应的时长阈值且所述目标任务的数量超过预设任务阈值，则依据存储的所述基本信息，将所述工作流实例重新分配至其他工作流客户端执行。

5.根据权利要求1所述的工作流执行方法，其特征在于，所述工作流服务端若监测到所述工作流客户端未成功执行所述工作流实例，则依据所述基本信息，重新调度所述工作流实例，包括：

所述工作流服务端若监测到所述工作流客户端不可用，则依据存储的所述基本信息，将所述工作例客户端上执行的所有工作流实例重新分配至其他工作流客户端执行。

6.一种工作流执行方法，其特征在于，应用于工作流服务端，该方法包括：

接收工作流客户端上传的工作流实例的基本信息；其中，所述基本信息包括所述工作流实例的元数据及初始状态；所述工作流实例由工作流客户端将工作流的各个任务实例化而创建，并由所述工作流客户端独立执行；所述工作流是计算机支持的协同工作流程；

存储所述基本信息，以用于若监测到所述工作流客户端未成功执行所述工作流实例，则依据所述基本信息，重新调度所述工作流实例。

7.根据权利要求6所述的工作流执行方法，其特征在于，在所述存储所述基本信息之后，还包括：

向所述工作流客户端返回存储结果；其中，所述存储结果为成功的情况下，用于触发所述工作流客户端执行所述工作流实例。

8.根据权利要求6所述的工作流执行方法，其特征在于，所述工作流实例包括多个任务，相应地，该方法还包括：

存储所述工作流客户端上传的所述任务的执行结果。

9.根据权利要求8所述的工作流执行方法，其特征在于，每个所述任务具有各自的时长阈值；相应地，该方法还包括：

若所述工作流客户端执行所述多个任务中的目标任务的时长超过对应的时长阈值且所述目标任务的数量超过预设任务阈值，则依据存储的所述基本信息，将所述工作流实例重新分配至其他工作流客户端执行。

10.根据权利要求6所述的工作流执行方法，其特征在于，还包括：

若监测到所述工作流客户端不可用，则依据存储的所述基本信息，将所述工作例客户端上执行的所有工作流实例重新分配至其他工作流客户端执行。

11.根据权利要求6所述的工作流执行方法，其特征在于，所述工作流服务端为工作流服务集群中的一服务节点，所述工作流服务集群中包含主服务节点及多个从服务节点；

相应地，所述存储所述基本信息，包括：

在所述工作流服务端为所述主服务节点的情况下，控制各个所述从服务节点存储所述基本信息；

在所述工作流服务端为所述从服务节点的情况下，在所述从服务节点本地存储所述基本信息，并向所述主服务节点发送存储通知，以触发所述主服务节点将所述基本信息存储至其他从服务节点。

12.一种工作流执行方法，其特征在于，应用于工作流客户端，该方法包括：

将工作流的各个任务实例化以创建工作流实例，并将所述工作流实例的基本信息上传至工作流服务端，所述基本信息包括所述工作流实例的元数据及初始状态；所述工作流是计算机支持的协同工作流程；

独立执行所述工作流实例；

将所述工作流实例的执行状态上传至所述工作流服务端，以用于若监测到所述工作流客户端未成功执行所述工作流实例，则依据所述基本信息，重新调度所述工作流实例。

13.根据权利要求12所述的工作流执行方法，其特征在于，所述执行所述工作流实例包括：

接收所述工作流服务端存储所述工作流实例的基本信息的存储结果；

在所述存储结果为成功的情况下，执行所述工作流实例。

14.根据权利要求12所述的工作流执行方法，其特征在于，所述工作流实例包括多个任务；相应地，在执行所述工作流实例时，该方法还包括：

将所述任务的执行结果上传至所述工作流服务端。

15.一种工作流服务端，其特征在于，包括：

基本信息接收单元，用于接收工作流客户端上传的工作流实例的基本信息，所述基本信息包括所述工作流实例的元数据及初始状态；所述工作流实例由工作流客户端将工作流的各个任务实例化而创建，并由所述工作流客户端独立执行；所述工作流是计算机支持的协同工作流程；

基本信息存储单元，用于存储所述基本信息，以用于若监测到所述工作流客户端未成功执行所述工作流实例，则依据所述基本信息，重新调度所述工作流实例。

16.根据权利要求15所述的工作流服务端，其特征在于，还包括：

存储结果返回单元，用于向所述工作流客户端返回存储结果；其中，所述存储结果为成功的情况下，用于触发所述工作流客户端执行所述工作流实例。

17.根据权利要求15所述的工作流服务端，其特征在于，所述工作流实例包括多个任务，相应地，该工作流服务端还包括：

任务执行结果存储单元，用于存储所述工作流客户端上传的所述任务的执行结果。

18.根据权利要求17所述的工作流服务端，其特征在于，每个所述任务具有各自的时长阈值；相应地，该工作流服务端还包括：

第一调度单元，用于若所述工作流客户端执行所述多个任务中的目标任务的时长超过对应的时长阈值且所述目标任务的数量超过预设任务阈值，则将所述工作流实例重新分配至其他工作流客户端执行。

19.根据权利要求15所述的工作流服务端，其特征在于，还包括：

第二调度单元，用于若监测到所述工作流客户端不可用，则将所述工作例客户端上执行的所有工作流实例重新分配至其他工作流客户端执行。

20.根据权利要求15所述的工作流服务端，其特征在于，所述工作流服务端为工作流服务集群中的一服务节点，所述工作流服务集群中包含主服务节点及多个从服务节点；

相应地，所述基本信息存储单元包括：

第一存储子单元，用于在所述工作流服务端为所述主服务节点的情况下，控制各个所述从服务节点存储所述基本信息；

第二存储子单元，用于在所述工作流服务端为所述从服务节点的情况下，在所述从服务节点本地存储所述基本信息，并向所述主服务节点发送存储通知，以触发所述主服务节点将所述基本信息存储至其他从服务节点。

21.一种工作流客户端，其特征在于，包括：

基本信息上传单元，用于将工作流的各个任务实例化以创建工作流实例，并将所述工作流实例的基本信息上传至工作流服务端，所述基本信息包括所述工作流实例的元数据及初始状态；所述工作流是计算机支持的协同工作流程；

工作流实例执行单元，用于独立执行所述工作流实例；

执行状态上传单元，用于将所述工作流实例的执行状态上传至所述工作流服务端。

22.根据权利要求21所述的工作流客户端，其特征在于，所述工作流实例执行单元包括：

存储结果接收子单元，用于接收所述工作流服务端存储所述工作流实例的基本信息的存储结果；

工作流实例执行子单元，用于在所述存储结果为成功的情况下，执行所述工作流实例。

23.根据权利要求21所述的工作流客户端，其特征在于，所述工作流实例包括多个任务；相应地，工作流客户端还包括：

执行结果上传单元，用于在执行所述工作流实例时，将所述任务的执行结果上传至所述工作流服务端。

24.一种工作流执行系统，其特征在于，包括：

工作流客户端，用于将工作流的各个任务实例化以创建工作流实例，并将所述工作流实例的基本信息上传至工作流服务端，独立执行所述工作流实例；所述工作流是计算机支持的协同工作流程；

所述工作流服务端，用于接收所述工作流实例的基本信息并进行存储，以及若监测到所述工作流客户端未成功执行所述工作流实例，依据所述基本信息，重新调度所述工作流实例。

Images