0에서 1까지: RPC 원격 호출에 대한 포괄적인 이해

작성자 | Python 프로그래밍 시간

편집자 Hu Weiwei

RPC란? 바이두 백과사전에서 제공하는 설명은 다음과 같습니다. "RPC(Remote Procedure Call Protocol) - 원격 프로시저 호출 프로토콜. 기본 네트워크 기술을 알지 못한 채 네트워크를 통해 원격 컴퓨터 프로그램에 서비스를 요청하는 프로토콜입니다."

이 개념은 아직까지는 상대적으로 추상적으로 들리지만, 계속 읽으시면 RPC의 기본 내용을 완전히 이해할 수 있도록 나중에 개념적인 내용을 명확하게 설명하겠습니다.

OpenStack에는 두 가지 주요 프로세스 간 통신 방법이 있는데, 하나는 HTTP 프로토콜 기반의 RESTFul API 방법이고, 다른 하나는 RPC 호출입니다.

그렇다면 애플리케이션 시나리오에서 이 두 가지 방법의 차이점은 무엇입니까?

경험이 있는 사람들은 다음을 알 것입니다.

먼저 두 가지 질문을 하고 다음 두 가지 질문을 계속 읽어 보겠습니다.

1. 무엇을 RPC와 REST의 차이점은 무엇입니까? 2. RPC를 사용하는 이유는 무엇입니까?

우선 첫 번째 질문: RPC와 REST의 차이점은 무엇입니까?

물론 저를 포함해서 이 질문이 이상하다고 생각하실 수도 있겠지만, 인터넷에 검색해 보면 비슷한 비교글이 많이 나와 있어서 초보자분들은 이해하지 못하는 분들이 많을 거라 생각합니다. 이 질문은 기본 지식이 부족하기 때문에 관련되지 않은 두 가지를 비교할 수 있습니다. 그렇기 때문에 생소한 RPC에 대한 이해를 돕기 위해 여러분에게 매우 익숙한 REST부터 시작해 보겠습니다.

01. 다양한 카테고리

REST는 Representational State Transfer의 약자로 중국어는 Representational State Transfer(리소스 데이터를 포함하여 특정 순간 상태의 리소스 데이터의 스냅샷을 말합니다.) , 프리젠테이션 형식(XML, JSON) 및 기타 정보)

REST는 소프트웨어 아키텍처 스타일입니다. 이 스타일의 일반적인 응용 프로그램은 HTTP입니다. 단순성과 강력한 확장성으로 인해 개발자들이 널리 선호합니다.

RPC는 Remote Procedure Call Protocol의 약자로 클라이언트가 서버의 서비스(메소드)를 로컬 서비스(메소드)처럼 호출할 수 있도록 하는 원격 프로시저 호출(Remote Procedure Call)입니다.

RPC는 TCP/UDP나 HTTP 프로토콜을 기반으로 전송할 수 있습니다. 논리적으로 말하면 REST와 동일한 수준이 아니며 함께 논의할 수도 없습니다. 그런데 REST를 그렇게 유명하게 만든 것은 무엇일까요? 현재 인터넷 애플리케이션을 위한 가장 인기 있는 API 설계 표준 세트입니다. 어떤 의미에서 REST는 실제로 HTTP 프로토콜을 의미합니다.

02. 다양한 사용 방법

03. 다양한 객체 방향

설계 관점에서 보면 원격 프로시저 호출이라고 불리는 RPC는 방법입니다. -지향, REST : 소위 표현 상태 전송은 리소스 지향입니다. 또한 메시지 지향인 소위 서비스 지향 아키텍처인 SOA도 있습니다. 그래서 자세한 내용은 다루지 않겠습니다.

04. 다양한 직렬화 프로토콜

인터페이스 호출에는 일반적으로 직렬화와 통신 프로토콜의 두 부분이 포함됩니다.

통신 프로토콜은 위에서 언급한 것처럼 REST는 HTTP 프로토콜을 기반으로 하며, RPC는 TCP/UDP 또는 HTTP 프로토콜을 기반으로 전송할 수 있습니다.

일반적인 직렬화 프로토콜에는 json, xml, hession, protobuf, thrift, text, bytes 등이 포함됩니다. REST는 일반적으로 JSON 또는 XML을 사용하는 반면 RPC는 JSON-RPC 또는 XML -RPC를 사용합니다.

위의 내용을 통해 우리는 REST와 RPC 사이에 분명한 차이점이 있다는 것을 알고 있습니다.

그러면 두 번째 질문: RPC를 사용하는 이유는 무엇입니까?

그렇다면 왜 RPC를 사용해야 할까요? 그냥 RESTful API에만 의존하면 되는 것 아닌가요? 왜 우리는 그렇게 복잡한 합의를 해야 합니까? Zhazha는 정말로 그것을 배울 수 없다고 말했습니다.

이 점에 대해 다음 사항은 제 개인적인 추측일 뿐이며 소통을 위한 것입니다.

너무 많이 말씀드렸는데 둘 중 무엇을 선택해야 할까요? 참조를 위해 다음 두 가지 사항을 요약했습니다.

"원격 호출"은 호출된 메소드의 특정 구현이 프로그램이 실행되는 위치가 아니라 다른 위치(다양한 서버에 분산됨)를 의미합니다. 호출자는 함수 작업의 결과만 원할 뿐 함수 구현의 구체적인 세부 정보는 필요하지 않습니다.

연습하지 말고 그냥 얘기해 보세요. 다음에는 rpc 원격 호출이 어떻게 구현되는지 포괄적으로 이해하기 위해 세 가지 방법을 사용하겠습니다.

01. xml-rpc 기반

Python에서 rpc를 구현하려면 XML-RPC 프로토콜을 기반으로 하는 표준 라이브러리의 SimpleXMLRPCServer를 사용하면 됩니다.

이 모듈을 사용하면 rpc 서버를 시작하는 것이 매우 간단해집니다. 다음 코드를 실행합니다:

rpc 서버의 다음 단계는 rpc 클라이언트입니다. 위에서 XML-RPC를 사용하고 있으므로 rpc clinet은 xmlrpclib 라이브러리를 사용해야 합니다.

그러면 server_proxy 객체를 통해 이전 rpc 서버의 기능을 원격으로 호출할 수 있습니다.

SimpleXMLRPCServer는 단일 스레드 서버입니다. 즉, 여러 클라이언트가 동시에 여러 요청을 발행하는 경우 다른 요청은 계속하기 전에 첫 번째 요청이 완료될 때까지 기다려야 합니다.

다중 스레드 동시성을 달성하기 위해 SimpleXMLRPCServer를 사용해야 한다면 실제로 어렵지 않습니다. 코드를 다음과 같이 변경하면 됩니다.

02. json-rpc 기반

SimpleXMLRPCServer는 xml-rpc 기반의 원격 호출입니다. 위에서도 xml-rpc 외에 json-rpc도 있다고 언급했습니다. rpc 프로토콜.

그렇다면 Python은 json-rpc 프로토콜을 어떻게 구현합니까?

대답은 다양합니다. 많은 웹 프레임워크가 json-rpc를 자체적으로 구현하지만 우리는 이러한 프레임워크에서 독립되어야 하며 제가 찾은 두 가지 옵션이 있습니다. 첫 번째는 jsonrpclib입니다.

두 번째는 python-jsonrpc입니다.

첫 번째 jsonrpclib를 살펴보겠습니다.

Python 표준 라이브러리의 SimpleXMLRPCServer와 다릅니다. 매우 유사합니다(클래스 이름이 SimpleJSONRPCServer라고 해서 진실을 모르는 사람들은 실제로 형제라고 생각합니다). jsonrpclib는 SimpleXMLRPCServer 표준 라이브러리 이후에 작성되었다고 할 수 있습니다.

SimpleJSONRPCServer는 jsonrpclib 라이브러리에 배포되므로 가져오기가 SimpleXMLRPCServer와 약간 다릅니다.

서버

클라이언트

작성하기가 다소 복잡해 보이는 두 번째 python-jsonrpc를 살펴보겠습니다.

서버

클라이언트

호출 과정은 다음과 같습니다

위에서 언급한 zabbix API와 접촉이 있기 때문에 기억해두세요 그랬으니 그것에 대해 이야기하겠습니다. zabbix API는 json-rpc 2.0 프로토콜을 기반으로 구현됩니다.

내용이 많기 때문에 여기에서는 zabbix가 호출되는 방식만 보여드리겠습니다. zabbix 서버의 어떤 메소드를 호출할지, 이 메소드에 어떤 매개변수를 전달할지 직접 나타냅니다. .

03. zerorpc 기준

위에서 소개한 두 가지 RPC 원격 호출 방법은 잘 찾아보시면 둘 다인 것을 알 수 있습니다.) 내용을 업데이트해서 추가하겠습니다. 통지의.

OpenStack RPC 모듈은 RPC 요청을 보내고 받기 위해 rpc.call, rpc.cast 및 rpc.fanout_cast라는 세 가지 RPC 호출 메서드를 제공합니다.

구현 코드 관점에서 볼 때 rpc.call과 .rpc.cast의 차이는 매우 작습니다. 즉, 호출 시 wait_for_reply=True 매개변수가 있지만 캐스트는 그렇지 않습니다.

rpc의 호출 메커니즘을 이해하려면 먼저 oslo_messaging의 개념을 알아야 합니다. 4가지 주요 방법이 있습니다:

전송: RPC 함수의 기본 구현 방법은 다음과 같습니다. Rabbitmq의 메시지 대기열

전송의 액세스 경로는 연결 메시지 미들웨어에 액세스하는 방법을 정의하는 것입니다. 예를 들어 Rabbitmq를 사용하는 경우 nova에 Transport_url 구성 줄이 있어야 합니다. conf에는 Rabbitmq가 메시지 미들웨어로 지정되어 있고, Rabbitmq에 연결할 사용자, 비밀번호, 호스트 및 포트가 구성되어 있음을 알 수 있습니다.

Target은 RPC 서버가 모니터링하는 주제, 서버가 모니터링하는 서버 이름과 교환, 팬아웃 브로드캐스트 여부를 표현하는 데 사용됩니다.

메시지를 얻으려면 RPC 서버는 집 번호와 마찬가지로 대상을 정의해야 합니다.

메시지를 보내려면 rpc 클라이언트에는 메시지를 보낼 위치를 나타내는 대상도 필요합니다.

끝점: 다른 사람이 원격으로 호출할 수 있는 개체입니다.

RPC 서버는 끝점을 노출합니다. 각 끝점에는 전송을 통해 원격 클라이언트가 호출할 수 있는 일련의 메서드가 포함되어 있습니다. 직관적인 이해를 위해 nova-conductor 코드를 참고하여 rpc 서버를 생성할 수 있습니다. 여기서 엔드포인트는 nova/manager.py: ConductorManager

distributor, 이는 rpc 서버에만 해당되는 개념입니다. /p>

이를 통해서만 서버는 수신된 rpc 요청을 알고, 이를 처리하기 위해 누구에게 넘겨야 하며, 어떻게 처리해야 하는지 알 수 있습니까?

클라이언트 측에서는 호출할 메소드를 지정하는 방법입니다.

서버측에서는 이 메소드가 실행되는지 어떻게 알 수 있나요? 이것이 디스패처가 수행하는 작업입니다. 엔드포인트에서 이 메서드를 찾은 다음 이를 실행하고 최종적으로 반환합니다.

Serializer: Python 객체와 메시지(알림) 간의 데이터를 직렬화하거나 역직렬화하기 위한 기본 클래스입니다.

네 가지 주요 방법이 있습니다:

각 알림 리스너는 실행기에 바인딩되어 수신된 알림이 배포되는 방법을 제어합니다. 기본적으로 차단 실행기가 사용됩니다(특정 기능은 실행기 섹션 참조).

모방은 매우 효율적인 학습 방법입니다. 여기서는 OpenStack 호출 방법을 기반으로 핵심 콘텐츠를 추출하여 간단한 데모에 작성합니다. , OpenStack에 관심이 있는 사람들은 대부분 이 장을 건너뛸 수 있습니다.

다음 코드는 직접 실행할 수 없습니다. 또한 Rabbitmq 연결 방법을 구성해야 합니다. 구성 파일에 작성하거나, get_transport를 통해 cfg.CONF에서 읽거나, 직접 작성할 수 있습니다. url 형식을 매개변수로 만들어 get_transport에 전달합니다. 그리고 nova나 다른 openstack 구성 요소 환경에서 실행해야 합니다(환경 변수 ctxt가 필요하기 때문입니다)

단순 rpc 클라이언트

단순 rpc 서버

끝