【OpenStack源码分析之七】openstack中的RPC请求分析

转自：http://blog.csdn.net/hhp_hhp/article/details/51497560

概述

在OpenStack各个项目中，我们通常会用到如下几种RPC请求：

RPC.call：发送请求到消息队列，等待返回最终结果。
RPC.cast：发送请求到消息队列，不需要等待最终返回的结果。
RPC.Notifier：发送各类操作消息到队列，不需要等待最终的返回结果。
RPC.call、RPC.cast一般用于同一个项目下的服务之间进行的“内部“请求；RPC.Notifier发送的操作消息，目前被ceilometer notification服务所接收。

RPC.call & RPC.cast

一般情况下，openstack各个项目之间通过RestAPI接口进行相互访问，而项目内部服务之间则通过RPC请求的方式进行通信。

RPC.call 请求

对于RPC.call请求，借助官方一张经典的图来描述：

以nova-compute服务调用nova-network服务分配网络为例：
1. nova-compute服务向消息队列服务的compute.node队列发送RPC请求，并等待请求的最终回复。
2. nova-network服务通过nova exchange（topic exchange）从compute.node队列中获取消息并作出相应的处理。
3. nova-network服务消息处理完了之后，向reply_XXX队列发送一条回复消息
4. nova-compute服务通过reply_XXX exchange（direct exchange）接受从nova-network发送的RPC消息。

RPC.cast请求

对于RPC.cast请求，同样借助官方一张经典的图来描述：

以nova-conductor服务调用nova-compute服务build_and_run_instance为例：
1. nova-conductor服务向消息队列服务的compute队列发送RPC请求，请求结束，不需要等待请求的最终回复。
2. nova-compute服务通过nova exchange（topic exchange）从compute队列中获取消息并作出相应的处理。

在openstack项目中，一般情况下，RPC server端发送一个请求到消息队列，一般只有一个消费者（及时有多个消费者）接受并处理这条消息，还有一种类型的RPC.cast请求，也称为fanout_cast请求，fanout_cast发送的是广播请求，所有对应的consumer都能接收到。

RPC.Notifier

openstack中对于资源的操作，如创建虚拟机，会向向消息队列的notifications.info，notifications.warn，notifications.error等队列发送对应的RPC消息，而ceilometer的notification服务会充当RPC 消费者端，获取对应的操作消息进行处理。
RPC.Notifier提供的notifier消息有如下几种：

• audit：审计类消息，如compute.instance.exist
• info：正常操作消息，如compute.instance.create.end
• warn：告警类操作消息，暂无
• error：错误类操作消息，如scheduler.run_instance
• critical：严重错误，暂无
• sample：sample消息，ceilometer中使用

实际上openstack RPC notifier消息就是topic类型的消息，以虚拟机开始创建为例：
1. nova-compute服务向消息队列服务的notifications.info队列发送RPC消息。
2. ceilometer-agent-notification服务通过nova exchange（topic exchange）从notifications.info队列中获取消息并作出相应的处理。