一、概述：
在openstack項目中，api的調用規則：
跨項目：如nova調用keystone， glance，cinder等，使用rest api（通過相應的python-XXXclient 庫）
項目內跨服務調用，使用RPC調用，通過服務提供的rpcapi.py文件，比如cinder內部，cinder-api與cinder-volume，cinder-scheduler服務之間使用RPC接口，即RabbitMQ消息；
cinder系統結構圖：
cinder-api是cinder 服務的endpoint， 提供了rest接口，負責處理client的請求，並將rest請求解封，並重新封裝成RPC請求至cinder-scheduler組件；
除dashboard之外，所有的服務均有XXX-api作為XXX服務的endpoint，提供rest 接口，負責處理XXXclient 的請求：
1 [root@TS-M2-Cloud172 ~(keystone_admin)]# openstack-service list |grep api 2 openstack-ceilometer-api 3 openstack-cinder-api 4 openstack-glance-api 5 openstack-nova-api
二、openstack RPC通信
openstack組件內部的RPC（Remote Producer Call）機制的實現是基於AMQP協議作為通訊模型，從而組件內部的松耦合性。AMQP是用於異步消息通訊的消息中間件協議;AMQP模型有四個重要的角色：
- Exchange： 根據Routing key轉發消息到對應的Message Queue中；
- Routing key: 用於Exchange判斷那些消息需要發送對應的Message Queue
- Publisher： 消息發送者，將消息發送的Exchange並指明Routing Key，以便Message Queue可以正確的收到消息；
- Consumer：消息接受者，從Message Queue獲取消息；
消息發布者 Publisher 將 Message 發送給 Exchange 並且說明 Routing Key。Exchange 負責根據 Message 的 Routing Key 進行路由，將 Message 正確地轉發給相應的 Message Queue。監聽在 Message Queue 上的 Consumer 將會從 Queue 中讀取消息。
Routing Key 是 Exchange 轉發信息的依據，因此每個消息都有一個 Routing Key 表明可以接受消息的目的地址，而每個 Message Queue 都可以通過將自己想要接收的 Routing Key 告訴 Exchange 進行 binding，這樣 Exchange 就可以將消息正確地轉發給相應的 Message Queue。
OpenStack層封裝call和cast接口用於遠程調用RPC的server上的方法，這些方法都是構造RPC的server的endpoints內的方法。遠程調用時，需要提供一個字典對象來指明調用的上下文，調用方法的名字和傳遞給調用方法的參數(用字典表示)。如：
cctxt =self.client.prepare(vesion=’2.0’)
cctxt.cast(context,‘build_instances’, **kw)
通過cast方式的遠程調用，請求發送后就直接返回了；通過call方式遠程調用，需要等響應從服務器返回。