Openstack 中的消息總線 & AMQP

目錄

消息總線

Openstack 采用了面向服務的開發模式(有别于面向對象和面向過程)，需要我們去考慮各個服務之間和各項目之間是如何傳遞消息的。

Restful API：項目之間的通信。

消息總線：項目内部的服務之間的通信。

使用這種架構模式的好處在于：保證了各個項目對外提供服務的 API 接口可以被不同的用戶端類型所調用。即，隻要可以調用這個 API 接口，那麼 Client 是使用什麼技術來實作，Service 都不會受到影響，也不需要作出改變。Server 和 Client 做到了子產品化的分離。除此之外，還能夠保證項目内部通信接口的可擴充性和可靠性，可以支援大規模的部署。

消息總線：可以實作一些服務向總線發送資訊，其他的服務從總線上擷取消息的效果。就類似于回轉壽司的回轉帶，所有人都可以往回轉帶上放壽司和取壽司，這樣的話隻需要有足夠的位置，就能夠随時加入或減少客人，而且并不會影響整個壽司店的運作。

消息總線的原理

項目内部各服務程序之間的通信使用了：oslo.messaging庫所提供的函數方法。同時還需要以下兩種技術作為支撐。

遠端過程調用 RPC：一個服務程序可以調用其他遠端服務程序的方法。調用的方式：

call()：遠端方法會被同步執行，調用者會被阻塞直到傳回方法的結果，在一些調用時間較長的場合中使用會對效率又很大的影響。( call() 調用的遠端服務的方法會被馬上執行，在執行的過程中還會把調用者的程序阻塞掉，知道傳回結果為止。)

cast()：遠端服務的方法會被異步執行，調用者不會被阻塞，結果也無須立即傳回，可以在一個合适的時機(人為幹預)去執行并傳回結果。是以也要求調用者利用其他的方法來查詢這次遠端調用的結果。

事件通知：某一個服務程序将事件通知發送到消息總線上，所有在消息總線上且對該事件通知感興趣的服務程序都可以将該事件通知擷取并進行處理，執行的結果并不需要傳回給事件發送者。這種方式不僅可以在項目元件内部的程序服務通信間實作，還可以在項目之間的通信中實作(EG. Ceilometer)。

AMQP

AMQP進階消息隊列協定：是一個基于應用層的，用于異步消息傳遞的協定規範。其功能包括了： 消息的導向/ 消息的隊列/ 消息的路由/ 消息的可靠性/ 消息的安全性。不同的AMQP實作方式之間可以通過定義消息在網絡上傳輸時的位元組流格式來進行互相操作。

在一個實作了 AMQP協定 的中間件消息隊列服務中，如：RabbitMQ。當由生産者發出的不同的消息被發送到 RabbitMQ Server 中的 Queue 時，RabbitMQ 會根據不同的條件把 Queue 中的請發傳遞給不同的消費者。如果消費者無法接收，那麼這個消息，就會自動的把消息緩存在記憶體或者磁盤中。這些操作是由 RebbitMQ 中的 Exchange 和 Queue 來實作的( Exchange或Queue的數量不定 )：

Excange(資訊交換)：決定了消息的路由轉發，根據接收到的消息中的 Info (從消息屬性/消息頭/消息體中提取)來與綁定表比對(消息的 routing key 和 Queue 的 binding key 比對)以此來決定将消息轉發到哪一個 Queue 中，然後消費者再從 Queue 中擷取消息并進行處理。

Queue(消息隊列)：作為 消息存儲 和 分發 實體，負責将消息緩存在記憶體或者磁盤中，并且按照一定的順序将這些消息分發給一個或多個消費者。

注：Excange 負責将消息轉發到 Queue 中，轉發的判斷依據是從消息中擷取的routing key 與 Queue 中的 binding key 比對結果。