一种调度方法及系统、工作节点及监控节点与流程

本申请涉及计算机技术领域，特别是涉及一种调度方法及系统、一种工作节点、一种监控节点。

背景技术：

在云产品管控平台接收到用户请求后，可能存在一系列的工作流以完成该用户请求，比如以创建虚机为例，该请求需要调用存储、网络、虚拟化等各个模块完成用户请求，整个服务调用会跨越多个外部业务系统。那么对于一个工作流而言，如果其未完成，那么对于用户而言，由于相应请求无法被完成导致需要重新提交请求或者通过工单要求恢复。对于系统而言，工作流运行到一半可能导致有某些中间的资源无法被释放，出现孤立的资源导致系统不一致。上述问题如果不解决，会导致开发团队花费大量的精力来解决各种客户问题、系统问题，效率很低。

在先技术中，亚马逊提供了一种云服务amazonsimpleworkflowservice(亚马逊简单工作流服务，简称aws)，该云服务将应用程序划分为两个部分：决策程序(decider)和活动程序(activity)。决策程序决定用户的请求应该做什么，活动程序负责执行具体的业务逻辑。活动程序轮询aws任务列表上的活动任务，然后执行活动任务，报告活动任务检测信号。决策程序轮询aws获得决策任务，然后根据预置的协作逻辑做出决策返回aws。在该框架下，当活动程序出现问题时，aws无法接收到活动程序的反馈，所以aws可以通过超时机制来判断活动是否出现问题，如果出现问题，则aws会为该超时事件创建一个决策任务，决策程序从aws获取该任务，然后决定下一步具体的执行逻辑。当决策程序出现问题，aws也会通过超时检测来判断决策程序是否正常，如果不正常则执行相应的failover机制。其中，aws的failover机制是通过超时来判断，比如一个活动执行过程中，负责执行的活动节点失联，后端服务会限定该活动的最大执行时间，如果超过该时间，则认为活动执行超时，会重新创建一个新的活动来执行。

然而，aws上述过程，决策程序与活动程序需要反复与aws交互，决策程序与活动程序各自要通过http(hypertexttransferprotocol，超文本传输协议)接口从aws获取任务，提交任务结果。因此，上述这些操作由于需要反复的服务交互，每一个活动执行需要四次http交互，效率很低，对于活动的监控和恢复过程的处理逻辑也很复杂。

技术实现要素：

鉴于上述问题，本申请实施例提供调度方法及装置，以对工作流实例的执行过程数据进行记录，然后以监控节点监控各工作节点的运行状态，从而在工作节点失联时根据该工作节点的记录的记录，将未完成的工作流实例调度给一正常的工作节点中重建以继续执行，解决在先技术无法保证用户请求执行效率同时保证高可靠的问题。

为了解决上述问题，本申请实施例公开了一种调度方法，其特征在于，包括：

监控节点将用户请求发送给一处于可用状态的工作节点；

所述处于可用状态的工作节点创建对应所述用户请求的工作流实例；

所述处于可用状态的工作节点将所述工作流实例的执行过程数据进行记录；

所述监控节点监控多个工作节点的运行状态数据；

监控节点基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点；

所述另一处于可用状态的工作节点，根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据进行记录。

本申请实施例还公开了一种调度方法，应用于工作节点，包括：

接收监控节点发送的用户请求；

创建对应所述用户请求的工作流实例；

将所述工作流实例的执行过程对应当前工作节点进行记录；

接收监控节点发送的处于不可用状态的工作节点的未完成的工作流实例；

根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据对应当前工作节点进行记录。

本申请实施例还公开了一种调度方法，应用于监控节点，包括：

将用户请求发送给一处于可用状态的工作节点，以使所述工作节点创建工作流实例；

监控多个工作节点的运行状态数据；

基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点。

相应的，本申请实施例还公开了一种对应系统架构层级的调度方法装置，包括：

监控节点、至少两个工作节点；

所述监控节点包括：

用户请求处理模块，用于将用户请求发送给一处于可用状态的工作节点；

工作节点监控模块，用于监控多个工作节点的运行状态数据；

调度模块，用于基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点。

每个所述工作节点包括：

实例创建模块，用于创建对应所述用户请求的工作流实例；

第一执行模块，用于将所述工作流实例的执行过程对应当前工作节点进行记录；

第二执行模块，用于根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据对应当前工作节点进行记录。

相应的，本申请实施例还公开了一种工作节点，包括：

用户请求接收模块，用于接收监控节点发送的用户请求；

实例创建模块，用于创建对应所述用户请求的工作流实例；

第一执行模块，用于将所述工作流实例的执行过程对应当前工作节点进行记录；

未完成实例接收模块，用于接收监控节点发送的处于不可用状态的工作节点的未完成的工作流实例；

第二执行模块，用于根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据对应当前工作节点进行记录。

相应的，本申请实施例还公开了一种监控节点，包括：

用户请求处理模块，用于将用户请求发送给一处于可用状态的工作节点，以使所述工作节点创建工作流实例；

工作节点监控模块，用于监控多个工作节点的运行状态数据；

调度模块，用于基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点。

本申请还公开了一种装置，其特征在于，包括：

一个或多个处理器；和

其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行前述应用于工作节点的调度方法或使得所述装置执行前述应用于监控节点的调度方法。

一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行前述应用于工作节点的调度方法或使得装置执行前述应用于监控节点的调度方法。

本申请实施例包括以下优点：

本申请实施例通过划分工作节点和监控节点，由工作节点执行用户请求对应的工作流实例，并将执行该工作流实例的过程中的执行过程数据进行记录，比如记录到一存储空间。然后由监控节点监控各个工作节点的运行状态，当监控到一工作节点处于不可用状态，则利用前述记录的该不可用状态的工作节点的工作流实例的相关历史记录，将该不可用状态工作节点的未完成工作流实例调度给其他处于可用状态的工作节点，该可用状态的工作节点则可以利用前述记录的该不可用状态的工作节点的工作流实例的相关历史记录重建相应的工作流实例继续执行，如此循环直至工作流实例完成。

那么，上述过程中由于由工作节点本身去执行完整的工作流，其对于一个活动没有决策程序(decider)和活动程序(activity)拉取任务、返回任务结果的四次交互，仅是存储上下文信息至存储空间，提高了活动的执行效率，简化了对于工作流实例的监控和恢复过程的处理逻辑；

并且，由于采用监控节点监控工作节点的状态，然后由监控节点将失联的工作节点中未完成的请求调度到新的工作节点，新的工作节点可以根据存储空间的记录重建相应工作流实例，因此，在前述提高效率的同时还实现了自动对用户请求进行调度，达到高可靠的目的。

附图说明

图1a是本申请的系统架构示意图；

图1b是本申请的节点选择过程示意图；

图1c是本申请的调度方法实施例的步骤流程图；

图2是本申请的对应系统架构层级的调度方法实施例的步骤流程图；

图3是本申请的对应工作节点侧的调度方法实施例的步骤流程图；

图4是本申请的对应监控节点侧的调度方法实施例的步骤流程图；

图5是本申请的对应系统架构层级的调度装置实施例的结构框图；

图6是本申请的工作节点实施例的结构框图；

图7是本申请的监控节点实施例的结构框图；

图8是本申请的服务器实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

对于云产品而言，其云端服务器集群对客户端发送的用户请求，完成该用户请求可能需要一系列执行逻辑，比如用户创建虚拟机的请求，需要调用存储、网络、虚拟化等各模块完成用户请求，由此产生了一个工作流，其中的每个调用过程则认为是一个活动。又比如用户的一个订单下单请求，对于服务器而言其可能需要执行如下过程：1、验证订单；2、如果订单有效，要求客户付款；3、如果付款完成，则按订单发货；4如果发货完成，则保存订单详情。该流程则是对应该订单下单请求的工作流，上述4个过程相当于4个活动，每个活动可能会调用不同的模块执行。如上述例子，因为对一个用户请求，需要将相应的工作流执行完成才能获得最终的结果，那么如果在针对一个用户请求执行相应工作流时，如果系统出现问题，则会导致用户请求无法正常被处理。

对上述请情况，在先技术的亚马孙提供的aws服务提供了一种failover机制，可以解决系统出现问题时，用户请求的工作流没执行完毕的情况，其aws将应用程序划分为两个部分：决策程序(decider)和活动程序(activity)。决策程序决定用户的请求应该做什么，活动程序负责执行具体的业务逻辑。决策程序和活动程序都通过aws提取相应的任务执行、并返回任务结果给aws。在决策活动超时时，aws执行相应的failover机制，对请求进行调度，以继续执行等操作。但是aws的上述方式每个活动执行过程中，决策程序(decider)和活动程序(activity)与服务之间需要四次http交互，其用户请求的执行效率低，对于活动的监控和恢复过程的处理逻辑复杂。

本申请则提出了一种新的方案来解决用户请求的执行效率低、处理逻辑复杂的问题，同时也很好的解决了用户请求能够被调度恢复以达到高可靠的目的。如图1a，本申请实施例的该方案设置了多个节点，其中包括监控节点a11、多个工作节点a12、存储空间a13。其中，监控节点作为主节点，工作节点作为从节点，主节点可以监控从节点的状态，如可用/不可用状态。在实际应用中，主节点可以向从节点发送心跳信息以确定从节点是否失联，如果未失联则该从节点处于可用状态，如果失联则该从节点处于不可用状态。当然，监控节点和工作节点，是集群中各个节点按照预设规则选举出来的。

其中，每个工作节点a12有两个功能：其一，接收监控节点发送的用户请求；执行对应所述用户请求的工作流实例，并将所述工作流实例执行过程中的执行过程数据存储至存储空间；其二，接收一被监控节点调度的未完成的工作流实例，然后从所述存储空间a13获取对应所述用户请求的工作流实例的执行过程数据，重建相应工作流实例，继续执行所述工作流实例并将所述工作流实例执行过程中的执行过程数据存储至存储空间a13。当然，在实际应用中，工作节点中具体执行工作流实例的是其中的工作流引擎。其中该执行过程数据包括上下文信息等数据。

需要说明的是该存储空间可以独立与监控节点和工作节点之外，避免由于在某个节点中而该节点宕机，使其中的记录无法使用。另外，该存储空间可以采用非易失性存储设备，本发明实施例不对其加以限制。

对于监控节点a11，其将接收到的用户请求发送给一处于可用状态的工作节点，然后当所述监控节点监控到一工作节点处于不可用状态后，根据存储空间a13中所述不可用状态的工作节点的记录，将未完成的工作流实例调度到另一处于可用状态的工作节点。

由此，工作节点执行用户请求对应的工作流实例，并将工作流实例相关的上下文信息存储至存储空间中，工作节点独立执行工作流实例，不涉及多方任务交互，提高工作流效率。同时，由监控节点调度失联的工作节点的未完成工作流实例给其他正常的工作节点，该正常的工作节点则可以从储至存储空间读取该工作流实例的上下文信息重建实例，从而实现高可用性。因此，本申请实施例兼顾了用户请求的处理效率和集群的高可用性，简化了对于工作流实例的监控和恢复过程的处理逻辑。。

参照图1b、图1c，其示出了基于图1a的架构下的调度方法的详细示意图，具体包括如下步骤：

步骤p11，在初始状态下，每个节点向其他节点发送本节点的节点信息，以及接收其他节点发送的节点信息；

在整个系统初始上线后的初始状态，各个节点并未划分监控节点、工作节点，没有确定主从关系。那么本申请实施例则可以从各个节点中选举出监控节点，作为主节点。然后剩余的节点为工作节点，作为从节点。监控节点周期性的向各个工作节点发送心跳信息，根据从节点的对心跳信息的响应，确定各个工作节点的可用状态/不可用状态。

比如有100个节点a1、a2……a100。那么系统上线后，该100个节点两两相互之间把自己的节点信息发送给对方，如此每个节点都有其他节点的信息，比如各节点的节点标识、负载、节点状态等。

步骤p12，针对每个节点，基于本节点和其他各节点的节点信息，根据预设规则选举一节点作为监控节点；

比如，然后每个节点根据本节点的信息和其他各节点的信息，比如按负载大小等计算一个权值，从权值最高的节点中选择一个作为监控节点通知给其他节点，然后各个节点可能接收到一个或多个推荐的节点，然后从该一个或多个推荐的权值最高的节点中，再按节点标识大小选择一个节点作为监控节点。

比如，a1推荐最高权值为10的a4给所有节点，a2推荐最高权值为10的a6给所有节点，a3推荐最高权值为10的a4给所有节点，以此类推。那么每个节点接收到的推荐最终是相同的，比如a1最终接收到的推荐是最高权值为10的a4有40次，最高权值为10的a6有40次，最高权值为10的a50有20次。那么可以从a4、a6中选择标识最小的a4为监控节点。其他情况以此类推。

当然，本申请实施例中具体的用于选举的预设规则可以采用多种方式，本申请实施例不对其加以限制。

步骤p13，被选举为监控节点的节点记录自身为监控节点；其他节点记录自身为工作节点。进入步骤p14、步骤p18、步骤p20。

比如前述节点a4则确认自己的身份是监控节点，然后其他节点则确认自己的身份是工作节点。工作节点可以记录监控节点的访问地址信息，比如访问地址等，方便定期返回心跳信息给监控节点以便监控节点监控。当然监控节点也可以记录给工作节点的访问地址信息，方便主动监控各个工作节点。然后可以进入后续的步骤p14、步骤p18、步骤p20等监控节点容灾、用户请求调度、用户请求处理等过程。

步骤p14，各工作节点监控所述监控节点的运行状态数据，并基于所述运行状态数据判断所述监控节点是否处于不可用状态；

如果所述监控节点处于不可用状态，则进入步骤p15；如果所述监控节点处于可用状态，则进入步骤p14、步骤p18、步骤p20。

在本申请实施例中，为了避免由于一个监控节点宕掉，导致整个系统不可用，本申请的各个工作节点还会主动监控其选举出的监控节点是不是处于可用状态。

比如前述选举出的监控节点a4，如果该a4正常，则该监控节点继续进行容灾、用户请求调度、用户请求处理等过程。

如果该a4不可用了，则需要从其余的正常的工作节点中，重新选举出一个监控节点。

步骤p15，各个工作节点向其他工作节点发送节点信息以及接收其他工作节点发送的节点信息；

步骤p16，针对每个工作节点，基于本工作节点和其他各工作节点的节点信息，根据预设规则选举一节点作为监控节点；

比如前述例子，如果各个工作节点监控到监控节点a4不可用了，那么则每个工作节点将其运行状态数据发送到其他工作节点，然后可以按照步骤p12类似的选举方式从各个工作节点中选择一个新的监控节点。比如剩余了a1、a2、a3、a5、a6……a99，监控节点a4和工作节点a100宕掉了，那么剩余的正常的工作节点则选举出一个监控节点，比如选举a6作为监控节点。

步骤p17，被选举为监控节点的节点记录自身为监控节点，将原监控节点作为工作节点。

此时a6则将自身的身份改为监控节点，并且在原来的监控节点a4恢复正常后通知a4将a4自身的身份修改为工作节点。剩余的工作节点则继续保持自身的工作节点的身份。

上述p11至p13是初始状态下确定监控节点和工作节点的过程，上述p14-p17是运行过程中确定监控节点和工作节点的过程，进行监控节点的容灾。当然，监控节点本身也可以作为工作节点，其中的工作流实例的上下文信息同样存储到存储空间中记录。

步骤p18，监控节点将用户请求发送给一处于可用状态的工作节点；

比如当前的监控节点是a6，则监控节点a6可以接收各个客户端发送过来的用户请求。比如接收到客户端w1发送的用户请求q1，那么a6首先要获取哪些工作节点处于可用状态，比如工作节点a1、a2、a3、a5、a7……a99正常，处于可用状态。而a4、a100处于不可用状态。

那么a6可以从可用状态中的工作节点中选择一个，比如选择a1，然后将用户请求q1发送给a1。当然选择时，可以按照各工作节点的负载情况选择，也可按照其他方式选择，本申请实施例不对其加以限制。

需要说明的是，实际应用中，在监控节点被选举后，则可以设置接收客户端的用户请求的对象为该监控节点。重选举监控节点后，也重设接收客户端的用户请求的对象为重选举后的监控节点。

步骤p19，该处于可用状态的工作节点采用工作流引擎创建并执行对应所述用户请求的工作流实例；

步骤p20，该工作节点将所述工作流实例执行过程中的上下文信息存储至存储空间。

如前述例子，对于a1而言，接收到a6调度的用户请求q1，则会针对该用户请求q1启动一个工作流实例q1，然后由该工作流实例执行用户请求q1对应的各种活动。由于工作流实例在执行活动的过程中有执行过程数据，那么可以将该执行过程数据进行记录。比如将工作流实例在执行活动的过程中有上下文信息，那么工作流实例可以将该上下文信息存储至预先设置的存储空间中。其中，该存储空间可以为独立于监控节点和工作节点的存储节点。在存储空间中存储时，可以记录{节点标识：(工作流实例，上下文信息，是否完成)；(工作流实例，上下文信息，是否完成)……}，那么比如前述例子可以记录{a1：(q1，上下文信息，否)}。当然，可以采用其他形式的记录方式，比如只记录未执行完的工作流实例信息，执行完的就删除，那么则没有“是否完成”这个记录。

假设a6又接收到一个客户端w2发送的用户请求q2，a6又选择了a1，将q2发送给了a1。那么a1会针对该q2启动另一个工作流实例q2去执行，也会存储上述执行过程数据至上述存储空间中，那么其记录可以变更为{a1：(q1，上下文信息11，否)；(q2，上下文信息21，否)}。其他工作节点存储到该存储空间中的记录形式类似。

需要说明的是，实例是一个计算机用语，英文简称instance，是面向对象程序设计中的概念，实例是根据类创建出来的一个个具体的“对象”，每个对象都拥有相同的方法，但各自的数据可能不同，实例可以有状态地存储操作结果。

步骤p21，监控节点监控到一工作节点处于不可用状态后，根据所述工作节点的节点标识，从所述存储空间中查找未执行完的工作流实例标识；

比如前述监控节点a6监控到a1宕机，那么可以根据a1去上述存储空间中去查找a1中未执行完的工作流实例标识。

假设a1宕机前执行完前述q1，没执行完前述q2，其宕机前的记录为{a1：(q1，上下文信息12，是)；(q2，上下文信息22，否)}。

那么可以根据a1查找到没执行完的q2。

步骤p22，监控节点针对所述未执行完的工作流实例标识和原工作节点的节点标识生成调度请求；

步骤p23，该监控节点将所述调度请求调度到另一处于可用状态的工作节点。

监控节点a6重新选择可用状态下的工作流节点，比如a8，然后根据q2和a1重新生成调度请求发送给a8。

步骤p24，当所述处于可用状态的工作节点接收到监控节点调度的调度请求后，根据所述调度请求中的工作流实例标识从所述存储空间获取对应所述用户请求的工作流实例的上下文信息，重建相应工作流实例，继续执行所述工作流实例.

步骤p25，该工作节点将所述工作流实例执行过程中的上下文信息存储至存储空间。

当前述a8收到重调度的前述调度请求，从中解析出a1和q2，然后去存储空间中获取q2对应的上下文信息22，然后在a8中以该上下文信息重建q2继续执行，然后将继续执行的上下文信息存储到前述存储空间中存储，比如a8执行q2后的新的上下文信息为上下文信息23，此时未执行完成，则存储空间中记录{a8：(q2，上下文信息23，否)}。

需要说明的是，p21到p25的重调度过程，可以在任意出现宕机的工作节点后发生。

通过上述过程，本申请实施例通过划分工作节点和监控节点，由工作节点执行用户请求对应的工作流实例，并将执行该工作流实例的过程中的上下文信息存储至一设定存储空间，然后由监控节点监控各个工作节点的工作状态，当监控到一工作节点处于不可用状态，则利用前述存储空间中该不可用状态的工作节点的工作流实例的相关历史记录，去调度该不可用状态的未完成工作流实例给其他处于可用状态的工作节点，该可用状态的工作节点则可以利用前述存储空间中该不可用状态的工作节点的工作流实例的相关历史记录重建相应的工作流实例继续执行，如此循环直至工作流实例完成。提高了活动的执行效率，简化了对于工作流实例的监控和恢复过程的处理逻辑。并且，由于采用监控节点监控工作节点的状态，然后由监控节点将失联的工作节点中未完成的请求调度到新的工作节点，新的工作节点可以根据存储空间的记录重建相应工作流实例，因此，在前述提高效率的同时还实现了自动对用户请求进行调度，达到高可靠的目的。

参照图2，从系统架构层级示出了本申请的一种调度方法步骤流程图，具体可以包括如下步骤：

步骤110，监控节点将用户请求发送给一处于可用状态的工作节点；

在本申请实施例中，在整个监控开始之前，还包括：

步骤100，在初始状态下，由各处于可用状态的节点按预设规则从各节点中选举一节点作为监控节点，其余节点作为工作节点。

在本申请实施例中，在整个系统初始上线后的初始状态，各个节点并未划分监控节点、工作节点，没有确定主从关系。那么本申请实施例则可以从各个节点中选举出监控节点，作为主节点。然后剩余的节点为工作节点，作为从节点。监控节点周期性的向各个工作节点发送心跳信息，根据从节点的对心跳信息的响应，确定各个工作节点的可用/不可用状态。

比如，初始系统中有100个处于可用状态的节点，那么从这100个节点中选择1个作为监控节点，其与99个则为工作节点，这99个工作节点则为被监控对象。

在本申请实施例中，可以按预设规则从100个节点中选择一个监控节点。比如各个节点互相发送自身的负载情况，那么对于每个节点而言，其就知道自身和其他99个节点的负载情况，然后从中选择一个负载最低的节点即可。如果负载最低的节点有两个以上，则按节点标识的顺序选择一个。那么对于每个节点而言，由于大家的负载情况的记录都是一样的，选择方式一样，那么就会确切的知道自己是不是监控节点。对于一个节点而言，如果自己是监控节点，则将本节点修改为监控节点的身份，并向各个工作节点发送本节点是监控节点的确认通知，如果自己不是监控节点，则将本地修改为工作节点的身份。

需要说明的是，如何选举监控节点和工作节点，本申请实施例并不对其加以限制。

需要说明的是，监控节点本身也可以是工作节点，其也可以执行工作节点的功能。

那么，在确认监控节点和工作节点后，可以接收客户端的用户请求，然后根据预设的负载均衡算法，将该用户请求分发给某个工作节点。

步骤120，所述处于可用状态的工作节点创建对应所述用户请求的工作流实例。

步骤130，所述处于可用状态的工作节点将所述工作流实例的执行过程数据进行记录。

在本申请实施例中，如前所述用户请求对应一个工作流。那么在本申请实施例中，对于不同的云产品，其可以根据自己的需求，预先配置不同的工作流。不同类型的请求可能对应不同的工作流，相应的工作流中的活动也可能不同。

那么对于接收到监控节点调度的用户请求的处于可用状态的工作节点a，其调用工作流引擎启动对于该用户请求的工作流实例，并执行该工作流实例。在本申请实施例中，一个工作流实例执行过程中会产生执行过程数据，那么本申请实施例的工作节点则会将该执行过程数据发送至预设的存储空间进行存储。比如一个工作流实例执行过程中会产生上下文信息，那么为了后续其他节点可以重建，则本申请实施例则将该工作流实例执行过程中的上下文信息存储至预设的存储空间。

在本申请实施例中，所述上下文信息包括活动的状态、输入、输出、异常其中一项或多项。当然还可以包括其他内容。状态、输入、输出、异常等上下文信息中，在实际应用中，执行过程中出现哪几项就记录哪几项，不一定存在全部的记录，具体记录的内容根据实际情况而定。

其中，该存储空间比如硬盘等存储空间。

其中，工作流引擎是指工作流作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。工作流引擎包括了，流程的节点管理、流向管理、流程样例管理等重要功能。

可选地，在本申请一优选的实施例中，步骤130包括：

子步骤131，所述处于可用状态的工作节点调用工作流引擎执行对应所述用户请求的工作流实例，并将所述工作流实例执行过程中的活动的上下文信息，以所属工作节点的节点标识为基准，按活动执行顺序存储至存储空间。

在本申请实施例中，对于各节点预先会设置节点标识，比如前述100个节点，按序标记1、2……100。其中节点100为监控节点，节点1……节点99为工作节点。那么各节点在往存储空间写数据时，是以节点标识为主键在记录。

进一步的，对于每个工作流实例，会对其设置工作流实例标识，那么在存储时，会在上述节点标识下以工作流实例标识进行存储。

再者，对于工作流实例，其可能存在多个活动，比如前述下单请求，其对应的工作流包括：1、验证订单；2、如果订单有效，要求客户付款；3、如果付款完成，则按订单发货；4如果发货完成，则保存订单详情，四个活动。那么本申请实施例中则启动相应工作流实例，按序执行该四个活动，在存储时，在在节点标识+工作流标识下，按活动执行顺序存储相应活动的上下文信息。

在一个工作流实例执行完毕后，工作节点则可以对相应的工作流实例打上执行完毕标识。因此，当该工作节点宕掉，则其工作流实例没有执行完毕，则其没有执行完毕标识。

步骤140，所述监控节点监控多个工作节点的运行状态数据；

在整个系统的运行过程中，监控节点可以监控各个工作节点的运行状态数据，该运行状态数据比如心跳数据，当然也可以为其他用于指示节点是否可用的数据。

步骤150，监控节点基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点；

比如监控节点向前述工作节点a发送指定次数的心跳信息后，该指定次数的心跳信息均未收到工作节点a的回应，则确定工作节点a处于不可用状态。其中，该指定次数可以根据实际情况预设，本申请实施例不对其加以限定。该工作节点a的节点标识为99。

然监控节点可以去之前的记录中，查找该工作节点a未完成的工作流实例，然后将该未完成的实例调度给其他正常的工作节点。比如，监控节点可以去前述存储空间中，查找节点标识99下面的各个工作流实例的记录，当某些工作流实例没有前述执行完毕标识，则认为其是工作节点a正在运行尚未结束的工作流实例。然后将该工作流实例根据预设的负载均衡算法调度到某个处于可用状态的工作节点中。

可选地，步骤150包括：

子步骤151，所述监控节点基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的节点标识，从所述存储空间中查找未执行完的工作流实例标识；

比如前述工作节点a执行了工作流实例m、工作流实例n。其中工作流实例m在该节点正常时执行完毕，则该节点为其添加执行完毕标识。而工作节点a在执行工作流实例n的过程中宕掉，则工作流实例n没有执行完毕标识。

当然，在本申请实施例中，各个工作节点的工作流实例的相关信息可以存储至存储空间中，比如节点标识，工作流实例标识、执行完毕与否标识、工作流实例执行的上下文信息。其以一个节点标识对应至少一个工作流实例标识，以工作流实例标识对应执行完毕与否标识、工作流实例执行的上下文信息。

那么监控节点查找节点标识99下，有工作流实例n是未完成的。

子步骤152，针对所述未执行完的工作流实例标识和所述不可用状态的工作节点的节点标识生成调度请求，并将所述调度请求调度到另一处于可用状态的工作节点。

监控节点获取到该工作流实例标识“工作流实例n”和节点标识99，然后对其生成调度请求，按预设负载均衡算法将其调度到另一处于可用状态的工作节点b。

步骤160，所述另一处于可用状态的工作节点，根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据进行记录。

可以理解，在前述存储空间中，存储了工作节点执行的工作流实例的上下文信息。那么所述另一处于可用状态的工作节点从所述存储空间获取对应所述用户请求的工作流实例的上下文信息，重建相应工作流实例，继续执行所述工作流实例并将所述工作流实例执行过程中的上下文信息存储至存储空间。

在本申请实施例中，一处于可用状态的工作节点接收到被调度过来的宕掉的节点未完成的工作流实例后，则可以从上述存储空间获取对应所述用户请求的工作流实例的上下文信息，重建相应工作流实例，然后继续执行所述工作流实例，在执行过程中按照前述存储方式将所述工作流实例执行过程中的上下文信息存储至存储空间。

可行的，步骤160包括：

子步骤161，所述另一处于可用状态的工作节点根据所述工作流实例标识从所述存储空间获取所述未完成的工作流实例的上下文信息；

子步骤162，根据所述上下文信息，重建相应工作流实例；

如前述例子，假使工作节点b接收到调度请求，从该请求中解析出未完成的工作流实例n和节点标识99，则从存储空间中以节点标识99+工作流实例n，去获取该工作流实例下的各种上下文信息，然后根据上下文信息重建工作流实例。

在实际应用中，可以利用该工作流实例的已完成活动的状态、输入、输出、异常等信息，和未完成活动的状态、输入、输出、异常等信息，在启动的工作流实例中重加载一遍活动，从而重建了工作流实例。

在本申请实施例中重建工作流实例主要是在内存中重建工作流的上下文信息，包括工作流实例的信息，该实例已经执行的工作流活动历史等。具体重建的过程是从数据库中根据工作流实例id从工作流实例表和活动实例表中获取相关的记录，然后根据记录在内存中将相关数据填入工作流实例对象，完成重建。

子步骤163，继续执行所述工作流实例并将所述工作流实例执行过程中的上下文信息存储至存储空间。

在工作流实例重建后，该工作节点b继续执行该工作流实例，在执行的过程中，还可以采用前述方式将执行过程中的上下文信息存储至前述存储空间。

可选地，在本申请另一优选的实施例中，在监控节点和工作节点选出后，还可以包括：

步骤b11，各工作节点监控所述监控节点的运行状态数据，并基于所述运行状态数据判断所述监控节点是否处于不可用状态；

步骤b12，如果所述监控节点处于不可用状态，则由各工作节点从各工作节点中按预设规则选举一节点作为监控节点，并将原监控节点的作为工作节点。

在整个系统运行过程中，可能监控节点本身也会宕掉，也会处于不可用状态，那么对本申请的各工作节点而言，其也会根据监控节点周期性发送的心跳信息反向监控监控节点是否宕掉。比如工作节点已经n个周期未接收到监控节点发送的心跳信息，那么可以判断该监控节点宕掉。其中n为正整数，可以根据实际情况预设。

当然，在实际应用中，为了避免单个工作节点的错误判断，可以采用如下过程：如果一个工作节点判断出监控节点宕掉，则向其他工作节点发送监控节点宕掉确认询问消息。其他工作节点如果也确定出监控节点宕掉，在收到某个监控节点发送的上述宕掉确认询问消息后，则会返回一个确认宕掉响应。如果一个工作节点接收到大于阈值，则确认监控节点宕掉。

此时，各个处于可用状态的工作节点则重新按预设规则选举一个监控节点。

并且，由于监控节点也具备工作节点的功能，可能其本身也向存储空间存储了执行的工作流实例的上下文信息，则本申请实施例将原监控节点的作为不可用状态的工作节点，然后对其中的未完成的工作流实例执行步骤140-160的过程。

需要说明的是，监控节点、工作节点都是逻辑上的概念，他们可以在同一台物理主机上运行，也可以在不同的物理主机上运行，本申请实施例不对其加以限制。

综上，本申请实施设置了作为主节点的监控节点和作为从节点的工作节点，每个工作节点将执行过程中的工作流实例的执行过程数据进行记录。采用监控节点监控工作节点的状态，然后由监控节点根据前述记录，将失联的工作节点中未完成的请求调度到新的工作节点，新的工作节点可以前述记录重建相应工作流实例。因此，本申请实施例可以在提高工作流执行效率，简化了对于工作流实例的监控和恢复过程的处理逻辑的同时，还实现了自动对用户请求进行调度，达到高可靠的目的。

参照图3，从工作节点侧，示出了本申请的一种调度方法实施例的步骤流程图，具体可以包括如下步骤：

步骤210，接收监控节点发送的用户请求；

步骤220，创建对应所述用户请求的工作流实例；

步骤230，将所述工作流实例的执行过程对应当前工作节点进行记录；

可以理解，工作节点在接收到监控节点发送的用户请求后，执行对应所述用户请求的工作流实例，并将所述工作流实例执行过程中的上下文信息存储至存储空间，该具体过程参照前述实施例对工作节点侧的介绍，在此不再赘叙。

步骤240，接收监控节点发送的处于不可用状态的工作节点的未完成的工作流实例；

步骤250，根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据对应当前工作节点进行记录。

当工作节点接收到一被监控节点调度的未完成的工作流实例后，从所述存储空间获取对应所述未完成的工作流实例的上下文信息，重建相应工作流实例，继续执行所述工作流实例并将所述工作流实例执行过程中的上下文信息存储至存储空间，该具体过程参照前述实施例对工作节点侧的介绍，在此不再赘叙。

可选地，步骤230包括：

子步骤231，调用工作流引擎执行对应所述用户请求的工作流实例，并将所述工作流实例执行过程中的活动的上下文信息，以所属工作节点的节点标识为基准，按活动执行顺序存储至存储空间。

可选地，步骤240包括：

子步骤241，接收监控节点发送的调度请求；所述调度请求包括未执行完的工作流实例标识和所述不可用状态的工作节点的节点标识

可选地，步骤250包括：

子步骤251，根据所述工作流实例标识从所述存储空间获取所述未完成的工作流实例的上下文信息；

子步骤252，根据所述上下文信息，重建相应工作流实例；

子步骤253，继续执行所述工作流实例并将所述工作流实例执行过程中的上下文信息存储至存储空间。

可选地，还包括：

步骤200，在初始状态下，向各节点发送节点信息据以及接收各节点发送的节点信息；

步骤201，基于本节点和其他各节点的节点信息，根据预设规则选举一节点作为监控节点，并且当本节点不为监控节点时，将本节点作为工作节点。

在本申请实施例中，在整个系统初始上线后的初始状态，各个节点并未划分监控节点、工作节点，没有确定主从关系。那么本申请实施例则可以从各个节点中选举出监控节点，作为主节点。然后剩余的节点为工作节点，作为从节点。监控节点周期性的向各个工作节点发送心跳信息，根据从节点的对心跳信息的响应，确定各个工作节点的可用/不可用状态。

比如，初始系统中有100个处于可用状态的节点，那么从这100个节点中选择1个作为监控节点，其与99个则为工作节点，这99个工作节点则为被监控对象。

在本申请实施例中，可以按预设规则从100个节点中选择一个监控节点。比如各个节点互相发送自身的运行状态数据，比如负载情况，那么对于每个节点而言，其就知道自身和其他99个节点的负载情况，然后从中选择一个负载最低的节点即可。如果负载最低的节点有两个以上，则按节点标识的顺序选择一个。那么对于每个节点而言，由于大家的负载情况的记录都是一样的，选择方式一样，那么就会确切的知道自己是不是监控节点。对于一个节点而言，如果自己是监控节点，则将本节点修改为监控节点的身份，并向各个工作节点发送本节点是监控节点的确认通知，如果自己不是监控节点，则将本地修改为工作节点的身份。

可选地，还包括：

步骤202，监控所述监控节点的运行状态数据，并基于所述运行状态数据判断所述监控节点是否处于不可用状态；

步骤203，如果所述监控节点处于不可用状态，则向各工作节点发送节点信息以及接收各工作节点发送的节点信息；

步骤204，基于本工作节点和其他各工作节点的节点信息，根据预设规则选举一节点作为监控节点，并且当本节点不为监控节点时，将本节点作为工作节点，当本节点为监控节点时，将原监控节点的作为工作节点。

在整个系统运行过程中，可能监控节点本身也会宕掉，也会处于不可用状态，那么对本申请的各工作节点而言，其也会根据监控节点周期性发送的心跳信息反向监控监控节点是否宕掉。比如工作节点已经n个周期未接收到监控节点发送的心跳信息，那么可以判断该监控节点宕掉。其中n为正整数，可以根据实际情况预设。

然后，工作节点b则向其他节点发送自身的运行状态数据，比如负载情况，然后接收其他工作节点发送的运行状态数据。那么该工作节点a就知道所有工作节点的负载情况，然后可以根据预设规则，根据负载情况进行计算，选择一个监控节点。

比如，前述100个节点，监控节点100宕掉，工作节点b的节点标识为1，则工作节点b会向2～99的工作节点发送负载情况，接收2～99节点发送的负载情况，然后则根据2～99的负载，选择一个负载最低的比如10作为监控节点。然后工作节点b则继续保持自己为工作节点。对于节点10，其将自身的身份修改为监控节点，同时保留工作节点的功能。

本申请实施例从工作节点侧进行描述，参照图1a-图2的描述，其中在工作节点侧可执行的方法在本申请实施例也适用，在此不再详述。

参照图4，从监控节点侧，示出了本申请的一种调度方法实施例的步骤流程图，具体可以包括如下步骤：

步骤310，将用户请求发送给一处于可用状态的工作节点，以使所述工作节点创建工作流实例；

步骤320，监控多个工作节点的运行状态数据；

步骤330，基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点

可选地，所述不可用状态的工作节点的记录存储于存储空间中。

可以理解，如果某一工作节点处于不可用状态，则根据存储空间中所述不可用状态的工作节点的记录，将未完成的工作流实例调度到另一处于可用状态的工作节点，以供所述另一处于可用状态的工作节点从所述存储空间获取对应所述用户请求的工作流实例的上下文信息，重建相应工作流实例，继续执行所述工作流实例并将所述工作流实例执行过程中的上下文信息存储至存储空间。

其中，上述运行状态数据可以为心跳数据。

本申请实施例从监控节点侧进行描述，参照图1a-图2的描述，其中在监控节点侧可执行的方法在本申请实施例也适用，在此不再详述。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图5，示出了本申请的一种对应系统架构层级的调度方法装置实施例的结构框图，该实施例的结构框图对应图2实施例的的一种调度方法，具体可以包括：

监控节点410、至少两个工作节点420；

所述监控节点410包括：

用户请求处理模块411，用于将用户请求发送给一处于可用状态的工作节点；

工作节点监控模块412，用于监控多个工作节点的运行状态数据；

调度模块413，用于基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点。

每个所述工作节点420包括：

实例创建模块421，用于创建对应所述用户请求的工作流实例；

第一执行模块422，用于将所述工作流实例的执行过程对应当前工作节点进行记录；

第二执行模块423，用于根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据对应当前工作节点进行记录。

可选地，所述不可用状态的工作节点的记录存储于存储空间中。

可选地，所述第一执行模块422包括：

第一执行单元，用于调用工作流引擎执行对应所述用户请求的工作流实例，并将所述工作流实例执行过程中的活动的上下文信息，以所属工作节点的节点标识为基准，按活动执行顺序存储至存储空间。

可选地，所述调度模块413包括：

查找单元，用于基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的节点标识，从所述存储空间中查找未执行完的工作流实例标识；

调度单元，用于针对所述未执行完的工作流实例标识和所述不可用状态的工作节点的节点标识生成调度请求，并将所述调度请求调度到另一处于可用状态的工作节点。

可选地，所述第二执行模块424包括：

上下文信息获取单元，用于根据所述工作流实例标识从所述存储空间获取所述未完成的工作流实例的上下文信息；

重建单元，用于根据所述上下文信息，重建相应工作流实例；

第二执行单元，用于继续执行所述工作流实例并将所述工作流实例执行过程中的上下文信息存储至存储空间。

可选地，，在各节点中还包括：

第一初始选举模块，用于在初始状态下，由各处于可用状态的节点按预设规则从各节点中选举一节点作为监控节点，其余节点作为工作节点。

可选地，所述工作节点还包括：

第一监控节点状态判断模块，用于监控所述监控节点的运行状态数据，并基于所述运行状态数据判断所述监控节点是否处于不可用状态；

第二监控节点重选举模块，用于如果所述监控节点处于不可用状态，则从各工作节点中按预设规则选举一节点作为监控节点，并将原监控节点的作为工作节点。

可选地，所述上下文信息包括活动的状态、输入、输出、异常其中一项或多项。

可选地，所述运行状态数据为心跳数据。

可以理解，在工作节点中，还可以包括用户请求接收模块，用于接收监控节点发送的用户请求；

未完成实例接收模块，用于接收监控节点发送的处于不可用状态的工作节点的未完成的工作流实例。

综上，本申请实施设置了作为主节点的监控节点和作为从节点的工作节点，每个工作节点将执行过程中的工作流实例的执行过程数据进行记录。采用监控节点监控工作节点的状态，然后由监控节点根据前述记录，将失联的工作节点中未完成的请求调度到新的工作节点，新的工作节点可以前述记录重建相应工作流实例。因此，本申请实施例可以在提高工作流执行效率，简化了对于工作流实例的监控和恢复过程的处理逻辑的同时，还实现了自动对用户请求进行调度，达到高可靠的目的。

参照图6，示出了本申请的一种工作节点的结构框图，该实施例的结构框图对应图3实施例的方法，具体可以包括：

用户请求接收模块510，用于接收监控节点发送的用户请求；

实例创建模块520，用于创建对应所述用户请求的工作流实例；

第一执行模块530，用于将所述工作流实例的执行过程对应当前工作节点进行记录；

未完成实例接收模块540，用于接收监控节点发送的处于不可用状态的工作节点的未完成的工作流实例；

第二执行模块550，用于根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据对应当前工作节点进行记录。

可选地，所述第一执行模块530包括：

第一执行单元，用于调用工作流引擎执行对应所述用户请求的工作流实例，并将所述工作流实例执行过程中的活动的上下文信息，以所属工作节点的节点标识为基准，按活动执行顺序存储至存储空间。

可选地，所述未完成实例接收模块540包括：

调度请求接收单元，用于接收监控节点发送的调度请求；所述调度请求包括未执行完的工作流实例标识和所述不可用状态的工作节点的节点标识。

可选地，所述第二执行模块550包括：

上下文信息获取单元，用于根据所述工作流实例标识从所述存储空间获取所述未完成的工作流实例的上下文信息；

重建单元，用于根据所述上下文信息，重建相应工作流实例；

第二执行单元，用于继续执行所述工作流实例并将所述工作流实例执行过程中的上下文信息存储至存储空间。

可选地，还包括：

第一运行状态数据处理模块，用于在初始状态下，向各节点发送节点信息据以及接收各节点发送的节点信息；

第二初始选举模块，用于基于本节点和其他各节点的节点信息，根据预设规则选举一节点作为监控节点，并且当本节点不为监控节点时，将本节点作为工作节点。

可选地，还包括：

监控节点状态判断模块，用于监控所述监控节点的运行状态数据，并基于所述运行状态数据判断所述监控节点是否处于不可用状态；

第二节点状态信息处理模块，用于如果所述监控节点处于不可用状态，则向各工作节点发送节点信息以及接收各工作节点发送的节点信息；

第二监控节点重选举模块，用于基于本工作节点和其他各工作节点的节点信息，根据预设规则选举一节点作为监控节点，并且当本节点不为监控节点时，将本节点作为工作节点，当本节点为监控节点时，将原监控节点的作为工作节点。

参照图7，示出了本申请的一种监控节点的结构框图，该实施例的结构框图对应图4实施例的方法，具体可以包括：

用户请求处理模块610，用于将用户请求发送给一处于可用状态的工作节点，以使所述工作节点创建工作流实例；

工作节点监控模块620，用于监控多个工作节点的运行状态数据；

调度模块630，用于基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点。

可选地，所述不可用状态的工作节点的记录存储于存储空间中。

可选地，所述调度模块包括：

查找单元，用于基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的节点标识，从所述存储空间中查找未执行完的工作流实例标识；

调度单元，用于针对所述未执行完的工作流实例标识和所述不可用状态的工作节点的节点标识生成调度请求，并将所述调度请求调度到另一处于可用状态的工作节点。

本申请实施例还提供了一种装置，包括：一个或多个处理器；和

其上存储有指令的一个或多个机器可读介质，当由所述一个或多个处理器执行时，使得所述装置执行前述调度方法。

本申请实施例还提供了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得装置执行前述调度方法。

其中，当工作节点、监控节点在一个物理机器上时，上述一个或多个处理器执行时可以执行如图2实施例的方法。

其中，当工作节点、监控节点分散在不同的物理机器上时，上述一个或多个处理器执行时可以执行如图3实施例的方法或执行如图4实施例的方法。

图8是本申请实施例提供的另一种服务器结构示意图。参见图8，服务器700可以用于实施上述实施例中提供的交易服务器侧的打印处理方法。该服务器700可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessingunits，cpu)722(例如，一个或一个以上处理器)和存储器732，一个或一个以上存储应用程序742或数据744的存储介质730(例如一个或一个以上海量存储设备)。其中，存储器732和存储介质730可以是短暂存储的或持久存储的。存储在存储介质730的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器722可以设置为与存储介质730通信，在服务器700上执行存储介质730中的一系列指令操作。

服务器700还可以包括一个或一个以上电源726，一个或一个以上有线或无线网络接口750，一个或一个以上输入输出接口758，一个或一个以上键盘756，和/或，一个或一个以上操作系统741，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm等等。其中，中央处理器722可以在服务器700上执行以下操作的指令：

接收监控节点发送的用户请求；

创建对应所述用户请求的工作流实例；

将所述工作流实例的执行过程对应当前工作节点进行记录；

接收监控节点发送的处于不可用状态的工作节点的未完成的工作流实例；

根据所述不可用状态的工作节点的记录，继续执行所述未完成的工作流实例，并将所述工作流实例的执行过程数据对应当前工作节点进行记录。

在另一服务器的实施例中，中央处理器722可以在服务器700上执行以下操作的指令：

将用户请求发送给一处于可用状态的工作节点，以使所述工作节点创建工作流实例；

监控多个工作节点的运行状态数据；

基于所述运行状态数据，确定一工作节点处于不可用状态，则根据所述不可用状态的工作节点的记录，将所述不可用状态的工作节点的未完成的工作流实例调度到另一处于可用状态的工作节点。

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

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

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

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

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

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

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

以上对本申请所提供的一种调度方法、一种调度系统、一种工作节点、一种监控节点、一种设备，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。