Какие способы коммуникации используются между микросервисами
Что проверяют
Различаете ли вы синхронное и асинхронное взаимодействие и понимаете ли, чем платит каждое.
Как отвечать
Два больших класса.
Синхронное: вызывающий ждёт ответ.
- REST поверх HTTP: просто, отлаживается curl, кэшируется. Минус в связанности по времени: упал сосед, упали и вы;
- gRPC: бинарный протокол со строгим контрактом и стримингом, быстрее и компактнее. Хорош между своими сервисами;
- GraphQL: чаще как шлюз для клиентов, а не между сервисами.
Асинхронное: отправитель не ждёт.
- брокер очередей (RabbitMQ): задача одному исполнителю, гибкая маршрутизация, повторы, очередь недоставленных;
- журнал событий (Kafka): событие для многих независимых читателей, хранится заданное время, можно перечитать.
Что решает выбор: синхронное берут, когда нужен ответ прямо сейчас и цепочка короткая; асинхронное, когда операция может выполниться позже, когда получателей несколько или когда нельзя зависеть от доступности соседа.
Что обязательно упомянуть: при асинхронном взаимодействии доставка обычно «хотя бы один раз», поэтому обработчики идемпотентны; согласованность становится конечной, и появляются саги; событие и изменение данных пишутся одной транзакцией через Transactional Outbox, иначе они разъезжаются.
Практика чаще смешанная: команда синхронно, факты о произошедшем событиями.
Где спотыкаются
Строят длинные синхронные цепочки и получают лавинообразные отказы.
Считают, что брокер гарантирует ровно одну доставку.
Не делают обработчик идемпотентным.
Публикуют событие отдельно от записи в базу и теряют его при сбое.