CN114697334B - 一种编排任务的执行方法和装置 - Google Patents

Abstract

本申请提供了一种编排任务的执行方法和装置，涉及云计算领域，该方法应用于包含有服务端和多个客户端的系统中，服务端用于向多个客户端下发编排任务，编排任务包含多个原子脚本，多个原子脚本的执行顺序是预定义的，该方法包括：多个客户端中的第一客户端发送保活心跳包；第一客户端接收一个或多个响应心跳包，每个响应心跳包来自所对应的第二客户端，每个响应心跳包中携带有状态码，状态码用于指示所对应的第二客户端对编排任务中多个原子脚本的执行进度；第一客户端在多个客户端对多个原子脚本的执行进度一致的情况下，执行下一个原子脚本，有利于保证多个客户端对多个原子脚本的执行进度的一致性，进而有利于提高应用部署的成功率。

Description

一种编排任务的执行方法和装置

技术领域

本申请涉及云计算领域，尤其涉及一种编排任务的执行方法和装置。

背景技术

随着云计算产业的高速发展，云平台建设步伐逐渐加快。应用部署架构从早期的单体部署架构转变为以微服务为主的分布式部署架构，使得单应用下需要维护的节点数量呈指数级增长，传统的运维模式效率较低。

目前，各企业数据中心正加速自动化运维体系的研发，通过自动化运维工具，实现对大量节点的高效运维管理。saltstack是当前一种热门的自动化运维工具，通过saltstack服务端对多个saltstack客户端下发编排任务，以使得运维人员可以集中化管理大量服务器配置、分发文件、采集系统数据以及安装与管理软件包等。但是，在自动化运维过程中，无法保证各个saltstack客户端对多个原子脚本的执行进度的一致性。而在某些场景中，如部署实时应用集群(real application clusters，RAC)环境时，需要保证各个saltstack客户端对多个原子脚本的执行进度保持一致，否则，将会导致RAC环境部署失败。

因此，希望提供一种方法，能够保证各个saltstack客户端对多个原子脚本的执行进度的一致性，进而提高应用部署的成功率。

发明内容

本申请提供了一种编排任务的执行方法和装置，以期保证各个saltstack客户端对编排任务中多个原子脚本的执行进度的一致性。

第一方面，本申请提供了一种编排任务的执行方法，该方法可以应用于包含有服务端和多个客户端的系统中，所述服务端用于向所述多个客户端下发编排任务，所述编排任务包含多个原子脚本，所述多个原子脚本的执行顺序是预定义的。

示例性地，所述方法可以由第一客户端来执行，所述方法包括：所述多个客户端中的第一客户端发送保活心跳包；所述第一客户端接收一个或多个响应心跳包，所述一个或多个响应心跳包与一个或多个第二客户端一一对应，所述一个或多个第二客户端是所述多个客户端中除第一客户端之外的客户端，每个响应心跳包来自所对应的第二客户端，每个响应心跳包中携带有状态码，所述状态码用于指示所对应的第二客户端对所述编排任务中所述多个原子脚本的执行进度；所述第一客户端在所述多个客户端对所述多个原子脚本的执行进度一致的情况下，执行下一个原子脚本。

基于上述技术方案，第一客户端可以通过发送保活心跳包，以获取多个客户端中其他客户端对多个原子脚本的执行进度，并在第一客户端和其他客户端对多个原子脚本的执行进度均一致的情况下，再执行下一个原子脚本，进而保证多个客户端对多个原子脚本的执行进度的一致性，从而有利于提高应用部署的成功率。

结合第一方面，在第一方面某种可能的实现方式中，所述方法还包括：若所述第一客户端对所述多个原子脚本的执行进度处于第三客户端对所述多个原子脚本的执行进度之前，所述第一客户端暂停执行所述编排任务，直至所述第三客户端对所述多个原子脚本的执行进度与所述第一客户端对所述多个原子脚本的执行进度一致，所述第三客户端属于所述一个或多个第二客户端。

结合第一方面，在第一方面某种可能的实现方式中，所述方法还包括：若所述第一客户端对所述多个原子脚本的执行进度处于第四客户端对所述多个原子脚本的执行进度之后，所述第一客户端向所述第四客户端发送第一指令，以指示所述第四客户端暂停执行所述编排任务，直至所述第一客户端对所述多个原子脚本的执行进度与所述第四客户端对所述多个原子脚本的执行进度一致，所述第四客户端属于所述一个或多个第二客户端。

结合第一方面，在第一方面某种可能的实现方式中，所述多个客户端中的每个客户端维护有一个状态码，所述状态码越大，对所述多个原子脚本的执行进度越靠前。

结合第一方面，在第一方面某种可能的实现方式中，所述方法还包括：所述第一客户端每执行完一个原子脚本，更新一次所述第一客户端对应的状态码。

第二方面，本申请提供了一种编排任务的执行方法，应用于包含有服务端和多个客户端的系统中，所述服务端用于向所述多个客户端下发编排任务，所述编排任务包含多个原子脚本，所述多个原子脚本的执行顺序是预定义的。

示例性地，所述方法可以由第二客户端执行，所述方法包括：所述多个客户端中的第二客户端接收来自第一客户端的保活心跳包，所述第二客户端是所述多个客户端中除所述第一客户端之外的任意一个客户端；所述第二客户端向所述第一客户端发送响应心跳包，所述响应心跳包中携带有状态码，所述状态码用于指示所述第二客户端对所述编排任务中所述多个原子脚本的执行进度。

基于上述技术方案，多个客户端中的第二客户端接收到第一客户端的保活心跳包后，便将自身对多个原子脚本的执行进度反馈给第一客户端，以便于第一客户端基于多个客户端对多个原子脚本的执行进度，控制第二客户端继续执行编排任务或暂停执行编排任务，进而保证各个客户端对多个原子脚本的执行进度的一致性。

结合第二方面，在第二方面某种可能的实现方式中，所述方法还包括：所述第二客户端接收来自所述第一客户端的第一指令，所述第一指令用于指示所述第二客户端暂停执行所述编排任务；所述第二客户端基于所述第一指令，暂停执行所述编排任务。

结合第二方面，在第二方面某种可能的实现方式中，所述方法还包括：所述第二客户端接收来自所述第一客户端的第二指令，所述第二指令用于指示所述第二客户端继续执行所述编排任务；所述第二客户端基于所述第二指令，继续执行所述编排任务。

结合第二方面，在第二方面某种可能的实现方式中，所述多个客户端中的每个客户端维护有一个状态码，所述状态码越大，对所述多个原子脚本的执行进度越靠前。

结合第二方面，在第二方面某种可能的实现方式中，所述方法还包括：所述第二客户端每执行完一个原子脚本，更新一次所述第二客户端对应的状态码。

第三方面，本申请提供了一种编排任务的执行装置，该装置包括：收发单元和执行单元，其中，收发单元用于发送保活心跳包；接收一个或多个响应心跳包，所述一个或多个响应心跳包与一个或多个第二客户端一一对应，每个响应心跳包中携带有状态码，所述状态码用于指示所对应的客户端对编排任务中多个原子脚本的执行进度；执行单元用于在所述装置和所述一个或多个第二客户端对所述多个原子脚本的执行进度一致的情况下，执行下一个原子脚本。

第四方面，本申请提供了一种编排任务的执行装置，该装置包括收发单元，用于接收来自第一客户端的保活心跳包；向所述第一客户端发送响应心跳包，所述响应心跳包中携带有状态码，所述状态码用于指示所述装置对所述编排任务中所述多个原子脚本的执行进度。

第五方面，本申请提供了一种编排任务的执行装置，该装置包括处理器。该处理器与存储器耦合，可用于执行存储器中的计算机程序，以实现第一方面和第一方面任一项可能的实现方式中所述的方法，或实现第二方面和第二方面任一项可能的实现方式中所述的方法。

可选地，第五方面中的装置还包括存储器。

可选地，第五方面中的装置还包括通信接口，处理器与通信接口耦合。

第六方面，本申请提供了一种芯片系统，该芯片系统包括至少一个处理器，用于支持实现上述第一方面和第一方面任一种可能的实现方式中所涉及的功能，或用于支持实现上述第二方面和第二方面任一种可能的实现方式中所涉及的功能，例如，接收或处理上述方法中所涉及的数据等。

在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存程序指令和数据，存储器位于处理器之内或处理器之外。

该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

第七方面，本申请提供了一种计算机可读存储介质，所述计算机存储介质上存储有计算机程序(也可以称为代码，或指令)，当所述计算机程序在被处理器运行时，使得上述第一方面和第一方面任一种可能的实现方式中的方法被执行，或使得上述第二方面和第二方面任一种可能的实现方式中的方法被执行。

第八方面，本申请提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得上述第一方面和第一方面任一种可能的实现方式中的方法被执行，或使得上述第二方面和第二方面任一种可能的实现方式中的方法被执行。

应当理解的是，本申请的第三方面至第八方面与本申请的第一方面和第二方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。

还应理解，本申请提供的编排任务的执行方法和装置可应用于云计算领域，也可应用于其他领域。本申请对此不作限定。

附图说明

图1是本申请实施例提供的saltstack的架构示意图；

图2是适用于本申请实施例提供的方法的应用场景示意图；

图3是本申请实施例提供的编排任务的执行方法的示意性流程图；

图4是本申请实施例提供的多个客户端执行编排任务的示意图；

图5是本申请实施例提供的编排任务的执行装置的示意性框图；

图6是本申请实施例提供的编排任务的执行装置的又一示意性框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

为便于理解本申请实施例，以下对本申请中涉及到的一些术语或词汇作简单说明。

1、saltstack：是一个服务器基础架构集中化管理平台，具备配置管理、远程执行、监控等功能。saltstack基于Python语言实现，结合轻量级消息队列(如ZeroMQ)与Python第三方模块(如Pyzmq、PyCrypto、Pyjinjia2、Python-msgpack和PyYAML等)构建。Saltstack可以理解为一个分布式远程执行系统，用来在远程节点上执行命令和查询数据。通过部署saltstack环境，我们可以在成千上万台服务器上做到批量执行命令，根据不同业务特性进行配置集中化管理、分发文件、采集服务器数据、以及软件包的安装与管理等。

2、Master和Minion：在saltstack架构中服务端可以称为Master，客户端可以称为Minion。Master作为控制中心运行在主机服务器上，负责salt命令运行和资源状态管理。Minion作为客户端安装组件运行在被管理的服务器上，可以主动连接Master，并接收来自Master的命令和配置。为便于清楚地理解Master和Minion之间的关系，下面将结合图1对其进行详细描述。图1是本申请实施例提供的saltstack的架构示意图。其中，图1中的服务端即Master，客户端即Minion。

如图1所示，服务端可以同时管理一个或多个客户端，如图中的客户端1、客户端2以及客户端3。服务端与客户端之间可以通过消息队列(如ZeroMQ)进行通信。例如，客户端上线后可以与服务端联系，把自己的公钥(public key)发送给服务端，服务端接收该客户端的密钥后，即可与该客户端建立互信。

需要说明的是，为便于描述，下文所述的服务端可以是saltstack架构中的Master，客户端可以是saltstack架构中的Minion。

3、ZeroMQ：是一种基于消息队列的多线程网络库，其对套接字类型、连接处理、帧、甚至路由的底层细节进行抽象，提供跨越多种传输协议的套接字。ZeroMQ是网络通信中新的一层，介于应用层和传输层之间(按照传输控制协议(transmission control protocol，TCP)/互联网协议(internet protocol，IP)划分)，其作为一个可伸缩层，可并行运行，分散在分布式系统间。在本申请实施例中，ZeroMQ用于客户端和服务端的通信，是二者之间建立通信的桥梁。

4、Daemon：运行在服务端和客户端内的守护进程，承担消息发布及端口监听的功能，其中，每个客户端部署有一个守护进程，服务端也部署有一个守护进程。

5、DevOps：是一种重视“软件开发人员(development，Dev)”和“互联网技术(internet technology，IT)运维技术人员(operations，Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，使得构建、测试、发布软件能更加便捷、频繁和可靠。目前，各大中型企业数据中心正加速自动化运维体系DevOps的研发与运维转型。

6、编排任务：按照一定的顺序串接起来的多个原子脚本的集合。例如，原子脚本1→原子脚本2→原子脚本3构成一个编排任务。

为便于理解本申请实施例提供的编排任务的执行方法，下面将对适用于本申请实施例的应用场景进行说明。可理解的，本申请实施例描述的应用场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定。

图2是适用于本申请实施例提供的方法的应用场景示意图。如图2所示，服务器210可以和服务器220、服务器230以及服务器240进行通信，其中，服务器210上可以部署Master，服务器220、服务器230以及服务器240上可以部署Minion，通过服务器210可以实现在服务器220至240上批量执行任务。例如，服务器210可以给服务器220至240下发任务指令，服务器220至240接收到任务指令后，便可以按照指令执行任务，进而实现在多台服务器上批量执行命令。

应理解，图2所示的场景仅为示例，不应对本申请实施例构成任何限定。例如，服务器210下还可以连接更多或更少数量的服务器，也即可以管理更多或更少数量的服务器。又例如，图2中所示的服务器(如服务器220)可以为一台物理设备，也可以为多台物理设备组成的服务器集群。再例如，多个Minion也可以部署在同一服务器上，本申请实施例对此不作限定。

目前，服务端(如服务器210)可以给客户端(如服务器220至240)同时下发编排任务，以保证任务的发起时间的一致性。但无法保证各个客户端对编排任务中的多个原子脚本的执行进度的一致性。而在某些场景中，如搭建RAC环境(也可以称为RAC环境安装)时，需要保证各个客户端对多个原子脚本的执行进度保持一致，否则，将会导致RAC环境安装失败。

为解决上述问题，本申请提供了一种编排任务的执行方法，可以通过多个客户端中的第一客户端发送保护心跳包，以获取其他客户端对编排任务中的多个原子脚本的执行进度，在第一客户端和其他客户端对多个原子脚本的执行进度均一致的情况下，再一起执行编排任务中的下一个原子脚本，进而保证多个客户端对原子脚本的执行进度的一致性。

下面将结合附图，详细说明本申请实施例提供的编排任务的执行方法。

图3是本申请实施例提供的编排任务的执行方法300的示意性流程图。图3所示的编排任务的执行方法300可以包括步骤310至步骤330。下面详细说明方法300中的各个步骤。

应理解，图3所示的方法300可以应用于包含有服务端和多个客户端的系统中，服务端用于向多个客户端下发编排任务，编排任务包含多个原子脚本，多个原子脚本的执行顺序是预定义的。多个客户端中的任意一个客户端可以作为第一客户端(也可以称为主节点)，发送保活心跳包，多个客户端除第一客户端之外的任意一个客户端作为第二客户端，发送响应心跳包，其中，第二客户端的数量可以是一个或多个。上述响应心跳包是第二客户端响应于接收到的保活心跳包，而向第一客户端发送的心跳包。

不失一般性地，图3以一个第二客户端为例示出了第一客户端和第二客户端的交互过程，但不应对本申请实施例构成任何限定。例如，第一客户端还可以和更多数量的第二客户端进行交互，换言之，第一客户端可以和一个或多个第二客户端中任意一个第二客户端执行图3所示的方法。

步骤310、第一客户端发送保活心跳包。

多个客户端中每个客户端部署有保活(keepalive)心跳进程，其中，第一客户端是多个客户端中任意一个客户端，该第一客户端上部署有保活心跳主进程，该第一客户端可以定期发送保活心跳包，例如，第一客户端以广播的形式发送保活心跳包，以供第二客户端响应。第二客户端是除第一客户端之外的其他任意一个客户端，第二客户端上部署有保活心跳检测进程，以检测来自第一客户端的保活心跳包，并作出响应。

一种可能的实现方式是，第一客户端定期发送保活心跳包，例如，第一客户端每隔1秒发送一次保活心跳包，以获取一个或多个第二客户端对多个原子脚本的执行进度。相应地，一个或多个第二客户端中每个第二客户端接收来自第一客户端的保活心跳包。

步骤320、第二客户端向第一客户端发送响应心跳包。相应地，第一客户端接收来自第二客户端的响应心跳包。

其中，响应心跳包与第二客户端一一对应，也即每个响应心跳包来自所对应的第二客户端，每个响应心跳包中携带有状态码，该状态码用于指示所对应的第二客户端对编排任务中多个原子脚本的执行进度。如此一来，第一客户端可以接收来自一个或多个第二客户端的响应心跳包，进而可以确定每个第二客户端对多个原子脚本的执行进度。

一种可能的实现方式是，第二客户端接收到来自第一客户端的保活心跳包后，向第一客户端发送响应心跳包，该响应心跳包中携带有状态码，以指示第二客户端对多个原子脚本的执行进度，即执行到哪一个原子脚本。

可选地，多个客户端中的每个客户端维护有一个状态码，状态码越大，对多个原子脚本的执行进度越靠前，换言之，执行进度靠前的客户端所维护的状态码比执行进度靠后的客户端所维护的状态码大。

第一客户端、一个或多个第二客户端中的每个第二客户端均维护有状态码，该状态码可以指示其对多个原子脚本的执行进度。

示例性地，以第一客户端为例，编排任务中包括原子脚本1、原子脚本2以及原子脚本3，上述多个原子脚本的执行顺序依次为原子脚本1→原子脚本2→原子脚本3，若第一客户端执行到原子脚本2(已执行完原子脚本2)，则第一客户端对应的状态码为2，若第一客户端执行到原子脚本3(已执行完原子脚本3)，则第一客户端对应的状态码为3，可以看出，第一客户端对多个原子脚本的执行进度越靠前，其对应的状态码越大。

下面以第一客户端为例，详细描述多个客户端中每个客户端维护状态码的方式。

一种可能的实现方式是，第一客户端每执行完一个原子脚本，更新一次第一客户端对应的状态码。例如，编排任务中各个原子脚本的执行顺序为原子脚本1→原子脚本2→原子脚本3，第一客户端执行完原子脚本1后，将状态码更新为1，进一步地，第一客户端执行原子脚本2，执行完原子脚本2后，将状态码更新为2，类似地，第一客户端执行完原子脚本3后，将状态码更新为3。

应理解，多个客户端中的每个客户端(如第二客户端)均可以通过上述方式维护其自身的状态码，为了简洁，此处不再一一描述。

可选地，多个客户端中每个客户端接收到服务端发送的编排任务后，将自身的状态码设置为0。如此一来，可以保证多个客户端的初始状态码相同。

例如，第一客户端接收到编排任务后，将自身的状态码设置为0。第一客户端每执行完一个原子脚本后，将自身的状态码增加1。

步骤330、第一客户端在多个客户端对多个原子脚本的执行进度一致的情况下，执行下一个原子脚本。

第一客户端接收到来自一个或多个第二客户端的响应心跳包后，判断其对原子脚本的执行进度与第一客户端对多个原子脚本的执行进度是否相同。

一种可能的情况是，第一客户端对多个原子脚本的执行进度与其他一个或多个第二客户端对多个原子脚本的执行进度均一致，这种情况下，第一客户端和一个或多个第二客户端均可以执行下一个原子脚本。例如，客户端1接收到来自客户端2、客户端3以及客户端4的响应心跳包，其中，客户端2对应的响应心跳包携带的状态码为2，也即客户端2执行完原子脚本2，客户端3对应的响应心跳包携带的状态码为2，也即客户端3执行完原子脚本2，客户端4对应的响应心跳包携带的状态码为2，也即客户端4执行完原子脚本2，客户端1自身的状态码也为2，可以看出，客户端1至客户端4对多个原子脚本的执行进度均一致，则客户端1可以进一步执行下一个原子脚本，如原子脚本3。同样地，客户端2至客户端4也可以进一步执行下一个原子脚本。

另一种可能的情况是，第一客户端对多个原子脚本的执行进度与其他一个或多个第二客户端对多个原子脚本的执行进度不一致，具体分为如下三种情况：

情况一、第一客户端对多个原子脚本的执行进度是多个客户端中最靠前的；

情况二、第一客户端对多个原子脚本的执行进度是多个客户端中最靠后的；

情况三、第一客户端对多个原子脚本的执行进度是多个客户端中处于中间位置的，也即，有的第二客户端对多个原子脚本的执行进度比第一客户端靠前，有的第二客户端对多个原子脚本的执行进度比第一客户端靠后。

下面将分别详细描述第一客户端针对对多个原子脚本的执行进度位于自身之前的客户端和位于自身之后的客户端的处理方式。

情况一、若第一客户端对多个原子脚本的执行进度处于第三客户端对多个原子脚本的执行进度之前，则第一客户端暂停执行编排任务，直至第三客户端对多个原子脚本的执行进度与第一客户端对多个原子脚本的执行进度一致，第三客户端属于一个或多个第二客户端。换言之，若第一客户端接收到的来自第三客户端的响应心跳包中携带的状态码指示：第三客户端对多个原子脚本的执行进度处于第一客户端对多个原子脚本的执行进度之后，则第一客户端需要暂停执行编排任务，直至第三客户端对多个原子脚本的执行进度与自身相同。

一示例，第一客户端为客户端1，第二客户端包括客户端2、客户端3以及客户端4。客户端1对多个原子脚本的执行进度为原子脚本3，客户端2对多个原子脚本的执行进度为原子脚本2，客户端3对多个原子脚本的执行进度为原子脚本2，客户端4对多个原子脚本的执行进度为原子脚本1，客户端1对多个原子脚本的执行进度处于客户端2、客户端3以及客户端4之前，则客户端1暂停执行编排任务，直至客户端2、客户端3以及客户端4对多个原子脚本的执行进度与客户端1对多个原子脚本的执行进度一致。

另一示例，第一客户端为客户端1，第二客户端包括客户端2、客户端3以及客户端4。客户端1对多个原子脚本的执行进度为原子脚本3，客户端2对多个原子脚本的执行进度为原子脚本2，客户端3对多个原子脚本的执行进度为原子脚本2，客户端4对多个原子脚本的执行进度为原子脚本4，客户端1对多个原子脚本的执行进度处于客户端2和客户端3之前，则客户端1暂停执行编排任务，直至客户端2和客户端3对多个原子脚本的执行进度与客户端1对多个原子脚本的执行进度一致。

情况二、若第一客户端对多个原子脚本的执行进度处于第四客户端对多个原子脚本的执行进度之后，第一客户端向第四客户端发送第一指令，以指示第四客户端暂停执行编排任务，直至第一客户端对多个原子脚本的执行进度与第四客户端对多个原子脚本的执行进度一致，第四客户端属于一个或多个第二客户端。

一示例，第一客户端为客户端1，第二客户端包括客户端2、客户端3以及客户端4。客户端1对多个原子脚本的执行进度为原子脚本1，客户端2对多个原子脚本的执行进度为原子脚本2，客户端3对多个原子脚本的执行进度为原子脚本2，客户端4对多个原子脚本的执行进度为原子脚本2，客户端1对多个原子脚本的执行进度处于客户端2、客户端3以及客户端4之后，即第四客户端包括客户端2、客户端3以及客户端4，则客户端1向客户端2至客户端4发送第一指令，以指示客户端2至客户端4暂停执行编排任务，直至客户端2、客户端3以及客户端4对多个原子脚本的执行进度与客户端1对多个原子脚本的执行进度一致。

另一示例，第一客户端为客户端1，第二客户端包括客户端2、客户端3以及客户端4。客户端1对多个原子脚本的执行进度为原子脚本2，客户端2对多个原子脚本的执行进度为原子脚本3，客户端3对多个原子脚本的执行进度为原子脚本3，客户端4对原子脚本的执行进度为原子脚本1，客户端1对多个原子脚本的执行进度处于客户端2和客户端3之后，则客户端1向客户端2和客户端3发送第一指令，以指示客户端2和客户端3暂停执行编排任务，直至客户端2和客户端3对多个原子脚本的执行进度与客户端1对多个原子脚本的执行进度一致。另外，由于客户端1对多个原子脚本的执行进度处于客户端4之前，因此客户端1也需要暂停执行编排任务，直至客户端1和客户端4对多个原子脚本的执行进度一致。

可选地，第一客户端在第二客户端对多个原子脚本的执行进度比自身靠后的情况下，第一客户端还可以向第二客户端发送第二指令，第二指令用于指示第二客户端继续执行编排任务。相应地，第二客户端接收来自第一客户端的第二指令，并基于第二指令，继续执行编排任务。

可选地，上述方法还包括：服务端向多个客户端发送编排任务。

例如，服务端可以基于消息队列ZeroMQ将编排任务分发到多个客户端上。其中，上述编排任务可以是通过控制台下发给服务端的，控制台可以理解为运维人员可以操作的控制界面，运维人员可以在该界面上选取需要下发的编排任务，以及需要执行编排任务的多个客户端。

可选地，各个客户端执行完编排任务后，可以将编排任务的执行结果通过消息队列ZeroMQ反馈给服务端，以便于服务端通知控制台编排任务执行完毕。

示例性地，控制台将编排任务下发给服务端后，接收来自服务端的一个任务标识，该任务标识可以用于获取编排任务的执行结果。服务端将上述编排任务进一步地下发给各个客户端，各个客户端执行完编排任务后，将执行结果反馈给服务端，以便于服务端更新上述任务标识对应的编排任务的执行结果。服务端进一步地将该执行结果通知给控制台。

图4是本申请实施例提供的多个客户端执行编排任务的一示例。如图4所示，服务端获取编排任务。例如，服务端可以从控制台获取编排任务。服务端获取到编排任务后，将编排任务通过消息队列下发给每一个客户端，如客户端1、客户端2以及客户端3。其中，服务端、客户端1、客户端2以及客户端3上均部署有守护进程，可以用于承担消息发布及端口监听的功能。客户端1作为第一客户端，其上部署有保活进程-主，即可以定期发送保活心跳包。客户端2和客户端3作为第二客户端，其上部署有保活进程-从(即保活心跳检测进程)，即可以检测来自第一客户端的保活心跳包，并作出响应。客户端1至客户端3接收到编排任务后，将自身的状态码置为0，每执行完一个原子脚本，便将自身的状态码增加1，如，客户端1执行完原子脚本1后，将状态码更新为1，执行完原子脚本2后，将状态码更新为2，执行完原子脚本3后，将状态码更新为3。另外，客户端1可以向客户端2和客户端3发送同步信号，以进行信号的同步。

基于上述技术方案，第一客户端可以通过发送保活心跳包，以获取多个客户端中其他客户端对多个原子脚本的执行进度，在第一客户端和其他客户端对多个原子脚本的执行进度均一致的情况下，再执行下一个原子脚本，进而保证多个客户端对多个原子脚本的执行进度的一致性，从而有利于提高应用部署的成功率。

图5是本申请实施例提供的编排任务的执行装置的示意性框图。

如图5所示，该装置500可以包括：收发单元510和执行单元520。该装置500可用于实现图3或图4所示实施例中所述的方法。

示例性地，当该装置500用于实现图3所示实施例所述的方法中第一客户端的功能时，所述收发单元510可以用于发送保活心跳包；所述收发单元510还用于接收一个或多个响应心跳包，所述一个或多个响应心跳包与一个或多个第二客户端一一对应，每个响应心跳包中携带有状态码，所述状态码用于指示所对应的客户端对编排任务中多个原子脚本的执行进度；执行单元520用于在所述装置和所述一个或多个第二客户端对所述多个原子脚本的执行进度一致的情况下，执行下一个原子脚本。

可选地，若所述第一客户端对所述多个原子脚本的执行进度处于第三客户端对所述多个原子脚本的执行进度之前，所述执行单元520还用于暂停执行所述编排任务，直至所述第三客户端对所述多个原子脚本的执行进度与所述第一客户端对所述多个原子脚本的执行进度一致，所述第三客户端属于所述一个或多个第二客户端。

可选地，若所述第一客户端对所述多个原子脚本的执行进度处于第四客户端对所述多个原子脚本的执行进度之后，所述执行单元520还用于向所述第四客户端发送第一指令，以指示所述第四客户端暂停执行所述编排任务，直至所述第一客户端对所述多个原子脚本的执行进度与所述第四客户端对所述多个原子脚本的执行进度一致，所述第四客户端属于所述一个或多个第二客户端。

可选地，所述多个客户端中的每个客户端维护有一个状态码，所述状态码越大，对所述多个原子脚本的执行进度越靠前。

可选地，所述执行单元520还用于每执行完一个原子脚本，更新一次所述第一客户端对应的状态码。

示例性地，当该装置500用于实现图3所示实施例所述的方法中第二客户端的功能时，所述收发单元510用于接收来自第一客户端的保活心跳包；所述收发单元510还用于向所述第一客户端发送响应心跳包，所述响应心跳包中携带有状态码，所述状态码用于指示所述装置对所述编排任务中所述多个原子脚本的执行进度。

可选地，收发单元510还用于接收来自所述第一客户端的第一指令，所述第一指令用于指示所述第二客户端暂停执行所述编排任务；执行单元520还用于基于所述第一指令，暂停执行所述编排任务。

可选地，收发单元510还用于接收来自所述第一客户端的第二指令，所述第二指令用于指示所述第二客户端继续执行所述编排任务；执行单元520还用于基于所述第二指令，继续执行所述编排任务。

可选地，所述多个客户端中的每个客户端维护有一个状态码，所述状态码越大，对所述多个原子脚本的执行进度越靠前。

可选地，执行单元520还用于每执行完一个原子脚本，更新一次所述第二客户端对应的状态码。

应理解，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

图6是本申请实施例提供的编排任务的执行装置的又一示意性框图。

该装置600可用于实现上述图3或图4所示的实施例中所述的方法。该装置600可以为芯片系统。本申请实施例中，芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

如图6所示，该装置600可以包括至少一个处理器610，用于实现图3或图4所示的实施例中所述的方法。

示例性地，当该装置600用于实现图3所示实施例中所述的方法中第一客户端的功能时，处理器610可以用于发送保活心跳包；接收一个或多个响应心跳包，所述一个或多个响应心跳包与一个或多个第二客户端一一对应，每个响应心跳包中携带有状态码，所述状态码用于指示所对应的客户端对编排任务中多个原子脚本的执行进度；在所述装置和所述一个或多个第二客户端对所述多个原子脚本的执行进度一致的情况下，执行下一个原子脚本。。具体参见方法示例中的详细描述，此处不做赘述。

示例性地，当该装置600用于实现图3所示实施例中所述的方法中第二客户端的功能时，处理器610可以用于接收来自第一客户端的保活心跳包；向所述第一客户端发送响应心跳包，所述响应心跳包中携带有状态码，所述状态码用于指示所述装置对所述编排任务中所述多个原子脚本的执行进度

该装置600还可以包括至少一个存储器620，可以用于存储程序指令和/或数据。存储器620和处理器610耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器610可能和存储器620协同操作。处理器610可能执行存储器620中存储的程序指令。所述至少一个存储器中的至少一个可以包括于处理器中。

该装置600还可以包括通信接口630，用于通过传输介质和其它设备进行通信，从而使得该装置600可以和其它设备进行通信。所述通信接口630例如可以是收发器、接口、总线、电路或者能够实现收发功能的装置。处理器610可利用通信接口630收发数据和/或信息，并用于实现图3或图4所示的实施例中所述的方法。

本申请实施例中不限定上述处理器610、存储器620以及通信接口630之间的具体连接介质。本申请实施例在图6中以处理器610、存储器620以及通信接口630之间通过总线640连接。总线640在图6中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

本申请还提供了一种芯片系统，所述芯片系统包括至少一个处理器，用于实现上述图3或图4所示实施例中第一客户端执行的方法或第二客户端执行的方法。

在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存程序指令和数据，存储器位于处理器之内或处理器之外。

该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

本申请还提供一种计算机程序产品，所述计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当所述计算机程序被运行时，使得计算机执行如图3或图4所示的实施例中第一客户端执行的方法或第二客户端执行的方法。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序(也可以称为代码，或指令)。当所述计算机程序被运行时，使得计算机执行如图3或图4所示的实施例中第一客户端执行的方法或第二客户端执行的方法。

需要说明的是，本申请实施例中提供的编排任务的执行方法和装置可以应用于云计算领域，也可以应用于除云计算领域之外的任意领域，本申请对此不作限定。

应理解，本申请实施例中的处理器可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(digitalsignal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

还应理解，本申请实施例中的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(dynamic RAM，DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double data rateSDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(directrambus RAM，DR RAM)。应注意，本文描述的系统和方法的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

本说明书中使用的术语“单元”、“模块”等，可用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各种说明性逻辑块(illustrative logical block)和步骤(step)，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。在本申请所提供的几个实施例中，应该理解到，所揭露的装置、设备和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上单元集成在一个模块中。

在上述实施例中，各功能模块的功能可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令(程序)。在计算机上加载和执行所述计算机程序指令(程序)时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，数字通用光盘(digital video disc，DVD))、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (7)

1.一种编排任务的执行方法，其特征在于，应用于包含有服务端和多个客户端的系统中，所述服务端用于向所述多个客户端下发编排任务，所述编排任务包含多个原子脚本，所述多个原子脚本的执行顺序是预定义的，所述方法包括：

所述多个客户端中的第一客户端发送保活心跳包；

所述第一客户端接收一个或多个响应心跳包，所述一个或多个响应心跳包与一个或多个第二客户端一一对应，所述一个或多个第二客户端是所述多个客户端中除第一客户端之外的客户端，每个响应心跳包来自所对应的第二客户端，每个响应心跳包中携带有状态码，所述状态码用于指示所对应的第二客户端对所述编排任务中所述多个原子脚本的执行进度；

所述第一客户端在所述多个客户端对所述多个原子脚本的执行进度一致的情况下，执行下一个原子脚本；

若所述第一客户端对所述多个原子脚本的执行进度处于第三客户端对所述多个原子脚本的执行进度之前，所述第一客户端暂停执行所述编排任务，直至所述第三客户端对所述多个原子脚本的执行进度与所述第一客户端对所述多个原子脚本的执行进度一致，所述第三客户端属于所述一个或多个第二客户端；

若所述第一客户端对所述多个原子脚本的执行进度处于第四客户端对所述多个原子脚本的执行进度之后，所述第一客户端向所述第四客户端发送第一指令，以指示所述第四客户端暂停执行所述编排任务，直至所述第一客户端对所述多个原子脚本的执行进度与所述第四客户端对所述多个原子脚本的执行进度一致，所述第四客户端属于所述一个或多个第二客户端；

所述多个客户端中的每个客户端维护有一个状态码，所述状态码越大，对所述多个原子脚本的执行进度越靠前。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述第一客户端每执行完一个原子脚本，更新一次所述第一客户端对应的状态码。

3.一种编排任务的执行方法，其特征在于，应用于包含有服务端和多个客户端的系统中，所述服务端用于向所述多个客户端下发编排任务，所述编排任务包含多个原子脚本，所述多个原子脚本的执行顺序是预定义的，所述方法包括：

所述多个客户端中的第二客户端接收来自第一客户端的保活心跳包，所述第二客户端是所述多个客户端中除所述第一客户端之外的任意一个客户端；

所述第二客户端向所述第一客户端发送响应心跳包，所述响应心跳包中携带有状态码，所述状态码用于指示所述第二客户端对所述编排任务中所述多个原子脚本的执行进度；

所述第二客户端接收来自所述第一客户端的第一指令，所述第一指令用于指示所述第二客户端暂停执行所述编排任务，所述第一指令是所述第一客户端对所述多个原子脚本的执行进度处于第二客户端对多个原子脚本的执行进度之后发送的；

所述第二客户端基于所述第一指令，暂停执行所述编排任务；

所述第二客户端接收来自所述第一客户端的第二指令，所述第二指令用于指示所述第二客户端继续执行所述编排任务，所述第二指令是所述第一客户端在所述第二客户端对多个原子脚本的执行进度比自身靠后的情况下发送的；

所述第二客户端基于所述第二指令，继续执行所述编排任务；

所述多个客户端中的每个客户端维护有一个状态码，所述状态码越大，对所述多个原子脚本的执行进度越靠前；

所述第二客户端每执行完一个原子脚本，更新一次所述第二客户端对应的状态码。

4.一种编排任务的执行装置，其特征在于，包括：

收发单元，用于发送保活心跳包；

所述收发单元还用于接收一个或多个响应心跳包，所述一个或多个响应心跳包与一个或多个第二客户端一一对应，每个响应心跳包中携带有状态码，所述状态码用于指示所对应的客户端对编排任务中多个原子脚本的执行进度；

执行单元，用于在所述装置和所述一个或多个第二客户端对所述多个原子脚本的执行进度一致的情况下，执行下一个原子脚本；

若第一客户端对所述多个原子脚本的执行进度处于第三客户端对所述多个原子脚本的执行进度之前，所述执行单元还用于暂停执行所述编排任务，直至所述第三客户端对所述多个原子脚本的执行进度与所述第一客户端对所述多个原子脚本的执行进度一致，所述第三客户端属于所述一个或多个第二客户端；

若所述第一客户端对所述多个原子脚本的执行进度处于第四客户端对所述多个原子脚本的执行进度之后，所述执行单元还用于向所述第四客户端发送第一指令，以指示所述第四客户端暂停执行所述编排任务，直至所述第一客户端对所述多个原子脚本的执行进度与所述第四客户端对所述多个原子脚本的执行进度一致，所述第四客户端属于所述一个或多个第二客户端；

所述多个客户端中的每个客户端维护有一个状态码，所述状态码越大，对所述多个原子脚本的执行进度越靠前。

5.一种编排任务的执行装置，其特征在于，包括：

收发单元，用于接收来自第一客户端的保活心跳包；

所述收发单元还用于向所述第一客户端发送响应心跳包，所述响应心跳包中携带有状态码，所述状态码用于指示所述装置对所述编排任务中多个原子脚本的执行进度；

所述收发单元还用于接收来自所述第一客户端的第一指令，所述第一指令用于指示第二客户端暂停执行所述编排任务，所述第一指令是所述第一客户端对所述多个原子脚本的执行进度处于第二客户端对多个原子脚本的执行进度之后发送的；

执行单元用于基于所述第一指令，暂停执行所述编排任务；

所述收发单元还用于接收来自所述第一客户端的第二指令，所述第二指令用于指示所述第二客户端继续执行所述编排任务，所述第二指令是所述第一客户端在所述第二客户端对多个原子脚本的执行进度比自身靠后的情况下发送的；

所述执行单元还用于基于所述第二指令，继续执行所述编排任务；

所述多个客户端中的每个客户端维护有一个状态码，所述状态码越大，对所述多个原子脚本的执行进度越靠前；

所述执行单元还用于每执行完一个原子脚本，更新一次所述第二客户端对应的状态码。

6.一种编排任务的执行装置，其特征在于，包括存储器和处理器，其中，所述存储器用于存储计算机程序；所述处理器执行所述计算机程序，以使得所述装置执行如权利要求1至2中任一项所述的方法，或执行如权利要求3所述的方法。

7.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1至2中任一项所述的方法，或执行如权利要求3所述的方法。