Openstack Nova(三)----架构（二）

在上一章中， 我们从基本的需求出发， 得到了一个简单的模型。通过和Openstack文档的架构对比，可以发现我们自己设计的模型已经非常接近它的实际实现, 这章中， 我们将继续分析需求， 然后确定一些细节问题。

接口(Interface)

云时代， 你会听到各种各样的平台， 然后他们提供接口，让第三方能够通过这些接口接入，对其提供对应的服务。比如说Google, Facebook, QQ等， 在这些接口中，数据基本上都是通过XML或是JSON来传输。而服务类型也基本上都为HTTP模式。所以在Openstack中，同样是选择了HTTP的JSON及XML RESTful风格来作为接口。

既然要使用HTTP， 那么就得有服务器， 这年头除了云， 还有个词很流行， 那就是协程， 因为协程解决了多线程的调度问题， 使得它能高效的处理任务，使得它是并发处理中变得非常通用。Openstack中同样使用了它。

既然基本的接口为HTTP的RESTful风格， 但是对管理员和用户来说， 他们是不可能直接使用HTTP来进行操作的。所以在此基础上， 还得实现基于命令行的接口，当然，图形界面如此发达的今天， 这个也是必不可少的，所以Openstack还得实现图形界面的接口， 当然这都不是Nova的的工作内容。但都是以Nova为基础。

Driver, Manager 及Controller

在Openstack中， 或是说在很多应用开发中， 都会碰到一个功能， 多种不同的实现。然后我们还得支持这种不同的实现，使得上层用户感知不到这些不同实现之间的差别。 比如说Openstack中的消息，首先它选择了AMQP协议的消息队列， 但是基于AMQP的实现有很多，如ZMQ, QPID, RabbitMQ等， 而且也想让用户能够通过配置或命令来使用不同的实现。 像这样的问题， Openstack中还有不少， 比如说数据库， 虚拟化技术， 硬盘， 网络等。

基于这个需求， 就必须得有一种设计， 使得它们能有一个共用的框架，然后把这些有效的组织起来。在Openstack中， 选择了一种Driver， Manager，Controller的方式。 在Openstack的代码中， 你会发现各种类似这样的模式。

Driver

Driver是对具体实现的一种抽象，用来消除各种实现之间的差异， 然后提供统一的接口给Manager。 比如说AMQP， ZMQ和QPID有不同的实现方式和接口，但在ZMQ和QPID之上， 再封装一层接口， 这样对于消息的Manager来说，就有了相同的接口。在比如说Hypervisors, 现有的实现有KVM/QEMU, XEN, VMWare， Docker等， 对于每种实现来说，他们的接口完全不一样，甚至基本的思想都不一样，比如说Docker，根本就没有虚拟机的概念， 但对用户来说，他只需要告诉Openstack，我要用那一种Hypervisor, 然后Openstack就得去执行。对于上层逻辑来说, 它也不需要去关心， 这个时候， Driver的价值就出来了，它能提供给上层统一的接口。

Manager

明白了Driver， 对于Manager来说就简单了， 它把所有的Driver管理起来， 然后在使用的时候，根据环境和参数来决定使用那个Driver。它的作用是更一步的对具体的实现抽象。 还是拿Hypervisor来说， 比如用户需要创建一个Instance(虚拟机)， Manager就要根据当前的环境来选择是使用KVM/QEMU， 还是XEN， 或是其它的。这样对更上一层的应用来说，基本上就不用去关心的底层的具体实现了。

Controller

Controller就是MVC中的C了， 放在这里，是因为它和Manager有着很强的关系。 Controller是具体的逻辑实现层，它对外提供了具体的操作(Action). 比如说对象的CRUD， Instance的迁移等， 它是面向HTTP服务的控制器。但是它的底层操作是通过Manager来实现的。

最后， 我们用一张图来说明下这三者的关系。

图1 Driver, Manager & Controller

总结

结合前一章的内容，再看看前面的架构图.

图2 Nova

然后把这两个结合起来， Nova的整体架构基本上就全出来了。比如说图2中的nova-compute就相当于ComputeController. 然后Nova-volume， Nova-Network，Nova-Database, Queue都基本上有相同或相似的结构。