Что лучше выбрать для взаимодействия в микросервисной архитектуре? MessageBroker или REST?

Question

[UsmanovTim]

Добрый день! Проектирую систему, которая в будущем будет держать большие нагрузки. До этого проектировал только монолитные решения. Это мой первый опыт проектирования микросервисов. Стоит дилемма что выбрать для общения сервисов друг с другом. Вижу 2 варианта.
1) REST - понятный, простой в документировании, но есть точка отказа в виде API Gateway
2) RPC через message broker(пока на rabbitmq) - удобный в масштабировании и балансировке, но также есть точка отказа в виде брокера.
Оба варианта со своими преимуществами и недостатками. И как такового перевеса в выборе нет. Хочу поинтересоваться что у Вас в компании используется в коммуникации сервисов? И есть ли какие -то подводные камни в данных методах?

Comments

[Maksim B]

Большие данные будут?

[Everything_is_not_so_bad]

в будущем будет держать большие нагрузки.

а в цифрах это сколько? 1000 запросов в день? Миллион в секунду?
Есть ли взаимодействие с пользователем? Какое? Сколько пользователей?

Answer 1

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

Зависит от того что именно за данные (для какой цели) будут передаваться и между кем и кем.
Rest как и любой другой синхронный метод взаимодействия несёт плюсы:
+ Сравнительно быстрая реакция на запрос и ответ. (как правило от запроса до получения ответа менее секунды)
+ Очень прост в использовании, нет никаких проблем с поддержкой на клиенте
+ Очень простая инфраструктура (в минимальном варианте она не нужна вообще)
+ Всё хорошо изучено. Та же аутентификация и авторизация очень легко реализуется в рамках http.
+ Достаточно легко разрабатывать и тестировать
+ Есть grpc и openapi - нет никакой проблемы с документированием такого API.
+ В http запрос с каким-нибудь multipart form data может спокойно быть размером в десятки мегабайт, а может и больше - полезно при загрузке файлов.
И минусы:
- Не понятно что делать, в случае недоступности ответной стороны
- При неправильной реализации клиента (политики ретраев) - можно легко заддосить сервер

Всякие разнообразные брокеры сообщений тоже имеют свои плюсы:
+ Строгая очерёдность обработки данных (событий) из коробки
+ В случае недоступности ответной стороны - брокер у себя может хоть несколько дней держать данные
+ Все политики ретраев реализуются на стороне брокера
+ Если это rabbit, то можно разные сложные механики рассылки и маршрутизации реализовать
+ Если это кафка или какой-то другой лог, то можно вычитывать события повторно

Но есть и минусы:
- Инфраструктура обычно сложнее
- Достаточно большие задержки
- Использовать можно будет только у себя внутри - внешнему клиенту (браузер, мобильное приложение, публичный API) такое дать не получится.
- Сложнее разграничивать в правах.
- Сложно разрабатывать и тестировать. На примере той же кафки - подключиться к топику и записать в него что-то через гуй - это отдельный челендж.
- Запросы должны быть небольшими (сотни кб)

Comments

[UsmanovTim]

Внутри системы данные бегают между сервисами бизнес-логики и доменным уровнем. БЛ забирает данные с доменного уровня и крутит ими как нужно. По большей части они синхронные и сейчас понимаю что быстрее и проще их построить по REST, так как ответ всегда нужен здесь и сейчас, а события или отложенные задачи сделать через брокер. Большое спасибо!

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

UsmanovTim, ага, так обычно и делают

Answer 2

[Петр]

Тут зависит от выбранного подхода.
Для примера:
Front/Moblie -> (REST API) -> API Gateway -> (GRPC) -> Service.
Сами сервисы между собой только нотификациями, через Message Broker (RebbitMq)

Comments

[UsmanovTim]

Только нотификациями? А как SAGA реализована? В случае хореографии понятно пустил событие и оно пошло по сервисам. А в случае оркестрации, когда нужно получить подтверждение?

[Петр]

У нас не нужно подтверждение. Каждый сервис является "источником правды", а все остальные сервисы просто обновляют у себя частичку/копию нужной информации.
Сообщения вида "Создан пользователь ID такой-то, Name такой-то" и все сервисы кто подписан и кому нужна какая-то информация о пользователе просто обновляют свои данные.

[UsmanovTim]

Петр, Понял. Большое спасибо!

Answer 3

[mayton2019]

Современные брокеры такие как Kafka не имеют одной точки отказа. Можешь их рассмотреть вместо кролика.

REST является синхронным по своему дизайну. Тоесть ты вызываешь rest метод и ждешь ответа именно на этот
вызов в отличие от MQ где ты просто шлешь уведомления и тебе безразличен отклик. Поэтому MQ обычно
быстрее и дешевле когда у тебя идут тысячи и миллионы месседжей в секунду.

В REST можно делать пакетные (batch) методы. Это ускоряет обработку при массовом обслуживании
но и коды ошибок будут тоже возвращаться в виде batch ошибок и их надо соотв также пачкой и обработать
а это все усложняет бизнес-логику.

Comments

[UsmanovTim]

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

[mayton2019]

Еще посмотрите Красную Панду https://redpanda.com/
Может подойдет. В современном мире нет смысла вкладываться в Rabbit, Apache MQ, IBM-MQ
системы. Они все - старого поколения и их преимущество только одно - это сетевые протколы.
И если у вас нет задачи поддержки старого протокола (как любят в банках) то вам и нет смысла
смотреть в рухлядь.