Nova几个简单的概念--有助于OpenStack的源码理解

本文主要是介绍Nova几个简单的概念--有助于OpenStack的源码理解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本人虾悠悠 QQ：617600535 邮箱：leezhoucloud@gmail.com，欢迎交流。

发现前面几篇博文，字体略显大啊，好吧，从这篇开始，把字体都改成"特小"吧。

这一篇博文，主要分为以下几个部分：

1、OpenStack API的类型，通过这一部分学习，使大家在阅读源码时候，对OpenStack 的API有一个基本的了解，虽然粗陋，但是非常有助于入门者对于代码的理解。

2、service、manager、driver之间的关系，通过这块，会让大家简单了解到OpenStack的一个设计思想，同样非常有助于大家对代码的理解。

3、组件之间（比如Scheduler和Nova）到底是如何传递消息的，通过这块，大家可以把之前翻译的《OpenStack之AMQP原理介绍(Rabbit MQ》联系起来，通过这两部分的学习，让rpc机制能在自己的大脑中跑起来。同时，再补充一点关于rpc_dispatcher的概念。

4、关于rpc_dispatcher，通过这个我们可以知道守护进程server接收到请求后，怎么把请求转发给manage（即调用manager中的方法去执行）

这篇博文多是讲简单概念为主，东西并不深入，只是我作为初学者的一个简单理解而已，希望能对还没入门的同学有一个帮助。简单的理解，有助于我们把问题简化，先把整个东西串起来，脑子中有印象。在此基础上，我们更加需要对Python代码的细致分析，这就需要我继续努力了，加油咯。

有讲错的地方，希望路过的大神，能够帮我纠正一下，好让我别在错误的道路上越走越远，谢谢了。

（一) OpenStack API类型

（1）nova-api 起到了Cloud Controller的作用，主要为所有的API查询提供了一个接口（比如Openstack API ，EC2 API），引发多数业务流程的活动（如运行一个实例），并实施一些政策（主要是配额检查）。----这个api会在具体Scheduler 时候讲到。

（2）这里分析一下OpenStack中的几种常见api类型。

第一种：程序内部的api主要是给本机程序内部使用，如/nova/compute/api.py文件中的API主要是为了给manager去调用，其中调用哪个API也是利用OpenStack中非常重要的动态载入方法来确定的，非常灵活。

第二种：RpcAPI，就是通过高级消息队列的方式，实现不同主机的方法的远程调用。如/nova/compute/rpcapi.py，其中调用的方法都是manager中的方法。

第三种：api就是通过web资源的方式暴露给外界的api，将提供的服务暴露成web资源，可以方便外界的访问。（关于WSGI可以另外写一个话题，现在暂时不研究这个）

（二）server、manager、driver关系

（1）server是一个服务进程，类似于Linux中的守护进程。一个server对应一个RpcAPI,接收特定topic的消息。server接收到请求之后，会转发给manager去处理。一个server具体有什么功能，由manager来决定。

（2） manager顾名思义，一个服务请求的管理者，处理者，不做实际的工作。

（3）而driver就相当于一个workers，实际的工作都由它来完成。

（4）按照OpenStack的官方定义，一个manager可以对应有多个driver。简单来说，driver可以理解为一个适配器，比如调度，我们可以选择chance方法的调度，也可以选择FilterScheduler的调度器，这就是两个不同的drivers。同样。这在Compute虚拟化层特别明显，比如虚拟化层可以xem，kvm技术，不同技术，driver不一样。

基于以上四点+外加（二），我们把上面的分类和设计思想，套用到代码的学习当中，那么我们就拥有了一条学习OpenStack源码的捷径，亲们，试试吧。相信短时间内，咱们就会对OpenStack源码有一个整体的了解。

（三）组件之间（比如Scheduler和Nova）到底是如何传递消息的

先来简单介绍一下，两个组件：

nova-schedule ：接受一个消息队列的虚拟实例请求，通过算法决定该请求应该在那台主机上运行，这个算法可以由我们指定。即起到调度器（Scheduler）的作用。nova-compute：是一个非常重要的守护进程，负责创建和终止虚拟机实例，即管理着虚拟机实例的生命周期。该模块内部非常复杂，基本原理是简单的，就是接受来自队列的动作然后执行一些列的系统操作（如启动一个KVM实例），并且更新数据库的状态。

接下来，就从一个简单的例子，来简单讲述下，如何实现两个组件之间消息的传递；

1、Scheduler完成调度过，需要将过滤完成后，把选出来compute node发送给相应的节点，并且让该节点启动一个虚拟机实例。

/nova/scheduler/filter_scheduler.py
找到def _provision_resource最后一句调用self.compute_rpcapi.run_instance(context,instance=updated_instance,host=weighed_host.obj.host,request_spec=request_spec,filter_properties=filter_properties,requested_networks=requested_networks,injected_files=injected_files,admin_password=admin_password, is_first_time=is_first_time,node=weighed_host.obj.nodename,legacy_bdm_in_spec=legacy_bdm_in_spec)

2、开始调用Compute的RpcAPI接口,找到/nova/compute/rpcapi.py文件，并找到run_instance方法

  def run_instance(self, ctxt, instance, host, request_spec,filter_properties, requested_networks,injected_files, admin_password,is_first_time, node=None, legacy_bdm_in_spec=True):instance_p = jsonutils.to_primitive(instance)msg_kwargs = {'instance': instance_p, 'request_spec': request_spec,'filter_properties': filter_properties,'requested_networks': requested_networks,'injected_files': injected_files,'admin_password': admin_password,'is_first_time': is_first_time, 'node': node}if self.client.can_send_version('2.37'):version = '2.37'msg_kwargs['legacy_bdm_in_spec'] = legacy_bdm_in_specelse:version = '2.19'cctxt = self.client.prepare(server=host, version=version)cctxt.cast(ctxt, 'run_instance', **msg_kwargs)

A）注意到最后一行， cctxt.cast(ctxt, 'run_instance', **msg_kwargs)，这就是非常关键的，一直在讲的RPC调用。

scheduler将需要运行的方法通过rpc机制发送给需要启动虚拟机的compute node的服务程序，守护服务进程接收命令后，由compute-manager处理该请求，最后实现虚拟机的启动。

当初没有理解AMQP机制的时候，一直被Scheduler如何把消息发送给Compute给纠结了好几天。-_-！

B）看到cast传递了两个参数，'run_instance',以及'msg_kwargs'。

（1）run_instance是一个方法，记得前面讲的service、manager、driver关系么，Scheduler通过rpc把该方法，传递给了compute服务（守护进程）中一直在监听的consumer绿色线程，然后server守护进程把方法传给manager（即调用manager中的run_instance方法）去执行这个方法。

（2）msg_kwargs的话，是一个字典，可以理解为把run_instance()方法需要的参数，打包到一起发送给compute node，再由compute服务的consumer把参数解析出来。

（四）关于rpc_dispatcher

1、我们再回头来看看，创建一个守护进程的步骤，首先，获取一个conn对象连接到rabbitMQ服务器，再创建3个consumer，再把consumer放到绿色线程中。

		#获取一个连接到rabbit MQ的连接self.conn = rpc.create_connection(new=True)LOG.debug(_("Creating Consumer connection for Service %s") %self.topic)#注册一个rpc_dispatcher，该对象与回调函数callback有关#MQ过来的消息，由rpc_dispatcher处理，具体函数在manager下定义rpc_dispatcher = self.manager.create_rpc_dispatcher(self.backdoor_port)#创建第一个RPC的consumer，格式为topic.node# Share this same connection for these Consumersself.conn.create_consumer(self.topic, rpc_dispatcher, fanout=False)#创建一个RPC的consumer，格式为topic.node.host[1,N]node_topic = '%s.%s' % (self.topic, self.host)self.conn.create_consumer(node_topic, rpc_dispatcher, fanout=False)#再创建一个consumer，但是只用在在Scheduler更新信息的时候self.conn.create_consumer(self.topic, rpc_dispatcher, fanout=True)#把RPC服务放到一个绿色线程中开始执行# Consume from all consumers in a threadself.conn.consume_in_thread()

重点看下面这两行代码

1、rpc_dispatcher = self.manager.create_rpc_dispatcher(self.backdoor_port)

2、self.conn.create_consumer(self.topic, rpc_dispatcher, fanout=False)

在consumer创建的时候，已经注册了callback函数，因为发送到server有不同的请求msg｛method：**kwargs｝，当consumer取出msg后，设计了一个rpcproxy来处理不同的msg。因为rpc_dispatcher属性里面含有callback，所以，dispatcher就可以理解为我们需要的callback函数。

再者，因为msg特别多，执行任务长，所以对于每个任务都创建了一个绿色线程去执行。

3、存在一个conn来连接RabbitMQ，因为我们同时需要多个connection，故使用eventlets.pools.pool来维护一个全局的pool，来管理这些connection。

总之，rpc_dispatcher = callback, server守护进程接收到请求后，由rpc_dispatcher的dispatch()方法执行msg｛method：**kwargs｝中的method方法（即调用对应的manager如compute-manager的run_instance执行）。

好了，以上四个问题，是我自己的一个小总结，希望对大家看代码有一定的帮助。

食堂饭菜不给力，这会就饿了，可能后面两部分写的不好，下次再看看有无错误。有需要的话我会附上几张流程图，让大家

看的更加形象一点。

先吃饭了。。。扛不牢了