openstack 의 rpc 원 격 호출 방법

알다 시 피 OpenStack 의 통신 방식 은 두 가지 가 있 는데 하 나 는 HTTP 프로 토 콜 을 기반 으로 하 는 RESTFul API 방식 이 고 다른 하 나 는 RPC 호출 이다.두 가지 통신 방식 의 응용 장면 이 다르다.OpenStack 에서 전 자 는 주로 각 구성 요소 간 의 통신(예 를 들 어 nova 와 glance 의 통신)에 사용 되 고 후 자 는 같은 구성 요소 에서 각 모듈 간 의 통신(예 를 들 어 nova 구성 요소 에서 nova-compute 와 nova-scheduler 의 통신)에 사용 된다.
nova 에서 rpc 호출 이 매우 많 습 니 다.pycharm 점 과 함 수 를 사용 할 때 rpc 를 만나면 눌 러 지지 않 습 니 다.해결 하지 않 으 면 바로 볼 수 없습니다.
RPC 가 뭐야?

이 그림 을 잘 못 보 는 것 은 nova 코드 를 보 는 데 중요 하지 않 습 니 다.그냥 무시 한 다음 에 보 셔 도 됩 니 다.가장 시 급 한 것 은 openstack 코드 가 rpc 에 부 딪 히 면 놓 치 는 문 제 를 해결 하 는 것 입 니 다.
RPC,메시지 큐,RESTful
이 세 가 지 는 사실 한 차원 의 물건 이 아니 므 로 본질 적 으로 함께 비교 해 서 는 안 된다.그러나 모두 통신 에 사용 되 기 때문에 헷 갈 리 기 쉬 우 니 설명 하 는 것 이 좋 겠 다.

RESTful:각 구성 요소 간 의 통신(예 를 들 어 nova 와 glance 의 통신)또는 구성 요소 가 대외 적 으로 호출 인 터 페 이 스 를 제공 하 는 데 사용 되 는

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?

        #   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 방식 으로 compute 의 live_migration 을 원 격 으로 호출 하 는 과정 에서 conductor 은 RPC 방식 으로 Queue 에 요청 을 한 다음 에 nova-compute 에 접수 되 었 다.
nova/nova/nova/compute/rpcapi.py

class ComputeAPI(object):

    #     RPC       
    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，          HostIP
        cctxt = self.client.prepare(server=host, version=version)

        #           RPC cliient           cast() ，         
        cctxt.cast(ctxt, 'live_migration', instance=instance,
                   dest=dest, block_migration=block_migration,
                   migrate_data=migrate_data, **args)
        # cast()      ，        ，               
        # cast()       RPC client      ，case()                   
        # cast()    live_migration()    manager.live_migration()             ， manager.py   。

호출 할 때 는 nova/nova/conductor/tasks/live_migrate.py 에서 nova/nova/compute/rpcapi.py 까지 이지 만 실제 compute 서 비 스 는 먼저 rpcapi.py 에서 인터페이스 함 수 를 제공 한 다음 에 사용자 가 통과 해 야 한다.
-1.import 가 져 오 는 방식 으로 rpc 호출 사용
-2.사례 화 된 전 삼 방식 으로 도입
열 이동 은 이곳 에서 사용 하 는 것 이 바로 예화 전 삼 이다.
tip:call()은 동기 호출 과 cast()는 비동기 호출 을 표시 합 니 다.
rpc.py 또는 rpcapi.py 중의 cast() 의 두 번 째 매개 변수 에 따라 이 서비스 에서 manager.py 에서 이 매개 변수 와 같은 이름 의 함수(이것 이 바로 rpc 이 최종 적 으로 호출 하고 자 하 는 함수)를 찾 아야 합 니 다.여 기 는 compute_rpcapi 이 므 로 compute 의 mannager.py 을 찾 아야 합 니 다.
mannager 를 찾 는 이 유 는 nova.compute.manager 가 Queue 를 계속 감청 하기 때 문 입 니 다.Queue 에 관련 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):
        """      。

        :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:
                #   _do_live_migration    
                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 함수 로 _do_live_migration 을 호출 하 는 것 입 니 다.그러나 그 다음은 열 이동 의 절차 입 니 다.앞의 문서 에 쓰 면 전개 되 지 않 습 니 다.어차피 rpc 의 표현 은 여기까지 입 니 다.
콜 드 이전 에는 많은 예 가 있 습 니 다.일일이 열거 하지 않 고 관심 이 있 으 면 냉 이동 소스 코드 분석 이라는 블 로 그 를 보 러 갈 수 있 습 니 다.
예 를 들 어 원생 의 코드 가 rpc 호출 을 썼 으 니 해당 하 는 서 비 스 는 rpc 인 터 페 이 스 를 제 공 했 을 것 입 니 다.그래서 실제 적 으로 compute_rpcapi 을 보 았 습 니 다.compute 의 rpc 파일 에서 찾 지 않 고 compute 의 manager 에 가서 구체 적 인 실현(compute 뿐만 아니 라 다른 서비스 도 마찬가지 입 니 다)을 볼 수 있 습 니 다.물론 입 니 다.눈 이 필요 하 다 면 동기 화 인지 비동기 호출 인지 확인 하 세 요.
총결산
완전한 rpc 가 있어 야 합 니 다.

구성 요소 A 는 rpc 호출 인터페이스(rpc.py 또는 rpcapi.py 파일)

을 제공 합 니 다.

구성 요소 B 가 구성 요소 A 를 도입 한 rpc(import 또는 )

구성 요소 B 호출 구성 요소 A 의 rpc(rpc 방식 으로 메시지 대기 열 에 요청 을 보 냅 니 다)

구성 요소 A 처리 요청(구성 요소 A 감 이 자신 에 게 보 낸 rpc 요청 을 들 으 면 manager 처리 요청 을 통과 합 니 다)

코드 만 본다 면 해당 하 는 manager 아래 에서 실현 을 찾 으 면 됩 니 다.그러나 자신 이 추가 하려 면 어디서 제공 하 는 지,어떻게 가 져 오 는 지,어떤 경 로 를 받 아들 이 는 지 알 아야 합 니 다.이렇게 코드 에 자신의 rpc 호출 을 추가 하려 면 자신 이 알 아야 합 니 다.
참고 문헌:
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
openstack 의 rpc 원 격 호출 에 관 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 openstack rpc 호출 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!