프로세스 간 통신

동기 RPI 패턴 응용 통신

• RPI는 클라이언트가 서비스에 요청을 보내면 서비스가 처리 후 응답을 회신하는 IPC 입니다.

• 대기 중에는 블로킹하는 클라이언트도 있고, 리액티브한 논블로킹 아키텍처를 가진 클라이언트도 있습니다.

• 모두 응답이 제때 도착하리라 가정합니다.

1. 동기 RPI 패턴 : REST

• 단순하고 익숙합니다.

• 포스트맨(Postman)같은 브라우저 플러그인이나 curl 등의 CLi 도구를 사용해서 HTTP API를 간편하게 테스트할 수 있습니다.

• 요청/응답 스타일의 통신을 직접 지원합니다.

• HTTP는 방화벽 친화적입니다.
• 단일 포트 사용/ 인터넷에서 서버 접속 가능/ TCP 사용

• 중간 브로커가 필요하지 않기 때문에 시스템 아키텍처가 단순해집니다.

• 요청 한 번으로 많은 리소스를 가져오기 어렵다.

• 작업을 HTTP 동사에 매핑하기 어렵다. (다중 업데이트 작업 등)

• 요청/응답 스타일의 통신만 지원합니다.

• 가용성이 떨어집니다. 중간에서 메시지를 버퍼링하는 매개자 없이 클라이언트/서비스가 직접 통신하기 때문에 교환이 일어나는 동안 양쪽 다 실행 중이어야 합니다.

• 서비스 인스턴스(들)의 위치(URL)를 클라이언트가 알고 있어야 합니다. 요즘 애플리케이션은 서비스 디스커버리 메커니즘을 이용해서 클라이언트가 서비스 인스턴스 위치를 찾을 수 있으므로 큰 단점은 아닙니다.

1. 동기 RPI 패턴 : gRPC

HTTP는 한정된 동사만 지원하기 때문에 다양한 업데이트 작업을 지원하는 REST API를 설계하기가 쉽지 않습니다. 그래서 등장한 기술이 바로 gRPC 입니다.

• 프로토콜 버퍼 포맷의 이진 메시지를 HTTP/2를 통해 교환

• 다양한 업데이트 작업이 포함된 API를 설계하기 쉽습니다.

• 특히 큰 메시지를 교환할 때 콤팩트하고 효율적인 IPC입니다.

• 양방향 스트리밍 덕분에 RPI, 메시징 두 가지 통신 방식 모두 가능합니다.

• 다양한 언어로 작성된 클라이언트/서버 간 연동이 가능합니다.

• 자바스크립트 클라이언트가 하는 일이 REST/JSON 기반 API 보다 더 많습니다.

• 구형 방화벽은 HTTP/2를 지원하지 않습니다.