大话openstack之RPC

sfyhip

　　openstack中的api使用规则
　　如果是跨项目的调用(如nova调用keystone,glance，cinder等)，使用rest api(通过相应的python-XXXclient库)。
　　
　　安装nova时需要依赖python-cinderclient python-neutronclien python-glanceclient python-keystoneclient，因为nova需要调用这些rest api。其他项目也有类似的依赖。
　　
　　如果是项目内跨服务调用,则使用RPC调用，通过服务提供的rpcapi.py文件。比如cinder内部，cinder-api与cinder-volume，cinder-Scheduler服务之间是使用RPC接口，即RabbitMQ消息。
　　
　　如果是项目内服务内的不同代码之间调用，就没有明确规则了，一般使用本地函数调用。
　　
　　
　　
　　RPC：
　　RPC即Remote Procedure Call(远程方法调用)，是Openstack中一种用来实现跨进程(或者跨机器)的通信机制。
　　Openstack中同项目内(如cinder)各服务(service)间通过RPC实现彼此间通信。Openstack中还有另外两种跨进程的通信方式：数据库和Rest API。
　　
　　
　　AMQP：
　　RCP只定义了一个通信接口，其底层的实现可以各不相同。目前Openstack中的主要采用AMQP来实现。AMQP(
　　Advanced Message Queuing Protocol)是一种基于队列的可靠消息服务协议，作为一种通信协议，AMQP同样存在多个实现，如Apache Qpid, RabbitMQ等。
　　具体可参考http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol。
　　
　　
　　AMQP概念
　　publisher:消息发布者
　　receiver：消息接收者
　　queue：用来保存消息的存储空间，消息没有被receiver前，保存在队列中。
　　
　　exchange：
　　exchange是一个很重要的概念。用来接收publisher发出的消息，并决定消息后续处理。后续处理取决于消息的路由算法，而路由算法又是由exchange type决定的。
　　
　　exchange type：
　　AMQP中定义的类型包括：direct, topic, headers and fanout。
　　direct：消息路由到满足此条件的队列中： routing key = binding key 
　　topic：消息路由到满足此条件的队列中(queue,可以有多个)：routing key 匹配 binding pattern. binding pattern是类似正则表达式的字符串，可以满足复杂的路由条件。
　　fanout：消息路由到多有绑定到该exchange的队列中。
　　Openstack RPC中主要用了这三种exchange type。
　　
　　binding ：binding是用来描述exchange和queue之间的关系的概念，一个exchang可以绑定多个队列，这些关系由binding建立。前面说的binding key /binding pattern也是在binding中给出。
　　每个receiver在接收消息前都需要创建binding。
　　
　　
　　对于exchange的route这个动作，有下面三类：
　　1.fan-out：不看routing key，直接把消息放到所有注册到exchange上的queue上
　　2.direct：只把消息放到和routing key有相匹配key的queue上
　　3.topic：这里的routing key和queue的key的匹配不是完全的匹配，而是一个模糊匹配。所以一个routing key可能可以匹配到多个queue
　　
　　Binding：change 如何进行路由的呢？这便依靠 Routing Key，每个消息都有一个 routing Key，而每个 Queue 都可以通过一个 Binding 将自己所感兴趣的 Routing Key 告诉 Exchange，这样 Exchange 便可以将消息正确地转发给相应的Queue。”
　　
　　routing-key（这个message提供）和binding-key（这个queue注册到exchange的时候提供）。另外exchange是有类型的（direct，topic和fanout）
　　Routing Keys：message都会有一个routing key，这个是用于exchange路由用的。exchange根据不同的类型路由方法不一样，如果是direct的，那么如果某个queue的binding key和message的routing key一样，就会把消息发送给这个queue。
　　
　　
　　RabbitMQ有一个特点：一个message只能被一个consumer处理。还有一种模式叫做publish/subscribe，后者的话我producer发出一个消息可以被多个consumer同时处理。不过其实原理上是一样的：一个queue上的一个message只能被一个consumer处理，所以如果我有n个consumer要都处理某个message，那么我需要有n个queue，并且把exchange配制成fan-out。
　　
　　一个queue可以绑定多个routing key。
　　
　　
　　
　　Openstack RPC概念
　　Openstack RPC中沿用了AMQP中的一些概念，并做了一些扩展。理解AMQP概念是理解RPC的前提。RPC中定义了如下主要概念：
　　Server：同AMQP中的receiver
　　Client：同AMQP中的publisher
　　Exchange：同AMQP中的exchange 如同路由
　　Topic：同AMQP中的topic exchange type。topic类似于面向对象中的class概念，一个topic下可以包括多个方法，client通过topic调用一个方法，
　　server也通过监听topic来提供方法调用。通常每个topic下的方法应该是逻辑上密切相关的，正如class的设计一样。
　　
　　
　　Service对象的核心功能就是创建监听队列，并将收到的消息转化为对manager对象的方法调用
　　
　　Manager对象其实就是RPC API的入口。每个RPC API最终会转化为对Manger相应方法的调用，这个方法就是该RPC API的最终实现。
　　
　　掌握了Service + Manager，基本上就了解了RPC server是如何工作的，学习openstack代码就比较直观了。
　　
　　
　　target用来指定该rpc server监听在哪些队列上。
　　target指定了2个参数：topic和server。
　　
　　底层如何使用target创建RPC队列并绑定到exchang上，可以查看代码
　　transport._listen
　　self._driver.listen(target)
　　amqpdriver.listen
　　conn.declare_topic_consumer(target.topic, listener)
　　conn.declare_topic_consumer('%s.%s' % (target.topic, target.server),
　　listener)
　　conn.declare_fanout_consumer(target.topic, listener)
　　从代码中可以看到创建了3个队列，这个3个系列用来实现3种RPC场景
　　随机调用某server上的一个方法： 通过第一个队列实现
　　调用某特定server上的一个方法： 通过第二个队列实现，这个队列通过server参数来唯一标识一个队列
　　调用所有server上的一个方法：通过第三个队列实现，exchange type为fantout类型
　　
　　
　　RabbitMQ：
　　查看队列中的消息个数：
　　
　　[iyunv@OS_DEV ~]# rabbitmqctl list_queues
　　
　　
　　查看message在queue中的情况：
　　
　　[iyunv@OS_DEV ~]# rabbitmqctl list_queues name messages_ready messages_unacknowledged
　　
　　
　　查看exchange：
　　
　　[iyunv@OS_DEV ~]# rabbitmqctl list_exchanges
　　
　　
　　查看exchange和queue的绑定：
　　
　　[iyunv@OS_DEV ~]# sudo rabbitmqctl list_bindings
　　
　　
参考链接:

 

openstack学习之RPC服务实现分析

http://blog.csdn.net/zhengleiguo/article/details/26971481

 

 openstack学习之各种API

http://blog.csdn.net/zhengleiguo/article/details/26885557

 

AMQP的学习

http://bingotree.cn/?p=185

 

kombu的学习

http://bingotree.cn/?p=204

 

nova-api初始化流程分析

http://bingotree.cn/?p=193

 

oslo.messaging组件的学习之call方法

http://bingotree.cn/?p=207

 

 

oslo.messaging组件的学习之server端的初始化

http://bingotree.cn/?p=236

 

oslo.messaging组件的学习之notify方法

http://bingotree.cn/?p=238

 

openstack中的消息队列

http://lynnkong.iyunv.com/blog/1699299

 

RabbitMQ and Oslo.messaging

http://lingxiankong.github.io/blog/2015/04/01/rabbitmq-oslo-messaging/

 

Openstack RPC 通信原理

http://www.ibm.com/developerworks/cn/cloud/library/1403_renmm_opestackrpc/

 

Oslo.Messaging 中的 Message 处理

http://blog.csdn.net/zhaoeryi/article/details/39294293

 

 AMQP & Nova
http://jzhihui.iyunv.com/blog/1497031

 

NOVA源码分析——NOVA中的RabbitMQ解析
http://blog.csdn.net/gaoxingnengjisuan/article/details/9623529

OpenStack建立实例完整过程源码详细分析（12）----依据AMQP通信架构实现消息发送机制解析之一
http://blog.csdn.net/gaoxingnengjisuan/article/details/11468061

OpenStack建立实例完整过程源码详细分析（13）----依据AMQP通信架构实现消息发送机制解析之二
http://blog.csdn.net/gaoxingnengjisuan/article/details/12230521

OpenStack建立实例完整过程源码详细分析（14）----依据AMQP通信架构实现消息接收机制解析之一
http://blog.csdn.net/gaoxingnengjisuan/article/details/12231633

OpenStack建立实例完整过程源码详细分析（15）----依据AMQP通信架构实现消息接收机制解析之二
http://blog.csdn.net/gaoxingnengjisuan/article/details/12234079