Convection

注意：类似项目 -> Mistral

在 2013 年秋季于香港 Icehouse 设计峰会上，借鉴了此处 Convection 提案的一些想法，启动了一个名为 Mistral 的项目。目前，一些 OpenStack 贡献者正在积极开展该项目的工作。此处的提案应作为参考的想法保留。对于新想法，与 Mistral 项目合作可能是有益的：https://wiki.openstack.org/wiki/Mistral

仅提案：任务系统即服务 (Convection)

请注意，这只是一个提案。请参阅 Mistral 项目，该项目于 2013 年 10 月启动，旨在实现此提案中的想法，甚至更多。
Nova 的需求 Etherpad

什么是 Convection

Convection 是一个针对云工作负载的新开源任务系统即服务项目的提案。（注意：与其他云供应商提供的类似服务相比，有些人可能会将其视为工作流即服务系统，但是，任务系统一词更准确地反映了该服务的意图，而不是通常与业务流程管理相关的“工作流”，后者可能包括跨多个组织和系统的复杂自动化和手动流程）。 Convection 可以是一个面向公众的 API 服务，提供 任务和状态管理 功能，使 OpenStack API 消费者能够在 OpenStack 云上构建复杂的、多步骤的应用程序，这些云可以是公共云、私有云或混合云。 Convection 也可以是其他 OpenStack 项目利用来执行工作的服务。例如，Heat 编排启动云堆栈的一种可能方法是利用任务服务来执行启动和连接云资源的步骤。反之，希望运行元任务流的客户可以将 Heat 作为更大的元任务流中的单个任务，其中堆栈编排是单个任务。

为什么命名为 Convection？

Convection 是由 Tim Simpson（Trove 开发人员）提出的名称。想法是 (1) Convection “传递”，意味着秩序的组织； (2) Convection 通常与烤箱联系在一起，烤箱产生热量，OpenStack 项目 Heat 可能是任务流的一个潜在消费者，其中任务流可以比作对流烤箱中的气流。

什么是任务流（有时也称为工作流）？

定义注意：存在静态工作流和动态工作流。

工作流是一个被过度使用的术语吗？是的！关于“工作流”一词的实际含义存在误解，并且它通常被用来表示与上述定义不同的事物。这也是为什么该服务现在被称为任务流服务，而不是工作流服务的主要原因之一。为了 Convection 的讨论目的，让我们定义以下术语

任务流术语

按顺序执行（静态）任务流：在学术背景下，工作流有时被描述为一系列有序的任务，这些任务具有明确的开始、顺序和结束。某些任务可以并行执行，但是预先确定的工作流步骤树（和并行分支）在运行时是已知的，并且每次执行工作流时都会遵循树的流程。
即时（动态）事件驱动的任务流：一系列任务，其中一些任务可能不需要执行顺序，其中任务执行通过单个任务启动/停止/状态通知的事件通信来协调。在基于事件的流程系统中，可以有一个中央任务执行协调器来处理监听任务完成事件并发送新任务启动事件。或者，执行单个任务的代码可以编码自己的逻辑来根据直接从其他任务发送的事件来了解何时执行。

我不想在此提案中指定理想的实现。我只想记录一些任务流概念，并利用社区协作设计一个有用的 OpenStack 基于工作负载的任务流系统。

任务流即服务并非编排

编排（项目 Heat 的目的）与任务流管理不同。诸如 Heat 之类的项目可以利用任务流服务或代码库。任务流服务可以利用 Heat，即元任务流的一个任务可以是调用 Heat 来启动堆栈。任务流关注“任务状态管理和“任务执行的“规则和顺序”的存储。任务系统可能不一定负责实际执行任务。编排关注于智能地 创建、组织、连接和协调基于云的资源，这可能涉及创建任务流和/或执行任务。

任务流即服务的用例

我们认为独立的任务流服务是有价值的，它将允许各种功能由其他服务执行（例如，Heat 可以是利用任务流的一个服务）。虽然 OpenStack 项目 Heat 专注于资源的编排和资源连接，但任务流可以负责

具有开始和结束的任务序列
批量处理（具有开始和结束的多个任务序列）
一个持久作业/流程（例如自动缩放策略），该作业保持运行直到手动终止
一个作业，用于在指定的时间段内运行（例如，运行此自动化压力测试 2 天，然后退出）。

从高层来看，可以将任务流视为“批量”（具有开始/结束）和“长期运行”，它们执行一段时间或直到发生某个触发事件。

潜在的任务系统即服务能力

以下是 Convection 的拟议功能列表。这些不一定是最小可行服务所必需的，只是任务流服务可能包含的一些想法

概念组件

任务流引擎： 任务流引擎可以提供通用的任务和状态管理功能。任务流引擎可以充当中央状态协调器，使任务流客户端应用程序可以分布在公共云和本地部署中。任务流客户端将状态管理卸载到任务流服务，从而允许任务流客户端是无状态的、可扩展的并且能够容忍进程和客户端故障。任务流引擎可以支持在流程和任务级别上可配置的约束，例如超时、重试计数、重试间隔等。

DSL 封装任务流逻辑： 任务流系统不需要执行任务流逻辑，但作为增值增强功能，它可以执行。例如，在任务流服务的简化实现中，该服务本身可以维护任务状态，并让任务流的客户端来实现任务流逻辑的业务逻辑。任务流服务的增强版本可以允许客户端以声明式 DSL 的形式向服务提供任务流业务逻辑，并且任务流引擎可以执行任务流业务逻辑的强制执行（例如，通知任务何时运行、停止、重新启动等）。

命令行工具/仪表板： 由于 OpenStack 是一个云操作系统，因此一些操作系统工具，例如 top，可以查看云中运行的作业列表，这可能非常有用。工具可以提供对现有任务流、当前运行的任务流、处于各种执行状态的任务流的深入了解：运行中、已完成、失败、准备就绪... 并提供重新提交/重试失败的任务流作业的能力。任务流工具还可以提供分析 -- 指标，这些指标可以帮助识别性能瓶颈或任务流中常见的故障区域，该任务流会重复执行。一些可能的指标包括：任务流的平均执行时间、单个流程任务的平均执行时间、任务/工作流故障率等。

任务流存储库： 任务流存储库可以公开一组预定义的常见任务流（例如，启动服务器并将其添加到负载均衡器）。存储库促进了重用并提供了一组引人注目的预定义任务流集。

任务流服务的一个提议是，它不需要客户端将代码上传到任务流服务。客户端将完全灵活地控制任务流任务的语言/执行/部署。唯一的要求是任务工作者能够访问服务公开的 REST API 和/或从任务流系统接收通知（例如，通过 Webhook 或其他机制）。

任务流引擎

从概念上讲，任务流由需要按特定顺序执行的一组任务组成。任务执行的顺序可以是预先确定的；顺序也可以根据先前任务的执行结果动态确定。

能力

任务流引擎可以提供以下功能

通过 REST API 调用注册任务流及其关联的任务
能够在流程和任务级别上指定可配置的约束，例如超时、重试计数、重试间隔等。
调用任务流实例
查询任务流实例的状态
查询给定任务流定义的正在运行的任务流实例列表
支持任务流定义的版本控制
取消任务流实例
支持任务流的并行调用
任务流实例可以调用另一个任务流实例 [主-子任务流]

数据存储

以下信息可以存储在任务流服务数据存储中

已注册的流程、任务及其关联的约束列表，例如超时、重试
任务流实例的执行状态（已完成、正在运行、错误、准备就绪）
计划任务队列。任务流引擎可以为每个已注册的任务类型维护一个任务队列。任务流引擎可以在需要安排任务执行时将任务项发布到任务队列
任务流流程上下文，包含与给定任务流实例关联的运行时信息，例如，调用任务流的应用程序传递的输入数据、任务流任务生成的数据以及管理任务流实例所需的任何其他数据，例如开始时间、运行持续时间等。

概念图

下图描绘了任务流引擎与使用该服务的任务流客户端之间的可能交互。绿色框由任务流客户端实现。请注意，下图显示了一种期望客户端轮询引擎以获取状态的交互（即，引擎没有发送通知），但可以设想一种使用轮询、推送或两者的组合来“通知”状态更改的系统。

实施策略

2013 年 4 月：在哈瓦那设计峰会上，有人提出（并普遍同意）任务流系统对许多项目和客户云用例都很有价值，应该开发。期望的总体方法是

在 Heat 中孵化任务流/系统库函数
在确保稳定性和合理的成熟度后，毕业并将其建议给 Oslo
使用 Oslo 中任务流库的功能开发独立的任务系统服务

以下是在哈瓦那峰会上发表的演示文稿，导致了上述结果：File:Workflow-proposal-presentation.pdf

在非正式会议演示期间收集的 etherpad 笔记如下：https://etherpad.openstack.org/Convection