Cue

使命宣言

为现成的消息传递技术提供可扩展且可靠的消息代理配置功能，同时为底层消息代理提供高级管理、调优和管理。

描述

Cue 是 Openstack 的消息代理配置服务。其目标是简化和自动化消息代理的配置、管理和维护的复杂任务。该服务的用户可以根据需要创建和管理多个类型的消息代理集群。该服务将在 VM 级别提供资源隔离，并且不尝试在消息代理层实现多租户。

为什么

消息传递是构建松散耦合分布式系统的常用开发模式。消息传递系统也充当独立应用程序之间的粘合剂。存在几种现成的产品实现消息传递和队列语义，其中许多产品实现开放协议，例如 AMQP 0.9 和 1.0。

为单个应用程序配置和支持消息传递系统可能是一项耗时且痛苦的体验。Cue 旨在简化消息传递系统的配置和管理，为云运营商和最终用户提供高可用性和自动修复能力，同时提供安全的租户级别隔离。

该服务的主要目标是简化遗留应用程序和“云原生”应用程序的最终用户应用程序开发生命周期，让开发人员专注于他们的应用程序，而不是底层中间件服务。

用例

微服务 - 通过 PaaS 产品（如 Cloud Foundry）在 OpenStack 上分发服务之间的工作

John 在一家电信公司的 IT 运营部门工作，负责为内部开发团队提供高度可用的消息传递服务。在此之前，开发团队可以自由地启动自己的消息传递组件来支持他们的应用程序，这给运营团队带来了很大的麻烦。该公司已将 AMQP 标准化为应用程序之间发送消息的标准协议，并将 RabbitMQ 作为大多数项目的默认代理。为了可移植性和可扩展性，该公司还在标准化 Cloud Foundry 作为构建基于 OpenStack 和非 OpenStack 云的云原生应用程序的默认平台。

首先，John 在现有的 OpenStack 环境中下载并安装 Cue。作为安装 Cue 的云管理员，John 在安装时有几个选项。他可以指定要在环境中启用哪些消息代理。他还可以控制默认配额并创建与特定代理（如 RabbitMQ 或 Kafka）关联的 flavor。Flavor 可以配置为以安全的方式在多个租户之间共享，具体取决于启用的代理（并非所有代理都支持此功能）。安装结果是在 Keystone 目录中将 Cue 服务显示为“Messaging Service”。它还在 Horizon 中创建了一个名为“Messaging”的新顶级服务。

现在 Cue 已安装并处于运行状态，开发团队可以使用 Cue 的 REST API、CLI 或 Horizon 自由配置消息代理的实例/集群。由于 John 的公司已选择 Cloud Foundry 作为平台标准，他还有一步需要执行。John 必须将 Cue 与 Cloud Foundry 服务代理集成，以便将 Cue 暴露给 Cloud Foundry 层的开发团队。这一点很重要，因为公司中构建云原生应用程序的大多数开发团队不会直接访问 OpenStack 层，这意味着他们没有 Keystone 凭据（或通过 Keystone<->AD/LDAP 集成获得访问权限）。通过将 Cue 与 Cloud Foundry 服务代理集成，开发团队可以自由地根据需要从 Cloud Foundry CLI 或 UI 配置主题/队列。Cloud Foundry 的 Cue 服务代理公开了 John 在安装时配置的相同 flavor，在 Cloud Foundry 术语中称为“plans”。实施服务代理后，可以将 Cue 直接暴露给任何 Cloud Foundry 环境或启用到现有环境。

Sally 是这家电信公司的开发人员，她正在构建一个使用利用 Cloud Foundry 的微服务架构的新原型。她验证了已在 OpenStack 之上运行的 Cloud Foundry 集群。Cloud Foundry UI 显示对她来说有一个名为“Messaging Service”的新服务可用。她看到了服务的几个计划并选择了小 RabbitMQ 计划，这导致配置了一个 RabbitMQ 实例（1 个小型虚拟机）并绑定到微服务。配置和绑定发生在几秒钟内。RabbitMQ 实例的连接信息/凭据随后呈现出来。然后 Sally 选择适当的 RabbitMQ 客户端库并继续编写她的原型。在后端，RabbitMQ 实例是 Cue 资源池的一部分，由运营团队监控和管理。