眾所周知，openstack的通信方式有兩種，一種是基于http協(xié)議的restful api方式，另一種則是rpc調(diào)用。兩種通信方式的應(yīng)用場(chǎng)景有所不同，在openstack中，前者主要用于各組件之間的通信（如nova與glance的通信），而后者則用于同一組件中各個(gè)不同模塊之間的通信（如nova組件中nova-compute與nova-scheduler的通信）。
nova中rpc調(diào)用非常多，用pycharm點(diǎn)點(diǎn)點(diǎn)跟函數(shù)的時(shí)候遇到rpc就會(huì)點(diǎn)不下去了，不解決直接就看不下去了那種多法
什么是 rpc
看不明白這個(gè)圖對(duì)于看nova代碼，其實(shí)不是很重要，直接忽略以后再看也可以，當(dāng)務(wù)之急是解決一下看openstack代碼遇到rpc就跟丟了的問題
rpc、消息隊(duì)列、restful
這三個(gè)其實(shí)不是一個(gè)層面的東西，本質(zhì)上不應(yīng)該放在一起比，但是因?yàn)槎加脕硗ㄐ牛容^容易混淆就還是解釋一下
- restful：主要用于各組件之間的通信（比如nova與glance的通信），或者說用于組件對(duì)外提供調(diào)用接口
- rpc：則用于同一組件中各個(gè)不同模塊之間的通信（比如nova組件中nova-compute與-nova-scheduler的通信）
- 消息隊(duì)列：用于解耦組件，也是組件間通信用的，而且會(huì)有一個(gè)隊(duì)列用來暫存消息
在nova中的典型rpc
nova/nova/nova/conductor/tasks/live_migrate.py
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
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的方式遠(yuǎn)程調(diào)用compute的live_migration,過程就是, conductor以rpc的方式發(fā)出一個(gè)請(qǐng)求到queue再被nova-compute接收
nova/nova/nova/compute/rpcapi.py
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
class computeapi(object): # 這是一個(gè)rpc遠(yuǎn)程調(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' # 獲取目標(biāo) compute 主機(jī)(dest host)的rpc client，即被調(diào)用的服務(wù)進(jìn)程的hostip cctxt = self.client.prepare(server=host, version=version) # 通過目標(biāo)主機(jī)對(duì)象的 rpc cliient 來調(diào)用遠(yuǎn)程過程方法 cast() ，以此來實(shí)現(xiàn)遠(yuǎn)程調(diào)用 cctxt.cast(ctxt, 'live_migration', instance=instance, dest=dest, block_migration=block_migration, migrate_data=migrate_data, **args) # cast()異步遠(yuǎn)程調(diào)用，不會(huì)阻塞別的進(jìn)程，適合于需要長時(shí)間進(jìn)行的執(zhí)行過程 # cast()的第二個(gè)參數(shù)是rpc client調(diào)用的函數(shù)名，case()后面的參數(shù)會(huì)繼續(xù)作為參數(shù)傳入該調(diào)用函數(shù) # cast()函數(shù)內(nèi)的live_migration()函數(shù)是 manager.live_migration() 視具體實(shí)現(xiàn)遷移功能的函數(shù)，在manager.py內(nèi)實(shí)現(xiàn)。 |
調(diào)用的時(shí)候是從nova/nova/conductor/tasks/live_migrate.py到nova/nova/compute/rpcapi.py，但是實(shí)際上是compute服務(wù)首先得在rpcapi.py提供出接口函數(shù)，然后使用者通過
- 1. import導(dǎo)入的方式去使用rpc調(diào)用
- 2. 類實(shí)例化傳參的方式去引入
熱遷移這里用的就是類實(shí)例化傳參
tip: call()表示同步調(diào)用 和 cast()表示異步調(diào)用
根據(jù)在rpc.py或者rpcapi.py中的cast()的第二個(gè)參數(shù),去該服務(wù)下的manager.py中找和這個(gè)參數(shù)同名的函數(shù)（這個(gè)就是rpc最終想要調(diào)用的函數(shù)），我們這里是compute_rpcapi，所以要去找compute下的mannager.py
為什么要去找mannager，是因?yàn)閚ova.compute.manager 會(huì)一直監(jiān)聽 queue ，當(dāng)queue中存在相關(guān)的 rpc 請(qǐng)求時(shí)，就去完成這個(gè)請(qǐng)求
nova/nova/nova/compute/manager.py
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
@wrap_exception() @wrap_instance_event(prefix='compute') @wrap_instance_fault def live_migration(self, context, dest, instance, block_migration, migration, migrate_data): """執(zhí)行實(shí)時(shí)遷移。 :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) |
當(dāng)然實(shí)際干活的還不是manager.py的def live_migration，而是live_migration函數(shù)去調(diào)用_do_live_migration，但是之后的就是熱遷移的流程，在之前的文檔里寫了就不展開了，反正rpc的體現(xiàn)就只到這里
冷遷移中還有很多例子，不一一列舉了，有興趣可以去看這篇博客
看完例子會(huì)發(fā)現(xiàn)，既然原生的代碼既然已經(jīng)寫了rpc調(diào)用，那么對(duì)應(yīng)的服務(wù)肯定已經(jīng)提供了rpc接口，所以實(shí)際上看到compute_rpcapi，可以不去compute下的rpc文件中找了，直接去compute下的manager看具體實(shí)現(xiàn)(不止compute，其他服務(wù)也一樣)，當(dāng)然，如果需要雪確定是同步還是異步調(diào)用那還是不要偷這一步的懶。
總結(jié)
完整的rpc應(yīng)該具有
-
組件a提供出rpc調(diào)用接口（
rpc.py或者rpcapi.py文件） -
組件b引入組件a的rpc (
import或者類實(shí)例化傳參) -
組件b調(diào)用組件a的rpc(以
rpc方式發(fā)送一個(gè)請(qǐng)求到消息隊(duì)列) -
組件a處理請(qǐng)求（組件a監(jiān)聽到發(fā)給自己的
rpc請(qǐng)求會(huì)通過manager處理請(qǐng)求）
如果只是看代碼，那么去對(duì)應(yīng)的manager下面找實(shí)現(xiàn)就可以了，但是如果自己要加就還是的明白從哪里提供的、怎樣導(dǎo)入，何種途徑接收,這樣想在代碼里添加自己的rpc調(diào)用才心里有數(shù)
參考文獻(xiàn)：
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遠(yuǎn)程調(diào)用的文章就介紹到這了,更多相關(guān)openstack rpc調(diào)用內(nèi)容請(qǐng)搜索服務(wù)器之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持服務(wù)器之家！
原文鏈接：https://blog.csdn.net/qq_33909098/article/details/118576253
