openstack cinder，及AMQP（Advanced Message Queuing Protocol）RPC

Cinder是OpenStack的块存储服务，类似AWS的EBS，管理的实体为volume。Cinder并没有实现volume provide功能，而是负责管理各种存储系统的volume，比如Ceph、fujitsu、netapp等，支持volume的创建、快照、备份等功能，对接的存储系统我们称为backend。只要实现了cinder/volume/driver.py中VolumeDriver类定义的接口，Cinder就可以对接该存储系统。

Cinder不仅支持本地volume的管理，还能把本地volume备份到远端存储系统中，比如备份到另一个Ceph集群或者Swift对象存储系统中
一 cinder各组件
二 cinder架构图
三 RPC机制
一 cinder各组件
1、cinder主要组成:
restful 接口，处理用户请求的一个endpoint(url),转发RPC请求到cinder-scheduler组件。
#cinder-api： 是 cinder 服务的 endpoint，提供 rest 接口，负责处理 client 请求，并将 RPC 请求发送至 cinder-scheduler 组件。

#cinder-scheduler
Cinder-scheduler 负责cinder的请求的调度，其核心部分就是 scheduler_driver, 作为scheduler_management的driver，负责 cinder-volume具体的调度处理，发送 cinder RPC 请求到选择的 cinder-volume。

#cinder-volume:
#Cinder-volume 负责具体的 volume 请求处理，由不同后端存储提供 volume 存储空间。目前各大存储厂商已经积极地将存储产品的 driver 贡献到 cinder 社区
3、nova与cinder的工作原理类似

复制代码
nova主要组成:

#nova-api restful 接口，名词后面加操作 …/volume/add

#nova-scheduler 起到的是调度分配的作用

#nova-compute

#nova-conductor
cinder框架：

openstack组件间通信:调用各组件api提供的rest接口，组件内通信:基于rpc(远程过程调用)机制，而rpc机制是基于AMQP模型实现的
注：queue是按照路由来分配的。

从rpc使用的角度出发，nova，neutron，和cinder的流程是相似的，我们以cinder为例阐述rpc机制：

三 RPC机制

异步：不用等待上一个任务的结束后，才能执行下一个任务。
同步：只有等待上一个任务的结束后才能执行下一个任务。
Openstack 组件内部的 RPC（Remote Producer Call）机制的实现是基于 AMQP(Advanced Message Queuing Protocol)作为通讯模型，从而满足组件内部的松耦合性。AMQP 是用于异步消息通讯的消息中间件协议，AMQP 模型有四个重要的角色:
Publisher：消息发送者，将消息发送的 Exchange 并指明 Routing Key，以便 Message Queue 可以正确的收到消息
Exchange：根据 Routing key 转发消息到对应的 Message Queue 中.
Routing key：用于 Exchange 判断哪些消息需要发送对应的 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。
Publisher可以分为4类：

Direct Publisher发送点对点的消息；

Topic Publisher采用“发布——订阅”模式发送消息；

Fanout Publisher发送广播消息的发送；

Notify Publisher同Topic Publisher，发送 Notification 相关的消息
**Exchange可以分为3类：**

1.Direct Exchange根据Routing Key进行精确匹配，只有对应的 Message Queue 会接受到消息；

2.Topic Exchange根据Routing Key进行模式匹配，只要符合模式匹配的Message Queue都会收到消息；

3.Fanout Exchange将消息转发给所有绑定的Message Queue。
AMQP消息模型

Client 端发送 RPC 请求由 publisher 发送消息并声明消息地址，consumer 接收消息并进行消息处理，如果需要消息应答则返回处理请求的结果消息。
OpenStack RPC 模块提供了 rpc.call，rpc.cast, rpc.fanout_cast 三种 RPC 调用方法，发送和接收 RPC 请求。
1.rpc.call 发送 RPC 请求并返回请求处理结果，请求处理流程如图 所示，由 Topic Publisher 发送消息，Topic Exchange 根据消息地址进行消息转发至对应的 Message Queue 中，Topic Consumer 监听 Message Queue，发现需要处理的消息则进行消息处理，并由 Direct Publisher 将请求处理结果消息转发到即将创建的 Direct Consumer ，请求发送方创建 Direct Consumer 监听消息的返回结果

2.rpc.cast 发送 RPC 请求无返回，请求处理流程如图 所示，与 rpc.call 不同之处在于，不需要请求处理结果的返回，因此没有 Direct Publisher 和 Direct Consumer 处理。

3.rpc.fanout_cast 用于发送 RPC 广播信息无返回结果