OpenStack设计与实现4——消息总线（AMQP）

OpenStack设计与实现4——消息总线（AMQP）

Tips：文章为拜读@xingjiarong 后有感而作的分享，先对做者表示感谢，附原文地址：http://blog.csdn.net/xingjiarong

0. 引言

• 在西方有一句谚语，叫作“Don’t Reinvent the Wheel！”。直译过来就是不要在从新发明轮子了。也就是说咱们应该避免作一些重复性的工做，若是一个东西别人已经作过了，那么咱们拿来直接用就好了，没有必要从新制做，这一点在软件开发里尤其突出。因此在OpenStack的开发中也借鉴了这一思想，OpenStack利用了大量的现有库，这加快了OpenStack的开发，使得开发人员能够集中精力研究难点。下面咱们就来一块儿讨论一下OpenStack的通用技术。

1. 消息总线

• OpenStack的设计原则：

  1. 项目之间经过RESTful API进行通讯；

  2. 项目内部经过，不一样服务进程之间经过消息总线进行通信。

• 这种设计思想保证了各个项目对外能够被不一样类型的客户端接受，同时也保证了内部项目通讯接口的可扩展性和可靠性，以支持大规模的部署。

• 软件的开发经历了三个阶段，从最初的面向过程到面向对象，而后再到面向服务。在面向服务的软件开发中，咱们须要考虑的就是如何保持各个服务之间的通讯。这里OpenStack借鉴了计算机硬件总线的思想，引入了消息总线。一些服务向总线上发送消息，另外一些服务从总线上获取获取消息。

• OpenStack利用开源库实现了如下两种类型的用于在内部服务进行之间的通信：

  1. 事件通知
     某个服务进程能够把事件通知发送到消息总线上，该消息总线上全部对此类事件感兴趣的服务进程，均可以得到此事件通知并进行进一步的处理，可是处理的结果不会返回给事件发送者。

  2. 远程过程调用（RPC）
     经过远程调用，一个服务进程能够调用其余远程服务进程的方法，而且有阻塞和非阻塞两种方式。

• OpenStack已经支持了一些常见的消息总线，以下表。

名称	特色
RabbitMQ	实现了AMQP的消息中间件服务，支持多种协议网关和编程语言
Qpid	Apache基金会下的顶层项目，实现了AMQP协议
ZeroMQ	开源的高性能异步消息库，能够在没有Server/Broker的状况下工做

2. AMQP的实现原理

• OpenStack所支持的消息总线类型中（上表），大部分是基于AMQP（Advanced Message Queuing Protocol）的，AMQP是一个异步消息传递所使用的开放的应用层协议规范，主要包括了消息的导向、队列、路由、可靠性和安全性。下面咱们来详细的学习一下AMQP的原理。
  

• 如上图所示，AMQP的主要参与者有如下几个：

  1. Producer：消息的产生者

  2. Comsumer：消息的接收者

  3. Exchange：交换部件，根据消息的条件选择不一样的消息接收者。

  4. Queue：消息队列，暂时缓存到达消费者的消息

  5. Server/Broker：实现了AMQP的中间件服务

• 消息的传递过程：

  1. 产生
     生产者服务器进程产生消息，消息是由消息头和消息体组成的，消息头指定了消息的接收条件，即哪些接收者能够接收这条消息。

  2. 交换（路由）
     Exchange部件相似于网络中的路由器，负责将消息转发到合适的接收者那里。在Exchange有一张表格，相似于路由表。在这张表中存放了全部的Queue的binding key，binding key的做用就是表示这个queue能够接收那些类型的消息。同时每个消息头中都携带着一个routing key，表示这条消息能够被那些Queue接收。当一条消息到达Exchange时，Exchange会遍历这张表格，若是一个Queue的bing key与消息的routing key相匹配，那么就将消息转发到这个Queue。Exchange与路由器同样，经过通配符也能够支持多播（组播）和广播。

  3. 缓存
     Queue是接收者的缓存部件，是为了防止消费者没法接收消息，或者接收消息的速度不够快时消息不会被新到的消息覆盖。Queue会把消息缓存在内存或磁盘上。

3. 基于AMQPRPC的实现原理

• 消息发送过程：

  1. 客户端发送一个请求消息给Exchange，指定routing key为”op_queue“，同时指明一个消息队列名用来获取响应，图中为“res_queue”。

  2. Exhange把此消息转发到消息队列op_queue。

  3. 消息队列op_queue把消息推送到服务端，服务端执行此RPC调用对应的任务。执行结束后，服务端把响应的结果发送给消息队列，指明routing key为”res_queue“。

  4. Exchange把此消息转发到消息队列res_queue。

  5. 客户端从消息队列res_queue中获取响应。