OpenStack设计与实现4——消息总线（AMQP）
Tips：文章为拜读@xingjiarong 后有感而做的分享，先对作者表示感谢，附原文地址：http://blog.csdn.net/xingjiarong
0. 引言
在西方有一句谚语，叫做“Don’t Reinvent the Wheel！”。直译过来就是不要在重新发明轮子了。也就是说我们应该避免做一些重复性的工作，如果一个东西别人已经做过了，那么我们拿来直接用就行了，没有必要重新制作，这一点在软件开发里尤为突出。所以在OpenStack的开发中也借鉴了这一思想，OpenStack利用了大量的现有库，这加快了OpenStack的开发，使得开发人员可以集中精力研究难点。下面我们就来一起讨论一下OpenStack的通用技术。
1. 消息总线
-
OpenStack的设计原则：
项目之间通过RESTful API进行通信；
项目内部通过，不同服务进程之间通过消息总线进行通讯。
这种设计思想保证了各个项目对外可以被不同类型的客户端接受，同时也保证了内部项目通信接口的可扩展性和可靠性，以支持大规模的部署。
软件的开发经历了三个阶段，从最初的面向过程到面向对象，然后再到面向服务。在面向服务的软件开发中，我们需要考虑的就是如何保持各个服务之间的通信。这里OpenStack借鉴了计算机硬件总线的思想，引入了消息总线。一些服务向总线上发送消息，另一些服务从总线上获取获取消息。
-
OpenStack利用开源库实现了以下两种类型的用于在内部服务进行之间的通讯：
事件通知
某个服务进程可以把事件通知发送到消息总线上，该消息总线上所有对此类事件感兴趣的服务进程，都可以获得此事件通知并进行进一步的处理，但是处理的结果不会返回给事件发送者。远程过程调用（RPC）
通过远程调用，一个服务进程可以调用其他远程服务进程的方法，并且有阻塞和非阻塞两种方式。
OpenStack已经支持了一些常见的消息总线，如下表。
| 名称 | 特点 |
|---|---|
| RabbitMQ | 实现了AMQP的消息中间件服务，支持多种协议网关和编程语言 |
| Qpid | Apache基金会下的顶层项目，实现了AMQP协议 |
| ZeroMQ | 开源的高性能异步消息库，可以在没有Server/Broker的情况下工作 |
2. AMQP的实现原理
OpenStack所支持的消息总线类型中（上表），大部分是基于AMQP（Advanced Message Queuing Protocol）的，AMQP是一个异步消息传递所使用的开放的应用层协议规范，主要包括了消息的导向、队列、路由、可靠性和安全性。下面我们来详细的学习一下AMQP的原理。
-
如上图所示，AMQP的主要参与者有以下几个：
Producer：消息的产生者
Comsumer：消息的接收者
Exchange：交换部件，根据消息的条件选择不同的消息接收者。
Queue：消息队列，暂时缓存到达消费者的消息
Server/Broker：实现了AMQP的中间件服务
-
消息的传递过程：
产生
生产者服务器进程产生消息，消息是由消息头和消息体组成的，消息头指定了消息的接收条件，即哪些接收者可以接收这条消息。交换（路由）
Exchange部件类似于网络中的路由器，负责将消息转发到合适的接收者那里。在Exchange有一张表格，类似于路由表。在这张表中存放了所有的Queue的binding key，binding key的作用就是表示这个queue可以接收那些类型的消息。同时每一个消息头中都携带着一个routing key，表示这条消息可以被那些Queue接收。当一条消息到达Exchange时，Exchange会遍历这张表格，如果一个Queue的bing key与消息的routing key相匹配，那么就将消息转发到这个Queue。Exchange与路由器一样，通过通配符也可以支持多播（组播）和广播。缓存
Queue是接收者的缓存部件，是为了防止消费者无法接收消息，或者接收消息的速度不够快时消息不会被新到的消息覆盖。Queue会把消息缓存在内存或磁盘上。
3. 基于AMQPRPC的实现原理
-
消息发送过程：
客户端发送一个请求消息给Exchange，指定routing key为”op_queue“，同时指明一个消息队列名用来获取响应，图中为“res_queue”。
Exhange把此消息转发到消息队列op_queue。
消息队列op_queue把消息推送到服务端，服务端执行此RPC调用对应的任务。执行结束后，服务端把响应的结果发送给消息队列，指明routing key为”res_queue“。
Exchange把此消息转发到消息队列res_queue。
客户端从消息队列res_queue中获取响应。
