TroveArchitecture

本页面旨在描述 Trove 的组件以及它们如何相互协作。

组件

Trove 是一种无共享消息传递系统，类似于 nova。它的组件通过消息总线进行通信，并且可以在不同的服务器上运行。它的行为与 nova 非常相似，即通过 http 发送消息，该消息被翻译并通过消息总线发送，并且操作异步发生。目前它由以下主要组件组成。

API 服务器
消息总线
任务管理器
客户代理
Conductor

API 服务器

API 使对已配置的客户和数据存储的命令和控制成为可能。API 端点是基本的 http Web 服务，处理身份验证、授权以及与数据存储相关的基本命令和控制功能。根据数据存储，API 存在扩展的概念，但这个概念需要更好的工程设计。

API 服务器与两个系统通信（目前）。它将与任务管理器通信以处理复杂的异步任务。它还将直接与客户代理通信以处理简单的任务，例如检索 MySQL 用户列表。这些任务都是同步的。API 不执行任何繁重的工作。它的工作是接收请求，将其转换为消息，验证它们，然后将其转发到任务管理器或客户代理。

消息总线

摘自 Nova 架构

消息队列代理 API 端点、任务管理器和客户代理之间的交互。与云控制器的通信通过 HTTP 请求通过多个 API 端点进行。

典型的消息传递事件始于 API 服务器接收来自用户的请求。API 服务器验证用户并确保用户被允许发出该命令。评估请求中涉及的对象的可用性，如果可用，则将请求路由到相关工作者的队列引擎。工作者根据其角色不断监听队列。当监听产生工作请求时，工作者接受任务分配并开始执行。完成时，响应被发送到队列，API 服务器接收该响应并中继给发起用户。在整个过程中，会根据需要查询、添加或删除数据库条目。

任务管理器

任务管理器服务负责实例配置、管理实例生命周期以及对实例执行操作等繁重的工作。它从 API 服务器接收消息，并相应地以确认消息回复，然后开始任务。一些复杂的任务，例如调整数据库风味和创建实例。它们都需要对 OpenStack 服务进行 HTTP 调用，以及轮询这些服务直到实例变为活动状态，并向客户代理发送消息。任务管理器处理跨多个分布式系统发生的过程流程。

任务管理器是有状态的。它在其系统内编排复杂的流程。如果任务管理器节点在有状态处理期间离线，操作已知会失败。长期运行的任务最终将实现任务流系统。

客户代理

客户代理是在客户实例内运行的服务，负责管理和执行对数据存储本身的操作。它负责将数据存储上线，这可能是一项复杂的任务。Heat 支持将成为未来 Trove 的默认配置和编排引擎，因此将数据存储上线的工作将减轻。客户代理还通过 Conductor 向 API 发送心跳消息。

每个数据存储实现都有一个客户代理实现，负责为该数据存储执行特定任务。例如，Redis 客户代理的行为将与 MySQL 客户代理不同。它们必须满足基本操作（例如创建和调整大小）的合同。

在上一周期（Havana）中，客户代理进行了大量的重构。它更易于进行多种实现。就像 API 扩展一样，客户应该拥有自己的扩展集，这些扩展集因数据存储实现而异。当前客户实现仍然缺乏此功能。

Conductor

Conductor 是在主机上运行的服务，负责接收来自客户实例的消息以更新主机上的信息。例如，实例状态和备份的当前状态。通过 Conductor，客户实例不需要与主机的数据库建立直接连接。Conductor 监听消息总线上的 RPC 消息并执行相关操作。

Conductor 类似于客户代理，因为它是一个监听 RabbitMQ 主题的服务。区别在于 Conductor 位于主机上，而不是客户上。客户代理通过将消息放入配置中定义的队列（默认情况下为“trove-conductor”）中来与 Conductor 通信。

入口点 - Trove/bin/trove-conductor
作为由 Trove/etc/trove/trove-conductor.conf.sample 配置的 RpcService 运行，该文件定义 trove.conductor.manager.Manager 作为管理器。这是到达队列的请求的入口点。
如上所述，请求使用 _cast()（异步）从另一个组件推送到 MQ，通常采用 {"method": "<method_name>", "args": {<arguments>}} 的形式
实际的数据库更新工作由 trove/conductor/manager.py 完成
“heartbeat” 方法更新实例的状态。客户代理使用此方法报告实例已从 NEW 更改为 BUILDING 到 ACTIVE 等。
“update_backup” 方法更改备份的详细信息，包括其当前状态、备份大小、类型和校验和。