大话openstack之RPC

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：

查看队列中的消息个数：

 

[root@OS_DEV ~]# rabbitmqctl list_queues

 

 

查看message在queue中的情况：

 

[root@OS_DEV ~]# rabbitmqctl list_queues name messages_ready messages_unacknowledged

 

 

查看exchange：

 

[root@OS_DEV ~]# rabbitmqctl list_exchanges

 

 

查看exchange和queue的绑定：

 

[root@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.iteye.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.iteye.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