Nova-RPC rabbitmq

Nova-RPC rabbitmq的使用

英文看着有点费劲。整理成中文的吧。

RabbitMQ与NOVA

RabbitMQ是用于OpenStack云的一个消息组件。RabbitMQ位于两个nova的组件中间，从而可以让这两个组件在松耦合的情况下通信。更精确地来说，nova的组件用RPC（远程过程调用）来与另外一个组件进行交互。这种方式是建立在发布/认购范式的策略下。那么在这种情况下，有如下好处可以达到。

1、客户端和服务端的解耦合。（更多的时候，客户并不关心服务端身在何处）。

2、客户端与服务端的异步机制。因为客户端并不要求服务端的实时响应。

3、随机平衡的远程调用。比如有多个服务端在运行的时候，一般一个调用只交付给最近最可用的服务端。

Nova一般来说，支持Direct和Topic-Based消息交换。整个系统中的架构如下图。

Nova实现了RPC（包括请求与响应，以及只有请求)。

1、请求与响应：rpc.call

2、只有请求rpc.cast

通过基于AMQP的RPC类提供了一个代理类。这个类提供了函数调用时的消息的编码与解码。每个Nova服务（比如Compute服务，Volume服务，等）在初始化的时候就建立了两个队列：

1、一个接收带有routing键值NODE-TYPE.NODE-ID，比如comput.hostname. 这个是指明了主机服务类型及主机地址。

2、接收带有routing键值NODE-TYPE，比如compute。

第一个队列是用于NOVA-API把这个队列的消息定向到一个特定的节点（也就是物理主机）。比如euca-terminate-instance i-XXXXX 的时候，这种情况下，只有运行着名为i-xxxx的虚拟机的主机才需要接收这个消息，并进行响应，做出相应的动作。API扮演的角色也会因为消息的不同，而有所不同。

1、当使用RPC.CALL时API表现得像一个消费者。

2、当使用rpc.cast时，API表现得像一个publisher.

NOVA RPC 映射

下面这个图表示了当一个虚拟机开始创建并在云中运行的时候，RabbitMQ节点中的内部结构。每个NOVA组件连接到RabbitMQ，然后根据其角色，比如角色可能有Compute node, Network node。由于角色不同，那么所使用的Queue也会不同。

1、Invoker Queue。角色为API和Scheduler时使用。Invoker主要动作：通过rpc.call、rpc.cast 发送消息。

2、Woker Queue。角色为Compute, Volume, Network时使用。主要是从消息队列中拿消息，并对rpc.call做出响应。

实际上，Invoker和worker并不真正出现在NOVA的架构中，之所以这么提，完全是为了便于理解。

上面这个图，展示了内部结构：

1、Topic Publisher：会话发起人。当开始调用rpc.cast和rpc.call的时候，Topic Publisher就开始了其生命周期。这个对象被实例化并且用来压入一个消息到消息队列系统中。每个Publisher连接常常是基于同一个话题的交换的。其生命周期与消息的传递有关。

2、Direct Consumer：直接消费者。直接消费者的生成是由于rpc.all被执行的时候，这个对象被实例化然后用于接收来自于队列系统的响应消息。每个消费者连接到一个单一的direct-based交换（此交换是基于一个单一独有的队列）。其生命周期也是受限于消息传输。交换标识和队列的标识是由一个UUID生成器生成的，然后被Topic Publisher编码（仅限于rpc.call操作)。

3、Topic Consumer:一个话题消费者被唤醒并且是同量一个Worker被实例化，一起存在于整个生命周期。这个对象用于从队列中接收消息，并且此话题消费者还会调用Worker的相应的应用程序。一个Topic Consumer连接一个相同的topic-based交换。这个Topic-based交换要么是一个共享队列要么是一个独特的独享的队列。并且一个Worker有两个topic consumer:

a、一个只关心rpc.cast操作。也就是只关心其交换key是topic.

b、一个只关心rpc.call操作。也就是连接到一个独有的队列中。其交换key是topic.host.

4、Direct Publisher：一个Direct Publisher开始其生命周期是由于rpc.call的调用。其在调用的同时，被实例化并且把消息返回到请求/响应操作。这个对象被连接到一个direct-based交换。这个交换是由到来的消息所标识。

 juacm