OpenStack設計與實現4——消息總線（AMQP）

OpenStack設計與實現4——消息總線（AMQP）

Tips：文章爲拜讀@xingjiarong 後有感而作的分享，先對做者表示感謝，附原文地址：http://blog.csdn.net/xingjiarong

0. 引言

• 在西方有一句諺語，叫作「Don’t Reinvent the Wheel！」。直譯過來就是不要在從新發明輪子了。也就是說咱們應該避免作一些重複性的工做，若是一個東西別人已經作過了，那麼咱們拿來直接用就好了，沒有必要從新制做，這一點在軟件開發裏尤其突出。因此在OpenStack的開發中也借鑑了這一思想，OpenStack利用了大量的現有庫，這加快了OpenStack的開發，使得開發人員能夠集中精力研究難點。下面咱們就來一塊兒討論一下OpenStack的通用技術。

1. 消息總線

• OpenStack的設計原則：

  1. 項目之間經過RESTful API進行通訊；

  2. 項目內部經過，不一樣服務進程之間經過消息總線進行通信。

• 這種設計思想保證了各個項目對外能夠被不一樣類型的客戶端接受，同時也保證了內部項目通訊接口的可擴展性和可靠性，以支持大規模的部署。

• 軟件的開發經歷了三個階段，從最初的面向過程到面向對象，而後再到面向服務。在面向服務的軟件開發中，咱們須要考慮的就是如何保持各個服務之間的通訊。這裏OpenStack借鑑了計算機硬件總線的思想，引入了消息總線。一些服務向總線上發送消息，另外一些服務從總線上獲取獲取消息。

• OpenStack利用開源庫實現瞭如下兩種類型的用於在內部服務進行之間的通信：

  1. 事件通知
     某個服務進程能夠把事件通知發送到消息總線上，該消息總線上全部對此類事件感興趣的服務進程，均可以得到此事件通知並進行進一步的處理，可是處理的結果不會返回給事件發送者。

  2. 遠程過程調用（RPC）
     經過遠程調用，一個服務進程能夠調用其餘遠程服務進程的方法，而且有阻塞和非阻塞兩種方式。

• OpenStack已經支持了一些常見的消息總線，以下表。

名稱	特色
RabbitMQ	實現了AMQP的消息中間件服務，支持多種協議網關和編程語言
Qpid	Apache基金會下的頂層項目，實現了AMQP協議
ZeroMQ	開源的高性能異步消息庫，能夠在沒有Server/Broker的狀況下工做

2. AMQP的實現原理

• OpenStack所支持的消息總線類型中（上表），大部分是基於AMQP（Advanced Message Queuing Protocol）的，AMQP是一個異步消息傳遞所使用的開放的應用層協議規範，主要包括了消息的導向、隊列、路由、可靠性和安全性。下面咱們來詳細的學習一下AMQP的原理。
  

• 如上圖所示，AMQP的主要參與者有如下幾個：

  1. Producer：消息的產生者

  2. Comsumer：消息的接收者

  3. Exchange：交換部件，根據消息的條件選擇不一樣的消息接收者。

  4. Queue：消息隊列，暫時緩存到達消費者的消息

  5. 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會把消息緩存在內存或磁盤上。

3. 基於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中獲取響應。