GRPC или RabbitMQ что лучше использовать для взаимодействия между API Gateway и микросервисами?

Question

[nnn Xion]

Разрабатываю архитектуру микросервисов с использованием API Gateway. Не могу определиться между gRPC и RabbitMQ для взаимодействия между API Gateway и микросервисами и между самими микросервисами. Что лучше выбрать и почему?

Answer 1

[Василий Банников]

1. Зачем вообще нужны усложнения, почему в рамках ваших сервисов не использовать rest api (обычный голый http с json-ами)?
2. grpc vs rabbitmq - это больше вопрос про синхронное vs асинхронное взаимодействие.
В зависимости от конкретного случая может быть лучше одно, а может быть лучше другое.
Как правило при использовании api gateway имеет место синхронное взаимодействие, тк ожидается, что сервер ответит на http-запрос в течение пары секунд (как правило меньше секунды).

При желании, можно поверх rabbitmq устроить rpc, но там всё равно будет более высокая нагрузка на железо, чем если бы напрямую происходил вызов.

Comments

[d'Ivan]

При желании, можно поверх rabbitmq устроить rpc, но там всё равно будет несравнимо большая задержка и нагрузка на железо (тк все сообщения идут через диск и им же ограничены)

в зависимости от того как очередь определена:

Metadata of a durable queue is stored on disk, while metadata of a transient queue is stored in memory when possible.

https://www.rabbitmq.com/queues.html#durability

[Василий Банников]

Иерокопус Таманский, о, не знал что оно так работает. Никогда не создавал transient queue

Answer 2

[Валентин Бируля]

Это два совершенно разных подхода не исключающих друг друга.
Один используется для синхронного получения данных, второй для асинхронного.

gRPC быстрее(приблизительно в 5 раз) REST за счет протокола передачи, это весомое преимущество в больших проектах. Но он не может общаться с фронтом.

RabbitMQ же идеально подходит для асинхронного(не исключая синхрон, но если делаешь синхрон на брокерах нужно понимать зачем ты это делаешь) взаимодействия (например для сборов логов), он уступает по многим параметрам Kafka, но для маленьких/средний проектов с EDA идеален.

Если это Pet проект рекомендую попробовать оба.

Comments

[Q2W]

> gRPC быстрее(приблизительно в 5 раз) REST за счет протокола передачи

Как так? Оба ведь поверх http работают. Ну gRPC протобафом сериализует против json'а. Но на этом всё.

[Валентин Бируля]

Не совсем один:
у gRPC http 2 передает по сети 0 и 1
у REST http 1.1 передает по сети текст

Разница очень весомая за счет этого

[d'Ivan]

Валентин Бируля,

http 2 передает по сети 0 и 1

оба протокола HTTP работают на последнем сетевом уровне. Так что оба передают нули и единицы.
Но у 1.1 заголовки текстовые, без сжатия и нет мультиплексирования при передаче.
Интересно сравнивать gRPC и REST только в контексте HTTP 2. В теории, REST может так же работать с BLOB, как gRPC. Тогда преимущества последнего частично нивелируемы.

Answer 3

[Everything_is_bad]

Без разницы, это видно уже на уровне вопроса. И да, делай монолит.

Comments

[nnn Xion]

не хайпово