Как микросервисы взаимодействуют друг с другом?

Question

Accepted Answer

Сервисы взаимодействуют либо **синхронно** (запрос/ответ через REST или gRPC), либо **асинхронно** (сообщения/события через брокер, такой как Kafka или RabbitMQ).

## Синхронное взаимодействие (запрос/ответ)

Вызывающая сторона ждёт ответа. Просто и понятно, но создаёт связь по доступности — если вызываемый сервис недоступен, вызывающая сторона затронута.

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

## Асинхронное взаимодействие (сообщения/события)

Отправитель публикует сообщение и переходит к следующему; потребители обрабатывают его позже. Это разделяет сервисы по времени.

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

## Когда что использовать

| Требование | Выбирайте |
|---|---|
| Немедленный ответ пользователю | Синхронное |
| Развязка, буферизация, разветвление | Асинхронное |
| Сильная временная связь допустима | Синхронное |
| Устойчивость к сбоям нижестоящих сервисов | Асинхронное |

## Ловушка

Длинные **синхронные цепочки** (A → B → C → D) увеличивают задержку и вероятность отказа в геометрической прогрессии. По возможности предпочитайте асинхронность или агрегацию.

## Почему это важно

Стиль взаимодействия определяет устойчивость системы: синхронные вызовы легко анализировать, но создают тесную привязку к времени выполнения, в то время как асинхронные сообщения обеспечивают развязку ценой итоговой согласованности.

Большинство реальных систем используют оба подхода — синхронный для ориентированного на пользователя чтения, асинхронный для фоновых рабочих процессов.

Требование	Выбирайте
Немедленный ответ пользователю	Синхронное
Развязка, буферизация, разветвление	Асинхронное
Сильная временная связь допустима	Синхронное
Устойчивость к сбоям нижестоящих сервисов	Асинхронное