背景
本文更多的是基于代码层面对openstack nova服务进行简单概述的。
概念
Nova是Openstack最核心的服务模块，负责管理和维护云计算环境的计算资源，负责整个云环境虚拟机生命周期的管理。
Nova位于Openstack架构的中心，其他服务或者组件（比如Glance、Cinder、Neutron等）对它提供支持，另外它本身的架构也比较复杂，包括很多组件：
- API
- Compute Core
- DB
- Console Interface
- MQ
下面就这些组件及组件间如何协同工作来一一展开，不过在介绍这些之前，我们有必要了解一下Nova的设计思想。
设计思路
其实，这种架构思路也是openstack的通用设计思路，比如cinder/neutron基本上也是采用这种设计思路来的。
API
负责接收客户端请求，nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。当客户端需要执行虚机操作，客户端只能通过这些Rest API来完成，另外，这里的客户端指的是终端用户、命令行和 OpenStack 其他组件。
Nova Scheduler
当上面API的请求可以在多台实例或者节点上完成时，Scheduler可以根据当时的资源情况选择最合适的实例或者节点来执行请求。
Worker
Nova Worker其实质就是计算节点的nova-compute服务，前面Scheduler负责分发任务，而它则是负责执行任务。
Driver框架
在计算节点运行虚机，那必须要有Hypervisor来支持，而计算节点会支持多种Hypervisor（包括KVM, Hyper-V, VMWare, Xen, Docker, LXC等），nova-compute为Hypervisor定义统一接口，只要这些hypervisor实现了这些接口，就可以 以driver 的形式即插即用到 OpenStack 中，这样在技术上保持先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in），具有很大的灵活和开放性。
DB
通过数据库来维护Nova虚机的状态信息，比如MySQL会有Nova撞门的数据库。
MQ
在openstack这样的分布式系统中，一般程序的调用都是采用异步调用处理的，而nova各组件间的协同工作是通过消息队列来实现的，默认采用RabbitMQ。
一般工作流程
用户发送一个nova http请求或者服务，通常都会遵循下面的流程：
大概解释一下：
- 用户发送http请求至nova api，nova api会把这个请求放到mq；
- nova scheduler从消息队列里获取到请求，开始决定由哪个计算节点去执行请求，后把结果存放到消息队列里；
- nova compute从消息队列里知道了由哪个节点去执行请求后，分派该节点去执行用户请求并返回结果至消息队列；
- 具体执行过程中产生的一些中间态信息（比如虚机的运行状态、bdm信息等）通过nova conductor保存到数据库；
故障分析
当我们实际在虚机上进行操作时，可能会碰到各种各样的问题，这时我们可以分析nova的日志来解决，一般情况下日志会存放到/var/log/nova/目录下边，如果不够详尽，我们还可以通过修改nova配置文件（/etc/nova/nova.conf）打开debug开关来得到更详细的日志信息。
