# 마이크로 서비스 통신 설계

마이크로서비스에서 각 서비스들을 호출하기 위한 여러가지 통신 방법이과 고려해야 될 사항들이 있다.

RPC 선택시 고려 사항

API에 대한 RPC 메커니즘을 선택하기 전에 서비스와 클라이언트 간의 상호 작용 스타일을 고려하는 것이 좋다.

1. 상호 작용이 일대일인지 일대다인지 여부
2. 상호 작용이 동기식인지 비동기식인지 여부
   

• One-way notifications: 클라이언트가 서비스에 요청을 보내지만 응답을 기대하지 않는 방식

메시지 형식

1. 텍스트 형식

JSON or XML은 가장 많이 사용되는 텍스트 기반 형식이다.

👍장점

• 사람이 읽을 수 있다.

👎단점

• 메시지가 장황하다.
• 텍스트 구문 분석과 관련된 오버헤드가 존재한다.

2. 바이너리 형식

Thrift, Protocol Buffers(Protobuf) 및 Avro는 가장 많이 사용되는 바이너리 형식이다.

👍장점

• 메타 데이터가 최소한이므로 페이로드가 작다.
• 텍스트 기반 구문 분석보다 비교적 빠르다.

👎단점

• 사람이 읽을 수 없다.

동기 호출 패턴

호출 패턴으로는 REST / GraphQL / gRPC 와 같은 동기식 통신 메커니즘 또는 AMQP / STOMRMP 등 비동기식 메시지 기반 통신 메커니즘이 있다.

1. REST

HTTP URI를 통해 자원을 명시하고 HTTP 메서드를 통해 해당 자원에 대한 CRUD 작업을 처리하는 것

1. REST API 정의
   가장 인기있는 REST 인터페이스 정의 언어는 OpenAPI 입니다.
2. 단일 요청으로 여러 리소스를 가져와야 하는 과제
   이러한 확장성 부족으로 인해 발생할 수 있는 언더패치나 오버패치를 해결하기 위해 페이스북의 GraphQL이나 넷플릭스의 Falcor 같은 대체 API 기술이 점점 인기를 얻고 있다.
3. HTTP 동사에 대한 매핑 작업의 과제
   REST API 디자인 문제는 수행하려는 작업을 HTTP 메서드에 매핑하면서 발생한다. PUT을 사용해서 주문을 취소, 수정 등의 업데이트 작업을 해야한다면 다음과 같이 해결할 수 있을 것이다.

• 주문 취소: /orders/{orderId}/cancel
• 주문 수정: /orders/{orderId}/revise
  이렇게 하위 리소스를 정의하여 처리할 수 있겠지만 이는 RESTful하지 않다. 이런 문제의 결과로 gRPC와 같은 대안이 인기를 얻고 있다.

2. gRPC

gRPC는 구글이 개발한 고성능의 오픈소스 RPC 프레임워크로 MSA 구조안에서 여러 언어로 작성된 서비스들 간의 통신을 지원한다.

HTTP/2를 사용하며 메시지 형식은 바이너리 타입의 protobuf를 사용하기 때문에 상대적으로 적은 페이로드를 사용하고 효율적이다.

1. .proto 파일 내부에 서비스를 정의한다.
2. protocol buffer compiler를 이용하여 서버와 클라이언트 코드를 작성한다.
3. 서버 인터페이스를 구현하고 gRPC 서버를 생성한다.
4. 클라이언트 어플리케이션을 만들고 RPC 호출을 한다.

👍장점

• 풍부한 업데이트 작업이 있는 API를 비교적 간단히 디자인할 수 있다.
• 메시지 형식이 바이너리라 작고 효율적이다.
• 양방향 스트리밍을 통해 RPC와 메시징을 모두 사용할 수 있다.
• 다양한 언어로 작성된 클라이언트들과 통신이 가능하다.

👎단점

• REST/JSON 기반 API보다 더 많은 작업을 수행해야 한다.

3. GraphQL

GraphQL은 클라이언트에 데이터를 표시하는 방법을 쿼리로 정의함으로써 단일 요청을 사용하여 여러 리소스를 가져오는 문제를 해결한다.

GraphQL 서버는 클라이언트에 스키마(요청할 수 있는 데이터 모델)를 제공한다.

👍장점

• 클라이언트는 서버에서 필요한 것을 정확하게 지정하여 언더패칭, 오버패칭을 줄이고 유연한 확장성을 가질 수 있다.

👎단점

• 기본 제공 캐싱 지원이 없음
• REST보다 복잡하다.

비동기 호출 패턴

1. One-way notifications

서비스는 채널을 구독하고 메시지를 처리한다. 응답이 다시 전송되지 않는다.

2. Publish / Subscribe

클라이언트는 여러 구독자가 읽을 수 있는 채널에 메시지를 게시하고 필요에 따라 여러 서비스가 구독하여 메시지를 처리한다.

3. Publish / Async Response

Pub/Sub 방식과 Request/Response 방식을 결합하여 더 높은 수준의 상호 작용을 형성한다.

참고사이트