Heat/Vision

注意：以下信息用于讨论，图表/示意图并非由当前的 Heat 核心团队制作，在某些情况下也不完全代表 Heat 的当前架构。因此，本页面应被视为一个正在进行中的工作，我们将逐步完善它，以反映核心团队和社区在设计峰会期间和之后持续讨论的真实计划/愿景 --

在 2013 年波特兰 OpenStack 设计峰会上，针对 Havana 版本，人们对 Heat 的架构在未来可能是什么样子进行了大量的讨论。此框图试图说明当前实现各种未来设计目标的想法。我们计划逐步迭代到这个愿景。 新组件以绿色显示。 紫色表示最终用户主机位于 Heat 之外。 下面详细介绍每个组件。

用于讨论的替代架构图

核心组件的更改：我从 Heat REST API 框中删除了模型解释器，因为 REST API 应该尽可能简洁和“哑”。 我对流程的看法如下：Heat 模板（或短期内的 CFN 模板）通过 REST API 传递到队列（AMQP）。 Heat Engine 中的一个组件获取请求并开始处理。 模型处理器（对应于当前 Heat 架构中的解析器）读取 Heat 模板的拓扑信息，将其转换为内部对象并推导出处理流程。 最初，CFN 支持将与模型处理器紧密耦合，以便对 Heat 模板和 CFN 提供无干扰的支持——这种紧密集成由附着到模型处理器的“CFN”框表示。 在后续阶段，CFN 支持将转到替代 API（灰色框）。

我以以下方式更改了替代 API 中继框：现在有多个“模型转换器”，每个替代格式一个。 每种格式都有其特殊之处，因此似乎每种格式都需要自己的转换器。 转换为 Heat 模板后，API 中继会将 Heat 模板传递到本机 API。 该组件也已灰显，以表明它目前不属于 Heat 核心，但将作为附加组件驱动。 在后续阶段，我们可以考虑将此层移动到 Heat 核心更靠近的地方，也许是在 API 层下方。

我进一步更改了监控系统集成的方式：它不再直接与 Heat Engine 交互，而是将更新发布到队列（AMQP）。 更新事件由正确的 Heat Engine 拾取，然后处理更新并采取相应措施。

替代 API

Heat 将使用 开放 API 和相关的 DSL 作为编排的通用表达。 将使用新的解决方案模式来兼容替代模板格式，从而实现各种新兴云标准的实现。 每个模板都可以实现一个 模型解释器，该解释器将暴露适当的服务 API，并将给定的模板分解为通用格式。 一旦生成了开放 DSL 格式的模板，通用 API 就会被 API 中继 触发。 未来 CFN 模板将在其中处理，以及其他替代格式，例如 TOSCA，以及替代 API，例如 CAMP。

模型解释器

引入了 模型解释器 的概念。 这是 Heat 系统组件，负责解析 DSL 并组成部署计划。 它构建部署计划的图形，并将其交给 Heat Engine 的 模型处理器。 在 Heat Engine 准备好使用新的 DSL 之前，它将继续支持 CFN。 请参见图中的 CFN[1]。 一旦为新的 DSL 添加了完全支持，CFN 模板将在中继组件中处理。 请参见图中的 CFN[2]。

任务系统

我们认为 任务系统 的想法是可取的，该系统将允许为 Heat 执行各种功能。 虽然 Heat 专注于资源的编排，但任务流程负责

• 具有开始和结束的多个任务的序列。
• 一个持久作业/进程（例如自动伸缩策略），在手动终止之前保持运行。
• 一个作业，在指定的时间段内运行（例如，运行此自动化压力测试 2 天，然后退出）。

OpenStack 服务，例如 Nova 或 OpenStack Networking，可以选择在可靠的消息传递至关重要，并且调用另一个服务的单个 API 不足以处理需求的情况下，直接使用 任务系统。 例如，启动这个新网络，并将此服务器列表附加到它。 这将作为 Heat 中的一个库开始，并可能在达到适当的成熟度后毕业到 Oslo。 然后，它可以设置为容错 HA 服务配置中的独立服务。

自动伸缩

伸缩策略可以在 Heat 中实现。 预计这将在未来分解为一个独立的服务。 Ceilometer 提供来自正在运行的服务器的指标（在评估传感器数据时触发的事件）和警报，这些警报会传递到一个或多个用户定义的 webhook。 将实现 MAPE，并且“A”和“P”阶段将由用户定义的 CEP 组件处理。

用户定义的 CEP

CEP 是用户定义的复杂事件处理器，可以应用任意逻辑来确定在各种条件下要采取的措施，包括触发 工作流服务，例如“将节点添加到此集群”，或编排，例如“部署新集群”，或两者的组合，例如“销毁失败的集群（工作流），并启动一个新集群（编排）”。 它还可以将 webhook 发送回 Ceilometer，Ceilometer 会将其转发给 Heat，Heat 会监听特定的伸缩事件，以便触发 ScaleUp 和 ScaleDown 操作。

CEP 不由 Heat 托管。 它由用户作为可以接受 webhook 调用 HTTP 服务提供。 这允许用户用他们选择的语言编写它们，并实现适合他们需求的任何业务逻辑。 可以提供一些示例 CEP 解决方案来执行常见的自动伸缩分析和规划操作。

创建 CEP 的理由是，您可能不想每次从 Ceilometer 收到警报事件时都触发伸缩工作流。 您可能希望控制采取行动的速率。 您可以考虑使用简单的 ECA 模式，或者可能使用来自 Autonomic Computing 的更复杂的 MAPE 模式。