openstack rpc机制

王艳玲

一、概述：
　　在openstack项目中，api的调用规则：
　　跨项目：如nova调用keystone， glance，cinder等，使用rest api（通过相应的python-XXXclient 库）
　　项目内跨服务调用，使用RPC调用，通过服务提供的rpcapi.py文件，比如cinder内部，cinder-api与cinder-volume，cinder-scheduler服务之间使用RPC接口，即RabbitMQ消息；
　　cinder系统结构图：

　　cinder-api是cinder 服务的endpoint， 提供了rest接口，负责处理client的请求，并将rest请求解封，并重新封装成RPC请求至cinder-scheduler组件；
　　除dashboard之外，所有的服务均有XXX-api作为XXX服务的endpoint，提供rest 接口，负责处理XXXclient 的请求：



[iyunv@TS-M2-Cloud172 ~(keystone_admin)]# openstack-service list |grep api
openstack-ceilometer-api
openstack-cinder-api
openstack-glance-api
openstack-nova-api
二、openstack RPC通信
　　openstack组件内部的RPC（Remote Producer Call）机制的实现是基于AMQP协议作为通讯模型，从而组件内部的松耦合性。AMQP是用于异步消息通讯的消息中间件协议;AMQP模型有四个重要的角色：

• Exchange： 根据Routing key转发消息到对应的Message Queue中；
  
• Routing key: 用于Exchange判断那些消息需要发送对应的Message Queue
  
• Publisher： 消息发送者，将消息发送的Exchange并指明Routing Key，以便Message Queue可以正确的收到消息；
  
• Consumer：消息接受者，从Message Queue获取消息；　　　
  

　　消息发布者 Publisher 将 Message 发送给 Exchange 并且说明 Routing Key。Exchange 负责根据 Message 的 Routing Key 进行路由，将 Message 正确地转发给相应的 Message Queue。监听在 Message Queue 上的 Consumer 将会从 Queue 中读取消息。
　　Routing Key 是 Exchange 转发信息的依据，因此每个消息都有一个 Routing Key 表明可以接受消息的目的地址，而每个 Message Queue 都可以通过将自己想要接收的 Routing Key 告诉 Exchange 进行 binding，这样 Exchange 就可以将消息正确地转发给相应的 Message Queue。

　　OpenStack层封装call和cast接口用于远程调用RPC的server上的方法，这些方法都是构造RPC的server的endpoints内的方法。远程调用时，需要提供一个字典对象来指明调用的上下文，调用方法的名字和传递给调用方法的参数(用字典表示)。如：
　　　　　　cctxt =self.client.prepare(vesion=’2.0’)
　　　　　　cctxt.cast(context,‘build_instances’, **kw)
　　通过cast方式的远程调用，请求发送后就直接返回了；通过call方式远程调用，需要等响应从服务器返回。