本人虾悠悠 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)
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_spec
else:
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 Consumers
self.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 thread
self.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执行）。
好了，以上四个问题，是我自己的一个小总结，希望对大家看代码有一定的帮助。
食堂饭菜不给力，这会就饿了，可能后面两部分写的不好，下次再看看有无错误。有需要的话我会附上几张流程图，让大家
看的更加形象一点。
先吃饭了。。。扛不牢了
1385
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
