CN107193659A - 维护作业任务的***和设计方法 - Google Patents

Abstract

本发明提供了一种维护作业任务的***和方法，所述***包括组件、任务和任务组；一个任务组包括至少一个任务，任务组控制组内的每一个任务的执行过程以及执行过程中的任务入口参数传递；一个任务包括至少一个顺序执行的组件，任务控制每个组件的执行，并将前一个组件的组件输出参数传递给下一个组件；所述设计方法包括任务组创建和启动流程以及组件、任务、任务组执行流程。本发明基于操作流程触发，从组件、任务、任务组三个部分进行封装。用户在开发运维脚本时，只需要关注每一个步骤所需要做的事，而无需理会整个业务逻辑，通过任务组合方式建立与业务逻辑统一的业务流程，实现流程与操作的统一。

Description

维护作业任务的***和设计方法

技术领域

本发明涉及云资源管理技术领域，具体涉及一种维护作业任务的***和设 计方法。

背景技术

云计算包含了公有云和私有云两种主要模式和发展方向，出于安全考虑， 企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资 源，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和 匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目 的。

在目前对公有云和自建机房(私有云)，无论是管理方式和对资源的实际使 用都存在着不小的差异，例如：公有云平台中服务器资源一般都是虚拟化的， 实际物理环境不需要关心；而私有云中，同时存在物理环境和虚拟环境；在私 有云中，通过自建运维自动化作业平台，CMDB(Configuration Management Database，配置管理数据库)***来实现管理，在公有云中，需要依赖于公有云 提供的API接口(Application ProgrammingInterface，应用程序编程接口)和SDK (Software Development Kit，软件开发工具包)，或者直接在公有云后台***中 操作。无论是私有云还是公有云，在实际使用中，都需要针对业务特性来对云 资源进行规划和利用。

在云资源管理中，一般会存在多种操作组合，例如资源购买、网络配置、 服务部署等，云资源管理人员需要对操作流程建立标准化管理，因此流程落地 时，需要一套能支撑该流程的自动化作业平台。

在实际的云资源管理中，管理人员通过脚本、手工方式维护，操作流程依 赖于个人的经验和熟练程度，无法正真保证流程的落地执行，当流程发生变更 后，操作也无法保证能做到同步，如需要修改脚本业务逻辑。在操作中发生错 误时，也会遇到操作步骤无法回溯、审计的困难

发明内容

本发明设计了一种作业任务封装和执行装置，解决了对云资源操作流程标 准化的技术问题。

本发明采用的技术方案是：

一种维护作业任务的***，所述***包括组件、任务和任务组；一个任务 组包括至少一个任务，任务组控制组内的每一个任务的执行过程以及执行过程 中的任务入口参数传递；一个任务包括至少一个顺序执行的组件，任务控制每 个组件的执行，并将前一个组件的组件输出参数传递给下一个组件。

进一步地，所述组件用于封装运维操作，包括以下组成部分：

组件ID，全局唯一；

组件所属任务ID，全局唯一，用于关联任务；

组件状态；

组件内容，执行所述组件的实体；

组件输入参数，组件执行所需要的参数；

组件输出参数，标记组件执行后需要导出的变量参数，用于后续组件执行；

组件执行模块，执行并通过管道方式存储执行日志，更新执行状态。

进一步地，所述任务用于创建组件执行流，包括以下组成部分：

任务ID，全局唯一，用于关联任务组及组件；

任务所属任务组，用于关联任务组；

组件索引，一组顺序排列的组件ID，用于关联组件的执行；

任务入口参数，用于接收并发送任务中第一个调用组件所需要的参数；

任务执行模块，用于控制组件执行，更新任务状态。

进一步地，所述任务组对任务进行分组执行，包括以下组成部分：

任务组ID，全局唯一，用于关联任务；

任务索引，一组包含在所述任务组中的任务ID列表；

任务组执行策略，控制任务并发执行策略；

任务组入口参数，用于接收并创建任务，任务组根据获取到的任务组入口 参数，生成对应的任务；

任务组执行模块，用于控制任务执行，更新任务组状态。

一种维护作业任务的设计方法，任务组对任务进行分组执行，所述设计方 法基于操作流程触发，对组件、任务和任务组进行封装；任务组控制组内的每 一个任务的执行过程以及执行过程中的任务入口参数传递；任务控制每个组件 的执行，并将前一个组件的组件输出参数传递给下一个组件；组件对运维操作 进行封装；所述设计方法包括任务组创建和启动流程以及组件、任务、任务组 执行流程。

进一步地，所述任务组创建和启动流程步骤如下：

步骤S11，web控制台接收用户请求，通过请求接收接口获取启动任务组的 名称和参数；

步骤S12，根据配置DB中存储的任务组，创建并初始化任务组、任务和组 件；

步骤S13，推送任务组ID到消息队列中；

步骤S14，返回任务组ID到web控制台，web控制台控制任务组执行。

进一步地，所述组件、任务、任务组执行流程步骤如下：

步骤S21，任务组创建和初始化完成后，任务组控制器将任务组ID推送到 消息队列；

步骤S22，任务组控制器从消息队列重新获取任务组ID，任务组控制器检 查任务组状态；

步骤S23，任务组控制器读取任务ID列表，根据策略推送对应的任务ID 到消息队列中；

步骤S24，任务控制器从消息队列中接收到任务ID，触发任务运行，任务 控制器检查任务状态，读取组件信息，将组件ID或者组件所属任务组ID推送 到消息队列中；

步骤S25，组件控制器从消息队列中接收到组件ID，触发组件运行，组件 控制器执行判断组件状态、执行组件并同步日志，执行完成后，刷新组件状态， 同时推送组件所属任务ID到消息队列中；

步骤S26，重复步骤S21-步骤S25，直到整个组件、任务、任务组执行流程 完成。

进一步地，所述步骤S23中的策略包括并发模式和判断模式，并发模式中 设定同时运行任务的数量，判断模式中当一个任务执行完成后，根据任务最后 一个组件的组件输出参数判断后续执行的任务。

进一步地，所述步骤S24中当组件需要执行时，将组件ID推送到消息队列 中；当组件运行完成后，则将组件所属任务组ID推送到消息队列中。

进一步地，组件、任务、任务组与web控制台交互时，在组件状态、任务 状态、任务组状态同步刷新。

本发明用于解决流程操作的实际落地，有益效果如下：

1、可根据流程变更，灵活调整执行顺序；

2、流程和操作能做到一一对应；

3、每个流程步骤可独立执行，便于问题排查。

附图说明

图1是本发明***结构图实施例一。

图2是本发明***结构图实施例二。

图3是本发明任务组创建和启动流程图。

图4是本发明组件、任务、任务组执行流程图。

具体实施方式

本发明基于操作流程触发，从组件(流程执行)、任务(流程组合)、任务 组(流程批量组合执行)三个部分进行封装。用户在开发运维脚本时，只需要 关注每一个步骤所需要做的事，而无需理会整个业务逻辑，通过任务组合方式 建立与业务逻辑统一的业务流程，以实现流程与操作的统一。下文中，结合附 图和实施例对本发明作进一步阐述。

图1和图2为本发明***结构图，***包括组件、任务、任务组三个功能 模块。各个功能模块说明如下：

组件：用于封装特定的运维操作，比如一个脚本、或者一次接口调用，每 个组件只负责一次单一的操作过程；组件的组成部分如下：

组件ID，全局唯一；

组件所属任务ID，全局唯一，用于关联任务；

组件状态：特定关键字

组件内容：执行所述组件的实体，如果组件是类型是调用脚本，则内容就 是脚本本身；

组件输入参数：一个组件执行所需要的参数，例如：一次ssh(Secure Shell， 安全外壳协议)远程连接，需要host(主机)、user(登录账户)、password(登录密 码)；特定类型的组件可由默认参数和自定义参数组成；

组件输出参数：标记所述组件执行后需要导出的变量参数，用于后续组件 执行；

组件执行模块：执行并通过管道方式存储执行日志，更新执行状态；

组件分类：在程序设计中，可以将组件划分如下几类(如表1所示，非必 须，用户依据设计可自行扩展)。

表1组件分类

任务：用于创建组件执行流，一个任务包含多个顺序执行的组件，任务控 制每个组件的执行，并且将前一个组件的执行结果(组件输出参数)传递给下 一个组件，除此之外，任务还可以控制后续组件的执行、暂停等操作，当其中 一个组件执行错误，组件状态会直接返回至任务。

任务的组成部分如下：

任务ID，全局唯一，用于关联任务组及组件；

任务所属任务组，用于关联任务组；

组件索引：一组顺序排列的组件ID，用于关联多个组件的执行；

任务入口参数：用于接收并发送任务中第一个调用组件所需要的参数；

任务执行模块：用于控制组件执行，更新任务状态。

任务组：将多个任务组织在一起构成一个任务组，任务组根据预设的执行 策略，对任务进行分组执行，任务组控制组内的每一个任务的执行过程以及执 行过程中的入口参数传递。任务组一个典型的场景：批量执行多个云主机，使 用任务+组件封装好对云主机的具体操作流程，对N个云主机执行创建N个单 一任务(N至少为1)，使用任务组组合并控制这些任务(云主机)的执行策略： 同时多个主机并发执行，或者是先执行哪一个云主机。

任务组的组成部分如下：

任务组ID：全局唯一，用于关联任务；

任务索引：一组包含在所述任务组中的任务ID列表；

任务组执行策略：控制任务并发执行策略；

任务组入口参数：用于接收并创建任务，任务组可根据获取到的参数，生 成对应的任务。例如：N个云主机的IP，生成对这些云主机操作的N个任务；

任务组执行模块：用于控制任务执行，更新任务组状态。

表2为状态标记，事先约定了在组件、任务、任务组之间通信的状态标记， 作用是在功能模块间通过状态标记的变化来触发联动操作。各功能功能模块通 过消息队列(消息的传输过程中保存消息的容器)通知方式，触发功能模块启 动，功能模块根据获取到的状态标记来判断后续操作。

表2状态标记

状态标记	说明	模块场景
			CREATE	创建成功	组件、任务、任务组
INIT	任务组完成初始化(创建任务成功)	任务组
			START	启动成功	组件、任务、任务组
RUNNING	运行中	组件、任务、任务组
			FAIL	执行失败	组件、任务、任务组
PAUSE	暂停中	任务、任务组
			DONE	已完成	组件、任务、任务组

本发明中组件、任务、任务组之间使用层级依赖，当状态刷新后，推送上 级ID触发状态同步，三者同步关系因实时保持一致。本发明设计方法包括任务 组创建和启动流程以及组件、任务、任务组执行流程，其中任务组创建和启动 流程如图3所示，步骤如下：

步骤S11，web控制台接收用户请求，通过请求接收接口获取启动任务组的 名称和参数。

步骤S12，根据配置DB中存储的任务组，创建并初始化(INIT)任务组、 任务和组件。

步骤S13，推送任务组ID到消息队列中(触发任务组执行)。

步骤S14，返回任务组ID到web控制台，web控制台控制任务组执行。

组件、任务、任务组执行流程如图4所示，步骤如下：

步骤S21，任务组完成初始化(INIT)后，任务组控制器将任务组ID推送到 消息队列。

步骤S22，任务组控制器从消息队列重新获取任务组ID，任务组控制器检 查任务组状态。

步骤S23，任务组控制器读取任务ID列表，根据策略推送对应的任务ID到 消息队列中。

任务组策略中包括两种模式：并发模式：设定同时运行多少个任务；判断 模式：当一个任务执行完成后，根据任务最后一个组件的输出参数判断后续执 行哪一个任务。并发模式适合批量并发执行云主机，判断模式适合更复杂的业 务逻辑，例如：故障检测、业务逻辑测试、监控等。

步骤S24，任务控制器从消息队列中接收到任务ID，触发任务运行，任务 控制器检查任务状态，读取组件信息，将当前需要执行的组件ID推送到消息队 列，如果组件运行完成(成功或失败)，则推送所属任务组ID到消息队列中。

步骤S25，组件控制器从消息队列中接收到组件ID，触发组件运行，组件 控制器执行判断组件状态、执行组件并同步日志，执行完成(成功或失败)后， 刷新组件状态，同时推送组件所属任务ID到消息队列中。

步骤S26，重复步骤S21-步骤S25，直到整个组件、任务、任务组执行流程 完成。

可选地，在消息队列可靠性方面需要考虑消息丢失，可单独运行一个模块 检查进程，当模块一段时间内无变更，手动刷新状态、重新触发上级模块；

可选地，各功能模块与web交互时，需要在各功能模块状态同步刷新，包 括组件日志刷新时，推送状态通知到一个单独的消息队列中，使用websocket(基 于TCP的一种新的网络协议)实时更新页面信息，刷新日志滚动。

本发明开发语言包含以下部分：

组件、任务、任务组实现多并发执行，可通过docker部署，各功能模块间 通过队列进行交互、同级模块不关联，可以很方便在单台服务器上启动多个调 用***，增加单机并发操作能力同时降低部署难度；

消息队列：使用redis简易队列可快速实现本发明消息通知部分，如需要保 证消息可靠，可使用rabbitmq；

后台存储：任务名及任务绑定执行数据可使用关系数据(mysql)保存，例 如：可保存任务对应的脚本内容；任务执行数据使用mongodb存储，可利用 mongo***数据生成唯一key特性，直接将该key作为任务ID或日志数据ID 推送；

任务执行：ssh远程脚本执行优选使用Fabric、传送文件可使用rsync或者 同样使用Fabric模块实现，云接口调用可使用标准http组件，同时需要将返回 结果做格式标准化定义，保持接口调用的格式统一；

websocket：优选使用nodejs实现。

本发明虽然已以较佳实施例公开如上，但其并不是用来限定本发明，任何 本领域技术人员在不脱离本发明的精神和范围内，都可以利用上述揭示的方法 和技术内容对本发明技术方案做出可能的变动和修改，因此，凡是未脱离本发 明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、 等同变化及修饰，均属于本发明技术方案的保护范围。

Claims (10)

1.一种维护作业任务的***，其特征在于，所述***包括组件、任务和任务组；一个任务组包括至少一个任务，任务组控制组内的每一个任务的执行过程以及执行过程中的任务入口参数传递；一个任务包括至少一个顺序执行的组件，任务控制每个组件的执行，并将前一个组件的组件输出参数传递给下一个组件。

2.如权利要求1所述的一种维护作业任务的***，其特征在于，所述组件用于封装运维操作，包括以下组成部分：

组件ID，全局唯一；

组件所属任务ID，全局唯一，用于关联任务；

组件状态；

组件内容，执行所述组件的实体；

组件输入参数，组件执行所需要的参数；

组件输出参数，标记组件执行后需要导出的变量参数，用于后续组件执行；

组件执行模块，执行并通过管道方式存储执行日志，更新执行状态。

3.如权利要求1所述的一种维护作业任务的***，其特征在于，所述任务用于创建组件执行流，包括以下组成部分：

任务ID，全局唯一，用于关联任务组及组件；

任务所属任务组，用于关联任务组；

组件索引，一组顺序排列的组件ID，用于关联组件的执行；

任务入口参数，用于接收并发送任务中第一个调用组件所需要的参数；

任务执行模块，用于控制组件执行，更新任务状态。

4.如权利要求1所述的一种维护作业任务的***，其特征在于，所述任务组对任务进行分组执行，包括以下组成部分：

任务组ID，全局唯一，用于关联任务；

任务索引，一组包含在所述任务组中的任务ID列表；

任务组执行策略，控制任务并发执行策略；

任务组入口参数，用于接收并创建任务，任务组根据获取到的任务组入口参数，生成对应的任务；

任务组执行模块，用于控制任务执行，更新任务组状态。

5.一种维护作业任务的设计方法，其特征在于，任务组对任务进行分组执行，所述设计方法基于操作流程触发，对组件、任务和任务组进行封装；任务组控制组内的每一个任务的执行过程以及执行过程中的任务入口参数传递；任务控制每个组件的执行，并将前一个组件的组件输出参数传递给下一个组件；组件对运维操作进行封装；所述设计方法包括任务组创建和启动流程以及组件、任务、任务组执行流程。

6.如权利要求5所述的一种维护作业任务的设计方法，其特征在于，所述任务组创建和启动流程步骤如下：

步骤S11，web控制台接收用户请求，通过请求接收接口获取启动任务组的名称和参数；

步骤S12，根据配置DB中存储的任务组，创建并初始化任务组、任务和组件；

步骤S13，推送任务组ID到消息队列中；

步骤S14，返回任务组ID到web控制台，web控制台控制任务组执行。

7.如权利要求6所述的一种维护作业任务的设计方法，其特征在于，所述组件、任务、任务组执行流程步骤如下：

步骤S21，任务组创建和初始化完成后，任务组控制器将任务组ID推送到消息队列；

步骤S22，任务组控制器从消息队列重新获取任务组ID，任务组控制器检查任务组状态；

步骤S23，任务组控制器读取任务ID列表，根据策略推送对应的任务ID到消息队列中；

步骤S24，任务控制器从消息队列中接收到任务ID，触发任务运行，任务控制器检查任务状态，读取组件信息，将组件ID或者组件所属任务组ID推送到消息队列中；

步骤S25，组件控制器从消息队列中接收到组件ID，触发组件运行，组件控制器执行判断组件状态、执行组件并同步日志，执行完成后，刷新组件状态，同时推送组件所属任务ID到消息队列中；

步骤S26，重复步骤S21-步骤S25，直到整个组件、任务、任务组执行流程完成。

8.如权利要求7所述的一种维护作业任务的设计方法，其特征在于，所述步骤S23中的策略包括并发模式和判断模式，并发模式中设定同时运行任务的数量，判断模式中当一个任务执行完成后，根据任务最后一个组件的组件输出参数判断后续执行的任务。

9.如权利要求7所述的一种维护作业任务的设计方法，其特征在于，所述步骤S24中当组件需要执行时，将组件ID推送到消息队列中；当组件运行完成后，则将组件所属任务组ID推送到消息队列中。

10.如权利要求7所述的一种维护作业任务的设计方法，其特征在于，组件、任务、任务组与web控制台交互时，在组件状态、任务状态、任务组状态同步刷新。