API前端服务

Openstack遵循RPC设计框架，包含多个子服务，每个子服务都包含一个API服务来接受客户请求。
以 Nova 为例，nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。
当客户需要执行虚机相关的操作，能且只能向 nova-api 发送 REST 请求。

设计 API 前端服务的好处在于：

1. 对外提供统一接口，隐藏实现细节
2. API 提供 REST 标准调用服务，便于与第三方系统集成
3. 可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 nova-api 进程

Schedule 调度服务

对于集群式的架构，通常会有一个schedule调度服务在众多服务实体中选择一个来应答操作请求。
比如，Nova有多个计算节点，当需要创建虚拟机的时候，nova-scheduler会根据算法和权重选择一个最合适的计算节点来运行虚拟机。

Worker 工作服务

Schedule负责分配工作，具体的工作由Worker工作服务承担。
在Nova中，这个Woker就是Nova-compute。

将 Scheduler 和 Worker 从职能上进行划分使得 OpenStack 非常容易扩展：

• 当计算资源不够了无法创建虚机时，可以增加计算节点（增加 Worker）
• 当客户的请求量太大调度不过来时，可以增加 Scheduler

Driver 框架

Openstack做为开源的Infrastructure as a Service云操作系统，支持业内各种优秀的的技术。这些技术肯恩是开源的，也可能是收费的。
这种开放式的框架使得Openstack能够在技术上保持先进，具有很强的的竞争力，同时又不会对厂商造成锁定。
那 OpenStack 的这种开放性体现在哪里呢？一个重要的方面就是采用基于 Driver 的框架。

以 Nova 为例，OpenStack 的计算节点支持多种 Hypervisor。
包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。
Nova-compute 为这些 Hypervisor 定义了统一的接口，hypervisor 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。
下面是 nova driver 的架构示意图：

nova-compute.png

在 nova-compute 的配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver

driver.png

Messaging 服务

Messaging 是 nova-* 子服务交互的中枢。

message.png

以前没接触过分布式系统的同学可能会不太理解为什么不让 API 直接调用Scheduler，或是让Scheuler 直接调用 Compute，而是非要通过 Messaging 进行中转。这里做一些解释。

程序之间的调用通常分两种：同步调用和异步调用。

• 同步调用
  API 直接调用 Scheduler 的接口是同步调用。
  其特点是 API 发出请求后需要一直等待，直到 Scheduler 完成对 Compute 的调度，将结果返回给 API 后 API 才能够继续做后面的工作。
• 异步调用
  API 通过 Messaging 间接调用 Scheduler 就是异步调用。
  其特点是 API 发出请求后不需要等待，直接返回，继续做后面的工作。
  Scheduler 从 Messaging 接收到请求后执行调度操作，完成后将结果也通过 Messaging 发送给 API。

在 OpenStack 这类分布式系统中，通常采用异步调用的方式，其好处是：

• 解耦各子服务。
  子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用。
• 提高性能
  异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。
• 提高伸缩性
  子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。

Database

OpenStack 各组件需要维护自己的状态信息。
比如 Nova 中有虚机的规格、状态，这些信息都是在数据库中维护的。
每个 OpenStack 组件在 MySQL 中有自己的数据库。

database