В каких случаях лучше использовать брокер сообщений, а в каких gRPC для взаимодействия между сервисами
Что проверяют
Понимаете ли вы разницу между вызовом и событием, и связываете ли выбор с доступностью сервисов.
Как отвечать
Ключевой вопрос: нужен ли вызывающему ответ прямо сейчас.
gRPC это синхронный вызов между двумя известными сторонами поверх HTTP/2 с контрактом в protobuf. Берут, когда:
- результат нужен, чтобы продолжить обработку: получить профиль, проверить лимит, посчитать цену;
- важна низкая задержка: бинарный формат и постоянное соединение дают заметно меньше накладных расходов, чем JSON поверх HTTP/1.1;
- нужен строгий контракт с генерацией клиента и обратной совместимостью полей;
- нужен поток данных в одну или обе стороны.
Брокер (Kafka, RabbitMQ) берут, когда:
- произошло событие, и о нём должны узнать другие, причём отправителю всё равно кто и когда;
- получателей несколько или их состав меняется: добавить нового потребителя не требует правки отправителя;
- получатель может быть недоступен или медленнее отправителя: очередь сглаживает пик и хранит сообщения;
- работа долгая и её незачем ждать: отправка писем, обработка файла, пересчёт отчёта;
- нужны повторы и очередь неразобранного из коробки.
Главное отличие, которое стоит назвать словами про надёжность: синхронный вызов связывает сервисы по доступности. Упал получатель, значит отказывает и вызывающий, а цепочка из четырёх вызовов перемножает их доступности. Брокер эту связь разрывает, но платит согласованностью в конечном счёте: данные обновятся не мгновенно.
На практике оба живут вместе: команды и запросы через gRPC или HTTP, а события через брокер. И там, и там нужны идемпотентность на стороне получателя, таймауты, повторы с ограничением и наблюдаемость.
Где спотыкаются
Используют брокер как замену запросу и ждут ответ через очередь.
Делают цепочку синхронных вызовов и получают отказ всей цепи от одного сервиса.
Не делают обработчик событий идемпотентным.
Считают, что брокер гарантирует доставку ровно один раз.