Сравните REST, gRPC и очереди сообщений для межсервисного взаимодействия.

Question

Accepted Answer

Три основных варианта — это **REST** (HTTP/JSON), **gRPC** (HTTP/2 + Protobuf) и **очереди сообщений** (Kafka/RabbitMQ). REST и gRPC синхронны; очереди асинхронны.

## Сравнение

| Аспект | REST | gRPC | Message Queue |
|---|---|---|---|
| Стиль | Синхр | Синхр | Асинхр |
| Payload | JSON (текст) | Protobuf (бинарный) | Любой (часто бинарный) |
| Производительность | Хорошая | Высокая | Высокая пропускная способность |
| Контракт | OpenAPI (слабый) | `.proto` (строгий) | Schema/event |
| Streaming | Ограниченный | Встроенный (bidi) | Pub/sub |
| Лучше всего для | Публичные API, браузеры | Внутренние критичные пути | Развязка, события |

## Пример контракта gRPC

```proto
service OrderService {
  // strongly-typed RPC, generated client + server stubs
  rpc GetOrder (OrderId) returns (Order);
}
message OrderId { string id = 1; }
message Order  { string id = 1; double total = 2; }
```

## Пример обмена сообщениями

```text
Order Service ─publish→ [ "OrderPlaced" topic ] ─▶ Inventory
                                              └────▶ Notifications
(producer doesn't know or wait for consumers)
```

## Выбор

- **REST** — внешние клиенты, широкая совместимость, удобство чтения.
- **gRPC** — внутренние системы, низкая задержка, высокая нагрузка; строгие контракты; streaming.
- **Очереди** — развязка, буферизация, событийные потоки, защита от сбоев.

## Подводный камень

Использование синхронного gRPC/REST везде пересоздаёт плотную связанность; использование асинхронного для незамедлительного чтения пользователя добавляет ненужную задержку.

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

Выбор транспорта устанавливает границы связанности и производительности для каждого взаимодействия, поэтому выбор для каждого варианта использования — а не глобально — это то, что поддерживает систему одновременно быстрой и устойчивой.

Зрелые системы намеренно комбинируют все три: gRPC на внутренних критичных путях, REST на границе и очереди для рабочих процессов.

Стиль	Синхр	Синхр	Асинхр
Payload	JSON (текст)	Protobuf (бинарный)	Любой (часто бинарный)
Производительность	Хорошая	Высокая	Высокая пропускная способность
Контракт	OpenAPI (слабый)	`.proto` (строгий)	Schema/event
Streaming	Ограниченный	Встроенный (bidi)	Pub/sub
Лучше всего для	Публичные API, браузеры	Внутренние критичные пути	Развязка, события