【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队列中获取消息并作出相应的处理。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值