1. 程式人生 > >Ceilometer 21、openstack元件之間通訊以及元件內服務通訊方式分析

Ceilometer 21、openstack元件之間通訊以及元件內服務通訊方式分析

1 openstack元件之間通訊以及元件內各服務通訊方式


1.1 openstack各元件之間的通訊方式


據我所瞭解的幾個元件,各個元件之間大部分是通過呼叫其他元件的rest api方式進行通訊,
而rest api的框架大部分是通過: wsgi + pecan 的形式搭建起來的,本質上是http的形式,
呼叫各個rest api的本質是封裝為一個http的url請求,從這一點上說,基於rest api的各元件
之間的通訊方式是http。
這種方式的特點是,呼叫rest api可以獲取到該api的返回結果(當然也有rest api不需要返回結果的,例如:
刪除某個資源)
當然也有例外,ceilometer和其他元件之間的基於事件建立型的通訊方式是走訊息佇列(例如nova建立虛機,
cinder建立雲硬碟都是傳送訊息到訊息佇列,ceilometer監聽到訊息佇列來獲取這些訊息)。
這種通訊方式的特點是:
訊息的傳送方並不需要受到訊息的接受方執行結果的返回值。

總結:
1) openstack各元件之間大部分的通訊方式是基於rest api,本質是通過http進行通訊。
2) 也有其他元件之間的通訊方式是訊息佇列。

2 同一組件中各個服務之間的通訊方式


大部分的元件,為了實現各個服務之間的解耦,採取了訊息佇列實現服務進行解耦
例如ceilometer-compute服務和ceilometer-notification服務也是通過訊息佇列(後端對應rabbitmq)的形式實現,
例如aodh-evaluator服務和aodh-notifier服務也是通過訊息佇列(後端對應rabbitmq)的形式實現。
當然,除此之外,也有另外一個訊息佇列的一個變種形式。
這種形式就是rpc(遠端過程呼叫)。
當某個元件的某個服務通過rabbitmq的rpc的call方法執行另一個服務的某個方法並獲取執行的結果。

總結:
1) openstacj各元件內部服務的通訊方式大部分都是基於訊息佇列(後端對應rabbitmq實現)。
2) 這種訊息佇列又分為兩種使用方式:
2.1) 元件的一個服務不需要知道另一個服務的執行結果,只是單向的傳送資訊,這種使用的rabbitmq單純傳送訊息的功能
2.2) 元件的一個服務需要獲取另一個服務的執行結果,是雙向的過程,這種使用的是rabbitmq的rpc的call方法可以獲取另一個服務執行方法後的返回結果