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