Какие существуют способы коммуникации между микросервисами? Опишите их плюсы, минусы и типичные сценарии использования.

Ответ

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

1. Синхронная коммуникация (запрос-ответ)

Когда один сервис отправляет запрос другому и ожидает ответа.

a) HTTP/REST Простой и самый распространенный способ, основанный на стандартных HTTP-методах (GET, POST, PUT, DELETE) и кодах состояния.

Плюсы: Простота, понятность, огромное количество инструментов и библиотек, человекочитаемый формат (JSON).
Минусы: Относительно высокие накладные расходы (текстовый формат, HTTP-заголовки), сильная связанность сервисов (отправитель должен ждать ответа).
Сценарий: Публичные API, простые внутренние запросы, где производительность не является критическим фактором.
```
// Клиент делает запрос к сервису B
resp, err := http.Get("http://service-b/api/data")
```

b) gRPC (Google Remote Procedure Call) Высокопроизводительный RPC-фреймворк от Google. Использует Protocol Buffers для сериализации данных и HTTP/2 для транспортировки.

Плюсы: Высокая производительность (бинарный формат), строгая типизация контрактов (.proto файлы), поддержка стриминга, автоматическая генерация кода клиента и сервера.
Минусы: Сложнее в настройке и отладке по сравнению с REST, бинарный формат не является человекочитаемым.
Сценарий: Внутреннее взаимодействие между сервисами в высоконагруженных системах, где важны низкая задержка и строгие контракты.
```
// Пример .proto файла
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
}
```

2. Асинхронная коммуникация (событийная)

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

a) Брокеры сообщений (RabbitMQ, NATS, Kafka) Сервис-продюсер отправляет сообщение (событие) в очередь или топик, а сервис-консьюмер подписывается на эти сообщения и обрабатывает их в удобное для себя время.

Плюсы: Слабая связанность (сервисы не знают друг о друге), повышенная отказоустойчивость (если сервис-получатель недоступен, сообщение останется в очереди), масштабируемость.
Минусы: Усложнение архитектуры (необходимо поддерживать брокер), сложность отслеживания цепочки вызовов.

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

// Публикация сообщения в RabbitMQ
err := ch.Publish(
"orders_exchange", // exchange
"new_order",       // routing key
false,             // mandatory
false,             // immediate
amqp.Publishing{
    ContentType: "text/plain",
    Body:        []byte(body),
})

Выбор технологии

Внешние API: Чаще всего REST или GraphQL (для гибких запросов от фронтенда).
Внутренние коммуникации: gRPC для производительности и строгих контрактов.
Событийные потоки: Брокеры сообщений для асинхронных задач и декомпозиции логики.