眾所周知,OpenStack的通信方式有兩種,一種是基于HTTP協(xié)議的RESTFul API方式,另一種則是RPC調(diào)用。兩種通信方式的應用場景有所不同,在OpenStack中,前者主要用于各組件之間的通信(如nova與glance的通信),而后者則用于同一組件中各個不同模塊之間的通信(如nova組件中nova-compute與nova-scheduler的通信)。
nova中rpc調(diào)用非常多,用pycharm點點點跟函數(shù)的時候遇到rpc就會點不下去了,不解決直接就看不下去了那種多法
什么是 RPC
看不明白這個圖對于看nova代碼,其實不是很重要,直接忽略以后再看也可以,當務之急是解決一下看openstack代碼遇到rpc就跟丟了的問題
RPC、消息隊列、RESTful
這三個其實不是一個層面的東西,本質(zhì)上不應該放在一起比,但是因為都用來通信,比較容易混淆就還是解釋一下
- RESTful:主要用于各組件之間的通信(比如nova與glance的通信),或者說用于組件對外提供調(diào)用接口
- RPC:則用于同一組件中各個不同模塊之間的通信(比如nova組件中nova-compute與-nova-scheduler的通信)
- 消息隊列:用于解耦組件,也是組件間通信用的,而且會有一個隊列用來暫存消息
在nova中的典型rpc
nova/nova/nova/conductor/tasks/live_migrate.py
class LiveMigrationTask(base.TaskBase):
def __init__(self, context, instance, destination,
block_migration, disk_over_commit, migration, compute_rpcapi,
servicegroup_api, scheduler_client):
super(LiveMigrationTask, self).__init__(context, instance)
...
def _execute(self):
self._check_instance_is_active()
self._check_host_is_up(self.source)
if not self.destination:
self.destination = self._find_destination()
self.migration.dest_compute = self.destination
self.migration.save()
else:
self._check_requested_destination()
# TODO(johngarbutt) need to move complexity out of compute manager
# TODO(johngarbutt) disk_over_commit?
#調(diào)用 ComputeAPI 類中的 live_migration() RPC接口
return self.compute_rpcapi.live_migration(self.context,
host=self.source,
instance=self.instance,
dest=self.destination,
block_migration=self.block_migration,
migration=self.migration,
migrate_data=self.migrate_data)
conductor
以compute_rpcapi.live_migration
的方式遠程調(diào)用compute
的live_migration
,過程就是, conductor
以RPC
的方式發(fā)出一個請求到Queue
再被nova-compute
接收
nova/nova/nova/compute/rpcapi.py
class ComputeAPI(object):
# 這是一個RPC遠程調(diào)用的方法
def live_migration(self, ctxt, instance, dest, block_migration, host,
migration, migrate_data=None):
args = {'migration': migration}
version = '4.2'
if not self.client.can_send_version(version):
version = '4.0'
# 獲取目標 compute 主機(DEST HOST)的RPC client,即被調(diào)用的服務進程的HostIP
cctxt = self.client.prepare(server=host, version=version)
# 通過目標主機對象的 RPC cliient 來調(diào)用遠程過程方法 cast() ,以此來實現(xiàn)遠程調(diào)用
cctxt.cast(ctxt, 'live_migration', instance=instance,
dest=dest, block_migration=block_migration,
migrate_data=migrate_data, **args)
# cast()異步遠程調(diào)用,不會阻塞別的進程,適合于需要長時間進行的執(zhí)行過程
# cast()的第二個參數(shù)是RPC client調(diào)用的函數(shù)名,case()后面的參數(shù)會繼續(xù)作為參數(shù)傳入該調(diào)用函數(shù)
# cast()函數(shù)內(nèi)的live_migration()函數(shù)是 manager.live_migration() 視具體實現(xiàn)遷移功能的函數(shù),在manager.py內(nèi)實現(xiàn)。
調(diào)用的時候是從nova/nova/conductor/tasks/live_migrate.py
到nova/nova/compute/rpcapi.py
,但是實際上是compute
服務首先得在rpcapi.py
提供出接口函數(shù),然后使用者通過
- 1. import導入的方式去使用rpc調(diào)用
- 2. 類實例化傳參的方式去引入
熱遷移這里用的就是類實例化傳參
tip: call()表示同步調(diào)用 和 cast()表示異步調(diào)用
根據(jù)在rpc.py
或者rpcapi.py
中的cast()
的第二個參數(shù),去該服務下的manager.py
中找和這個參數(shù)同名的函數(shù)(這個就是rpc
最終想要調(diào)用的函數(shù)),我們這里是compute_rpcapi
,所以要去找compute
下的mannager.py
為什么要去找mannager,是因為nova.compute.manager 會一直監(jiān)聽 Queue ,當Queue中存在相關(guān)的 RPC 請求時,就去完成這個請求
nova/nova/nova/compute/manager.py
@wrap_exception()
@wrap_instance_event(prefix='compute')
@wrap_instance_fault
def live_migration(self, context, dest, instance, block_migration,
migration, migrate_data):
"""執(zhí)行實時遷移。
:param context: security context
:param dest: destination host
:param instance: a nova.objects.instance.Instance object
:param block_migration: if true, prepare for block migration
:param migration: an nova.objects.Migration object
:param migrate_data: implementation specific params
"""
self._set_migration_status(migration, 'queued')
def dispatch_live_migration(*args, **kwargs):
with self._live_migration_semaphore:
# 調(diào)用_do_live_migration執(zhí)行遷移
self._do_live_migration(*args, **kwargs)
# NOTE(danms): We spawn here to return the RPC worker thread back to
# the pool. Since what follows could take a really long time, we don't
# want to tie up RPC workers.
utils.spawn_n(dispatch_live_migration,
context, dest, instance,
block_migration, migration,
migrate_data)
當然實際干活的還不是manager.py
的def live_migration
,而是live_migration
函數(shù)去調(diào)用_do_live_migration
,但是之后的就是熱遷移的流程,在之前的文檔里寫了就不展開了,反正rpc的體現(xiàn)就只到這里
冷遷移中還有很多例子,不一一列舉了,有興趣可以去看冷遷移源碼分析這篇博客
看完例子會發(fā)現(xiàn),既然原生的代碼既然已經(jīng)寫了rpc調(diào)用,那么對應的服務肯定已經(jīng)提供了rpc接口,所以實際上看到compute_rpcapi
,可以不去compute
下的rpc
文件中找了,直接去compute
下的manager
看具體實現(xiàn)(不止compute
,其他服務也一樣),當然,如果需要雪確定是同步還是異步調(diào)用那還是不要偷這一步的懶。
總結(jié)
完整的rpc應該具有
- 組件A提供出rpc調(diào)用接口(
rpc.py
或者rpcapi.py
文件)
- 組件B引入組件A的rpc (
import
或者類實例化傳參
)
- 組件B調(diào)用組件A的rpc(以
rpc
方式發(fā)送一個請求到消息隊列)
- 組件A處理請求(組件A監(jiān)聽到發(fā)給自己的
rpc
請求會通過manager
處理請求)
如果只是看代碼,那么去對應的manager
下面找實現(xiàn)就可以了,但是如果自己要加就還是的明白從哪里提供的、怎樣導入,何種途徑接收,這樣想在代碼里添加自己的rpc調(diào)用才心里有數(shù)
參考文獻:
https://zhuanlan.zhihu.com/p/36427583
https://blog.csdn.net/Jmilk/article/details/52655645
https://www.cnblogs.com/wongbingming/p/11086773.html
https://blog.csdn.net/qq_33909098/article/details/118578133
到此這篇關(guān)于openstack中的rpc遠程調(diào)用的文章就介紹到這了,更多相關(guān)openstack rpc調(diào)用內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
您可能感興趣的文章:- python遠程調(diào)用rpc模塊xmlrpclib的方法
- 對python調(diào)用RPC接口的實例詳解
- Python中實現(xiàn)遠程調(diào)用(RPC、RMI)簡單例子