마이크로서비스는 서로 어떻게 통신하나요?

Question

Accepted Answer

서비스는 **동기적으로**(REST나 gRPC를 통한 요청/응답) 또는 **비동기적으로**(Kafka나 RabbitMQ 같은 브로커를 통한 메시지/이벤트) 통신합니다.

## 동기(요청/응답)

호출자는 응답을 기다립니다. 단순하고 직관적이지만 가용성을 결합시킵니다. 즉, 피호출자가 다운되면 호출자도 영향을 받습니다.

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## 비동기(메시징/이벤트)

발신자는 메시지를 발행하고 다음 작업으로 넘어갑니다. 소비자는 나중에 그것을 처리합니다. 이는 서비스를 시간적으로 분리합니다.

```text
Order Service ──"OrderPlaced" 발행──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## 언제 무엇을 쓸까

| 필요 | 선택 |
|---|---|
| 사용자에게 즉각적인 응답 | 동기 |
| 분리, 버퍼링, 팬아웃 | 비동기 |
| 강한 시간적 결합이 허용됨 | 동기 |
| 다운스트림 장애에 대한 복원력 | 비동기 |

## 함정

긴 **동기 호출 체인**(A → B → C → D)은 지연 시간과 장애 확률을 곱셈으로 증가시킵니다. 가능하면 비동기나 집계를 선호하세요.

## 왜 중요한가

통신 스타일은 시스템의 복원력을 결정합니다. 동기 호출은 추론하기 쉽지만 런타임에서 강한 결합을 만들고, 비동기 메시징은 eventual consistency를 대가로 분리를 얻습니다.

대부분의 실제 시스템은 두 가지를 혼합합니다. 사용자 대면 읽기에는 동기를, 백그라운드 워크플로에는 비동기를 사용합니다.