Cue/api1vsapi2

API 方法 1 与 API 方法 2 的对比

此页面将分析项目 Cue 的两种主要 API 方法之间的比较。

第一种方法位于此处： https://wiki.openstack.org/wiki/Cue/api

第二种方法位于此处： https://wiki.openstack.org/wiki/Cue/api_2

API 方法 1 概要

第一种 API 方法提供了对 Cue 部署的消息集群的内部结构和配置的更多可见性。这种暴露将允许用户在集群部署之前和之后对每个节点的配置进行额外的控制。这有利于更实用的部署和配置结构，允许用户进行更精细的控制。另一方面，这可能导致配置错误和不稳定的集群。

当用户创建新集群 (POST) 时，API 接受常规集群设置和“节点”列表，当前该列表仅包含 VM 规格 (例如，小型、中型、大型)。接受节点规格列表的原因，即使对于一个集群来说，所有节点都使用相同的规格才有意义，也是为了与 JSON 响应保持一致。响应主体包含与请求主体相同的结构，其中节点列表现在包含有关集群中节点的其他信息 (例如，节点 ID、状态、规格等)。总体而言，该 API 有望为用户暴露对消息集群的完全节点级别的控制。对于集群更新，用户可以指定要更新、添加或删除的特定节点。

API 方法 2 概要

第二种 API 方法隐藏了集群中的每个节点细节。 API 接受集群的配置设置作为一个整体，例如规格和大小，分别表示整体节点规格和节点数量。这种设计最大限度地减少了每个节点的内部配置，因此有利于一个将自动执行完全部署过程，最大限度地减少用户干预，从而减少可能由用户引起的错误的部署系统。

通过更改集群级别参数（例如大小或规格）来发出集群更新。例如，Cue 会决定在缩小规模的情况下删除哪些节点。

API 方法 1 的优缺点

优点	缺点
完全暴露给定集群中的节点配置和设置。请求和响应主体遵循与各自节点列表一致的格式，然后遵循到各自节点的端点列表。用户可以对每个节点进行更新控制。	当前节点列表可能存在混淆，需要节点规格，而对于给定的集群，这些规格必须全部相同。用户暴露的旋钮越多，配置错误的几率就越大，因此集群停机时间更长，需要的支持更多等等。

API 方法 2 的优缺点

优点	缺点
Cue 管理启动和运行集群所需的节点特定细节。最大限度地减少配置错误的集群的几率。将来，如果存在用例，可以添加节点特定的配置。	用户无法更改给定节点上的特定配置。 Cue 将管理集群中节点的任何更新。端点列表到特定节点(s)的映射不那么清晰。

扩展到自定义消息集群配置

Cue 的主要目标是为用户提供一个简单、高效、可靠且具有高可用性的集群消息预置/维护服务。因此，面向用户的 API 应允许简单部署主流消息集群，同时允许预置自定义（节点级别）用户定义的集群。

一种可能的方法是保持 API 在集群级别可配置，并允许用户指定指向自定义配置模板文件的链接。配置模板文件将允许用户定义细粒度的集群/节点配置。对于每种支持的消息传递技术（例如，RabbitMQ、Kafka、Qpid 等），都将有一个配置模板文件格式。如果用户未提供输入配置模板文件，Cue 将使用为给定消息传递技术预定义的模板文件。

这将允许不具备深入消息传递技术知识的主流用户快速/轻松地部署其消息集群，并允许高级用户根据指定的配置部署完全可定制的集群。

总而言之

简单的 API 用于部署集群级别可配置的消息集群
API 可以接受可选的模板配置文件，以进行完全节点级别配置
每种支持的消息传递技术都有一个模板配置文件
当通过 API 未提供配置文件时，Cue 使用默认模板配置文件

问题/讨论

用户从哪里获取配置模板文件？
使用第二种方法，用户如何知道哪个端点已启动/已停止？