OPENSTACK的可伸縮架構的基礎 RPC

RabbitMQ的功能之一就是實現RPC（Remote Process Call），OpenStack的各個元件就是通過RPC來進行通訊的，通訊內容走OpenStack內部網路中的管理網路。每個元件內部又通過不同的服務來完成不同的工作，比如資料庫訪問，接受API請求等。

如果從RPC的角度進行簡化，OpenStack中各元件的服務按角色分為兩種：RPC client／RPC server。各個元件模組通過RPC呼叫，作為RPC client傳送message到RabbitMQ，RabbitMQ作為message broker，將訊息分發到相應的queue中去，元件中負責接收訊息的RPC server接收message，根據message內容執行相應的操作，比如操作資料庫，或者執行作業系統的命令等。

從外部看OpenStack叢集，各個功能元件的API service提供RESTful API訪問，使用者或者元件都可以使用API獲得服務。 從叢集內部看，功能元件內部的各種服務通過RPC呼叫完成各個任務的銜接，最終完成使用者提交的一項任務。RabbitMQ作為提供RPC功能的Message broker，通過message連線各個服務，處在OpenStack叢集的中心環節。 因此處在中心環節的RabbitMQ對整個OpenStack叢集的穩定性和效能起著舉足輕重的作用。

下面這張圖用圖示的方式展現了“boot from volume”這樣一個使用者請求的主要步驟，元件中的各個服務通過rpc.call和rpc.cast訪問RabbitMQ。 使用者請求的大部分動作都需要橢圓形中的RabbitMQ完成連線。

“boot from volume”使用者請求的主要步驟

RabbitMQ提供了多種語言的binding，方便使用者使用它的服務。對於Python來講，用來構建／訪問RabbitMQ服務使用最多的是pika。

目前在OpenStack中，各個元件都已過渡到使用Oslo_messaging進行RPC呼叫。

下面是兩張經典的介紹OpenStack中rpc.call和rcp.cast的示意圖：

OpenStack中的rpc.call

OpenStack中的rcp.cast

圖中出現的一些概念，這裡也給大家做一個簡短的說明：

Topic（主題）——傳送訊息的一個屬性，主題中引入了一個叫做Routing Key（路由鍵)的概念，訊息轉發器會根據訊息主題的路由鍵將訊息路由到對應的訊息佇列

Exchange（訊息轉發器）——訊息到達訊息中介軟體時的第一站，訊息轉發器根據話題來負責訊息的分配，本身RabbitMQ提供了三種典型的訊息分配模式，Direct Exchange，Fanout Exchange，Topic Exchange，他們與網路技術中的單播，廣播和組播很相似

Binding（繫結）——訊息轉發器與訊息佇列之間的連線

Oslo_messaging使用Kombu框架連線RabbitMQ。

Kombu是一個AMQP訊息佇列的架構，Python可以方便的使用它提供的介面收發訊息。它採用外掛式的結構來支援不同的訊息系統，對與AMQP，它支援py-amqplib和librabbitmq兩個client來連線message server。

根據作業系統中安裝的AMQP client的不同，有以下兩種呼叫關係： 

OpenStack -> oslo_messaging -> kombu -> amqp -> socket

OpenStack -> oslo_messaging -> kombu -> librabbitmq -> rabbitmq-c -> socket

如果安裝了librabbitmq，則Kombu會優先使用。因為它使用C語言編寫，效率更高一些，理想情況下訪問效率可以達到amqp的兩倍。

企業中的OpenStack環境通常需要部署多個RabbitMQ節點，在Nova等服務的配置檔案中，通常以rabbitmq_hosts定義RabbitMQ叢集的多個節點資訊。由於使用Puppet／Chef等工具部署的原因，多個RabbitMQ節點的順序在所有的配置檔案中是統一的。AMQP client一般以round-robin的方式去嘗試連線這些節點。

在oslo_messaging中，對rabbitmq_hosts中儲存的節點資訊進行隨機排序，OpenStack的各個元件服務訪問MQ時將以一個隨機排序過的順序進行，逐個嘗試連線。這樣帶來的好處就是不至於將叢集中所有的訪問請求都從第一個節點開始，加大第一個節點的負載。當正在連線的節點失效時，在oslo_messaging的配置中同樣可以對Kombu的策略kombu_failover_strategy進行控制，可以設定為shuffle或round-robin模式，通常用預設值round-robin來避免失效的節點再次被選中。因此，oslo_messaging中對RabbitMQ多節點排序一定程度上代替了HAProxy的Load Balance功能，讓叢集的各個節點的訪問負責能夠均勻分佈。