11.3.1 基于消息通信的RPC调用之 AMQP简介

RESTful API是一套基于HTTP协议的通信机制。但是，这样的通信机制存在一下不足：

(1)、由于采用的是HTTP协议，客户端服务器之间所能传送的消息仅限于
文本。

(2)、客户端与服务器之间采用同步机制。当发送HTTP请求时，客户端需要等待服务器的响应。

(3)、客户端和服务器之间可以单独开发，但是还是存在耦合。例如：客户端发送请求时，必须知道服务器的地址，且保证服务器正常

工作。

基于以上原因。openstack采用另外一种远程通信机制---RPC调用(远程过程调用，进行间通信机制，允许计算机程序调用其他计算

机的子过程或者过程)。在openstack中，RPC采用 AMQP 协议实现进程间通信。 在openstack中，采用的是RabbitMQ 和 Qpid。

AMQP简介

AMQP(高级消息队列协议)是一个基于消息的中间件提供的开放的应用层标准协议。能够有效支持各种通信模型或者报文传送方面的

应用。一个完整的AMQP规格包括以下几个方面的性质：

(1)类型系统

AMQP是一套二进制的应用层通信协议。它自定义了一套自描述的编码方案，使得它能够表示多种多样的常用数据类

型。允许类型化的数据被赋予额外的意义。例：一个键值对构成的字典，可能注释为一个自定义数据类型。

(2)进程间对称的异步通信协议

AMQP中，进程间通信多是采用点对点，或者发布者--订阅者模型。 通常情况，由一个中间件实现消息队列的管理。通信进程双方

地位是均等的。 发布者不需要知道订阅者是否存在，而订阅者也无需知道自己消费的是哪个发布者的消息。这样的松耦合性，决

定AMQP协议比传统的客户端--服务器通信模型具有更强的可扩展性。

(3)消息格式

在AMQP中，将进程间传递的消息称作是裸消息。 裸消息：消息头(用户ID、消息主题和创建时间等)和消息体(应用程序需要真正传

递的数据，也称应用消息)。裸消息在进程间通信过程中是不可改变的。当消息传送到中间节点，允许被注释。

(4)一系列标准化的但可扩展的"消息能力"

 当两个节点通过AMQP通信时，他们不需要知道对方节点是什么节点，也不需要知道对方节点是如何处理发送的消息。
 订阅者可以拒绝或者接收发布者发送的消息
 当有多个订阅者时，可采用竞争或非竞争的策略决定由哪个订阅者处理消息
 可以根据需求自动地增加或删除节点
 可以通过过滤器，修改订阅者的兴趣(倾向于接收哪种类型的消息)

AMQP模型：发布者、中间件、订阅者3个部件构成。  发布者和订阅者相对比较简单，中间件是连接发布者和订阅者的桥梁。

发布者首先将消息发送给中间件，中间件将消息存储到消息队列中，最后订阅者从消息队列中获取消息。

中间件的功能：消息的存储、交换和路由