在西方有一句谚语,叫做“Don’t Reinvent the Wheel!”。直译过来就是不要在重新发明轮子了。也就是说我们应该避免做一些重复性的工作,如果一个东西别人已经做过了,那么我们拿来直接用就行了,没有必要重新制作,这一点在软件开发里尤为突出。所以在OpenStack的开发中也借鉴了这一思想,OpenStack利用了大量的现有库,这加快了OpenStack的开发,使得开发人员可以集中精力研究难点。下面我们就来一起讨论一下OpenStack的通用技术。

一、消息总线

OpenStack的设计原则:项目之间通过RESTful API进行通信;项目内部通过,不同服务进程之间通过消息总线进行通讯。 这种设计思想保证了各个项目对外可以被不同类型的客户端接受,同时也保证了内部项目通信接口的可扩展性和可靠性,以支持大规模的部署。

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

OpenStack利用开源库实现了以下两种类型的用于在内部服务进行之间的通讯。

(1)事件通知

某个服务进程可以把事件通知发送到消息总线上,该消息总线上所有对此类事件感兴趣的服务进程,都可以获得此事件通知并进行进一步的处理,但是处理的结果不会返回给事件发送者。

(2)远程过程调用(RPC)

通过远程调用,一个服务进程可以调用其他远程服务进程的方法,并且有阻塞和非阻塞两种方式。

OpenStack已经支持了一些常见的消息总线,如下表。

名称 特点 RabbitMQ 实现了AMQP的消息中间件服务,支持多种协议网关和编程语言 Qpid Apache基金会下的顶层项目,实现了AMQP协议 ZeroMQ 开源的高性能异步消息库,可以在没有Server/Broker的情况下工作 二、AMQP的实现原理

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

如上图所示,AMQP的主要参与者有以下几个:

Producer:消息的产生者 Comsumer:消息的接收者 Exchange:交换部件,根据消息的条件选择不同的消息接收者。 Queue:消息队列,暂时缓存到达消费者的消息 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会把消息缓存在内存或磁盘上。

三、基于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中获取响应。

原文链接: http://blog.csdn.net/xingjiarong/article/details/50564231