opestack遵循這樣的設計原則：

• 專案之間通過RESTful進行通行
• 專案內部，不同服務程序之間的通訊，則必須要通過訊息匯流排

這樣的設計保證了專案對外提供服務的介面可以被不同型別的客戶端高效支援，同時也保證了內部通訊介面的可擴充套件性和可靠性。openstack olso.messaging庫實現了以下兩種發方式來完成專案內部各服務程序之間的通訊：
1. 遠端排程RPC:
通過遠端排程，一個服務程序可以呼叫其他遠端服務程序的方法，兩種排程方式：call和cast。其中call方法會被同步執行，呼叫者會被阻塞直到結果返回。cast方式，會被非同步執行，並不會立刻返回，呼叫者也也不會被阻塞，呼叫者需要用其他方式查詢這次遠端呼叫的結果。
2. 事件通知：
服務程序將時間通知傳送到訊息總線上，總線上所有堆此類事件感興趣的服務程序都可以對此進行進一步的處理，但是處理結果並不會直接回給事件的傳送者。

 ## AMQP ##

 openstack所支援的高階訊息佇列中大多是基於AMQP。傳遞訊息的中介軟體（server/broker），訊息的生產者將訊息傳送server，他會根據不同的條件將訊息傳遞個不同的消費者。
上述操作由Exchange和queue來實現。其中Exchange不會儲存訊息，會根據不同的條件將訊息傳送個不同的Queue。所謂的條件就是Binding，每一個傳送的訊息會有一個routingkey，同樣每一個Queue也會有一個bindingkey，當兩者相匹配就會發送到改訊息佇列（Queue）。

• Direct bindingkey與routingkey相匹配
• Topic 可以通過萬用字元“*”來進行迷糊匹配
• Fanout 將訊息傳遞到所有繫結的佇列上

## 基於AMQP實現RPC##

• 客戶端傳送一個請求訊息個Exchange，指定routing key位”op_queue“，同時指明一個訊息佇列名來獲取響應”res_queue“
• Exchange將訊息傳送給 op_queue
• op_queue把訊息推送給服務端，服務端執行RPC呼叫相應的服務，結束後將結果發給訊息佇列，指明routing為”res_queue“
• Exchange將訊息轉發給res_queue
• 客戶端從訊息佇列res_queue中獲取響應