我們都知道openstack中有至少兩種通訊機制，一種是RESTful API，另一種是RPC呼叫，舉個例子，當nova與glance通訊的時候可能用的是RESTful API，而nova-api與nova-scheduler進行通訊的時候，卻是使用rabbitmq中的訊息佇列。為什麼呢？另外在一個架構設計中應該選擇哪一種通訊機制。需要我們對這兩種機制有一定的瞭解。

分類

• RESTFUL API
• RPC

RESTful API

• RESTFUL API是一套架構約束條件和原則
  
  • REST定義的原則
    
    • 所有事物都定義了ID。openstack中每個資源都有唯一的UUID
    • 所有事物都連結在一起。在openstack中將資源的ID放在URL中。
    • 使用標準的方法。比如說GET是查詢資源，POST是新增資源，PUT是更新資源等等。
  • 使用RESTful API架構，實現的目標
    
    • 客戶端與服務端的獨立性: 在公共介面不變的情況下，客戶端和服務端的程式碼可以獨立開發。
    • 無狀態性: 使用者的狀態儲存在客戶端，服務端不再儲存使用者的狀態。客戶端向服務端傳送請求時，必須傳送所有的資料，包括使用者狀態。
    • 統一的介面: RESTful API的URL格式需要遵守統一的規範。可以降低客戶端伺服器的耦合度，使得編碼更加簡單。
  • 利用PasteDeploy定製WSGI服務(openstack中所有web服務都是通過WSGI部署的，例如httpserver.serve(…))
    api-paste.ini
    檔案——app(應用程式)、filter(過濾器)、pipeline(管道)、composite(複合體)
    
    wsgi_paste.py檔案
    
    
    帶過濾器的WSGI服務
  • 特點
    基於HTTP協議
    使用PasteDeploy配置WSGI服務
    mapper類來實現URL對映的管理
  • 缺點
    訊息僅限於文字
    客戶端與服務端採取同步機制，當傳送http請求時客戶端需要等待伺服器的響應
    客戶端與伺服器雖然可以獨立開發，但也存在耦合。客戶端必須要知道伺服器的地址才可以正常工作。
  • 其他
    REST是面向資源的，資源通過URL暴露
    REST本身可以利用HTTP的一些特徵，如HTTP動詞、狀態碼、HTTP報頭等

RPC

• RPC協議，即遠端過程呼叫（Remote Procedure Call Protocol）
  RPC採用AMQP協議實現程序間通訊。openstack中採用rabbitmq和qpid。
  
  • AMQP:高階訊息佇列，基於訊息的中介軟體提供的開放的應用層標準協議。能夠有效地支援各種通訊模型或者報文傳送方面的應用。
  • 特點：二進位制的應用層通訊協議，進城之間對稱的非同步通訊協議，訊息格式，一系列標準化的但可拓展的訊息能力(訂閱者和釋出者，兩個節點無需知道對方是什麼節點，也不用管對方節點怎麼去處理髮送的訊息，擁有過濾器可以修改訂閱者的接收內容)
  • 組成：釋出者，中介軟體(訊息的儲存、交換和路由)，訂閱者
  • 流程：釋出者將訊息傳送到中介軟體，中介軟體將訊息儲存到訊息佇列中，最後訂閱者從訊息佇列中獲取訊息。
  • nova中使用rabbitmq實現RPC呼叫
    客戶端(釋出者)無需知道伺服器(訂閱者)的位置
    客戶端與伺服器無需同步執行。客戶端可以先發RPC呼叫，然後儲存在訊息佇列中。
    遠端呼叫的隨機均衡性，當客戶端發起RPC呼叫時，可以隨機選擇一個伺服器來處理訊息。
    
    兩種交換方式：直接交換方式(direct exchange，主要用於伺服器端返回rpc.call呼叫的結果，訂閱者直接點名要哪臺伺服器進行響應)和主題交換方式(topic exchange,主要用於客戶端發起遠端呼叫rpc.call和rpc.cast，釋出者不指定響應的伺服器，可實現負載均衡)

區別

只需要記住一點：RPC是以動詞為中心的， REST是以名詞為中心的，此處的動詞指的是一些方法，名詞是指資源。

• 以動詞為中心，意味著，當你要需要加入新功能時，你必須要新增更多的動詞，這時候伺服器端需要實現相應的動詞（方法），客戶端需要知道這個新的動詞並進行呼叫。
• 而以名詞為中心， 假使我請求的是 hostname/friends/， 無論這個URI對應的服務怎麼變化，客戶端是無需關注和更新的，而這種變化對客戶端也是透明的。