Имеет ли смысл реализация REST API через RabbitMQ?

Question

[Borisawa]

Разрабатываю интеграционную шину данных (ESB) в небольшой организации с RabbitMQ. У нас есть REST API с 4 методами для подрядчиков (они передают данные и получают в ответ id созданной сущности в нашей CRM на корп. портале), его схема работы выглядит так:
Отдельные лица в отделе настаивают на реализации запросов к REST API через RabbitMQ, чтобы был один единый сервис для транзита всех данных. Но мне это кажется странным, поскольку:
1) Это будет точкой отказа для всех сервисов;
2) Нельзя реализовать ответ для http-запроса, ведь брокер разделяет процесс и не предназначен для синхронных запросов (так мне кажется).
То, как будет работать шина без REST API представлено на рисунке:.
Мой вопрос: следует ли реализовывать передачу данных по REST API через RabbitMQ в данном случае?
Спасибо.

Comments

[сергей кузьмин]

а то.

как Apigee Google Cloud's API management platform, designed to help organizations

только маленькая

[Vitsliputsli]

1) Это будет точкой отказа для всех сервисов;
2) Нельзя реализовать ответ для http-запроса, ведь брокер разделяет процесс и не предназначен для синхронных запросов (так мне кажется).

1) разумеется, но другие плюсы могут перевешивать этот минус.
2) почему нет? типичная схема: клиент отправляет запрос по http и ждет, сервер валидирует запрос и кидает сообщение в брокер, оно там многократно крутится по разным сервисам, затем формируется сообщение для сервера работающего с http, он его забирает и формирует ответ по http.

Мой вопрос: следует ли реализовывать передачу данных по REST API через RabbitMQ в данном случае?

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

[сергей кузьмин]

Vitsliputsli, Это будет точкой отказа для всех сервисов
it is common practice for an API Gateway to be load balanced, although the API Gateway itself can sometimes provide some basic load balancing capabilities for backend services.

[Vitsliputsli]

сергей кузьмин,

Vitsliputsli, Это будет точкой отказа для всех сервисов
it is common practice for an API Gateway to be load balanced, although the API Gateway itself can sometimes provide some basic load balancing capabilities for backend services.

Можно подробнее. А то непонятно причем здесь балансировка API Gateway.

[Borisawa]

Vitsliputsli, мне кажется, что это бот или просто копирование из документации гугл...

[сергей кузьмин]

Borisawa, мне тоже

[Borisawa]

Vitsliputsli, сейчас почти все сервисы работают как прямые интеграции, т.е. креды прописаны в каждом сервисе и запись напрямую в боевые БД. Правильно ли я вас понимаю - задача в том, чтобы назначить условный id (например либой uuid) сообщению (которое является post / get запросом клиента), а после этого "скачать" результат исполнения этой очереди и отдать его клиенту? В таком случае http-соединение не порвётся, так? Чувствуется, что время ожидания вырастет, но врядли это критично, если данные станут реально персистентны.
P.s. 4я встреча по обсуждению плюсов/минусов послезавтра

[сергей кузьмин]

Vitsliputsli,

API-шлюзы обычно балансируются с помощью специального балансировщика нагрузки, который находится перед ними - для обработки большого объема входящих запросов API часто развертывается несколько экземпляров самого API-шлюза

в некоторых организациях делают свои gateway ( напр Wells Fargo / USA) - на основе HA Proxy / SOLR / WSO2/ Consul - но не у всех получается

consul опериодически прашивает бек сервисы и обнонвляет ha proxy config и свой DNS

[Borisawa]

сергей кузьмин, наши шлюзы для API представлены как SaaS-решение, защищены политиками на уровне OpenAPI-3 и балансировщиком нагрузки. Но как передавать запросы со шлюза до сервера и брокера, в принципе, понятно.

[сергей кузьмин]

Borisawa, на загнивающем часто кончается покупкой коробочного решения от того же гугла (apigee) или мелкомягких - название не помню -

потому что наколеночные решения не удовлетворяют (подробности сложно объяснять и не имею права)

[Vitsliputsli]

Borisawa,

сейчас почти все сервисы работают как прямые интеграции, т.е. креды прописаны в каждом сервисе и запись напрямую в боевые БД.

А с шиной они будут общаться только с ней, соответственно конфигурировать проще, и независимость сервисов выше. А если все сервисы общаются со всеми, и их много, то это еще больше склоняет чашу в сторону общей шины.

Правильно ли я вас понимаю - задача в том, чтобы назначить условный id (например либой uuid) сообщению (которое является post / get запросом клиента), а после этого "скачать" результат исполнения этой очереди и отдать его клиенту? В таком случае http-соединение не порвётся, так? Чувствуется, что время ожидания вырастет, но врядли это критично, если данные станут реально персистентны.

Да, типа того. Прям подробно не скажу, нет сейчас под рукой такой системы, но логично что процесс, который принял запрос, размещая его в брокере указывает себя как отправителя. И когда сообщение будет обработано всеми необходимыми сервисами, конечное сообщение будет в адресате иметь этот адрес отправителя (да, какойто условный id).
Т.е. пока идет обработка, процесс работающий с http висит на связи с брокером и ждет предназначенное ему сообщение. Нет никаких причин соединению отваливаться, разве что по таймауту, но это вопрос скорости работы сервисов.
Время ожидания вырастет, но вряд ли критично, можете сами прикинуть, на основе кол-ва пересылок (т.е. кол-ва сервисов) и сетевого лага между ними. Если они в одном ДЦ, то это немного. Затраты накладные на брокер тоже будут небольшие. Другое дело, что брокер будет обрабатывать весь трафик, и там должна быть достаточная машина. Это может быть проблемой, если трафик очень большой.
И еще, обратите внимание на момент, как будете управлять сообщениями, т.е. хореография или оркестрация. Этот выбор потом поменять очень сложно, поэтому выбирать нужно ответственно.

[Borisawa]

Vitsliputsli, в принципе, всё что вы сказали коррелирует с тем, как мы хотим организоваться. Тогда подитожу:
1) Клиент шлёт запрос через API-шлюз, запрос попадает в FastAPI-приложение;
2) Приложение назначает запросу id и размещает его как сообщение в заранее объявленной durable-очереди RabbitMQ и ждет по нему ответа;
3) Сервис-обработчик прослушивает эту очередь, скачивает сообщение, работает с ним, а затем отправляет json с данными и кодом ответа;
4) Приложение обнаруживает, что сообщение обработалось и возвращает клиенту его содержимое;
5) Если всё завершилось ожидаемым сценарием, приложение закрывает сообщение с флагом "ack".
Сейчас у меня такая картина шины данных с брокером. Надеюсь, у вас тоже.

[Vitsliputsli]

Borisawa,

Vitsliputsli, в принципе, всё что вы сказали коррелирует с тем, как мы хотим организоваться. Тогда подитожу:
1) Клиент шлёт запрос через API-шлюз, запрос попадает в FastAPI-приложение;
2) Приложение назначает запросу id и размещает его как сообщение в заранее объявленной durable-очереди RabbitMQ и ждет по нему ответа;
3) Сервис-обработчик прослушивает эту очередь, скачивает сообщение, работает с ним, а затем отправляет json с данными и кодом ответа;
4) Приложение обнаруживает, что сообщение обработалось и возвращает клиенту его содержимое;
5) Если всё завершилось ожидаемым сценарием, приложение закрывает сообщение с флагом "ack".
Сейчас у меня такая картина шины данных с брокером. Надеюсь, у вас тоже.

В принципе да, вы описали вариант простой очереди, т.е. у вас очередь заданий, и воркер(ы) которые эту очередь разбирают. Для такого варианта я скорее всего не стал бы подключать брокер (если его в архитектуре не было), а реализовал бы очередь в БД (по уже названным причинам, лишняя точка отказа и т.д.).
Но, если в п.3 сервис-обработчик не один (не в смысле 1 масштабирован в несколько, а в смысле обработчики осуществляющие разную бизнес-работу), т.е. обработчик сделал свое и отправил следующему, следующий дальше и т.д. Т.е. когда не 1 очередь, а пересылка между разными сервисами, тогда нужен брокер.

[сергей кузьмин]

Vitsliputsli, https://ru.wikipedia.org/wiki/%D0%98%D0%B7%D0%B4%D...

на кафке не на базе

[Borisawa]

Vitsliputsli, я разделяю ваши сомнения насчёт того, что брокер кажется излишним в этой небольшой цепочке сервисов. Изначальные мои схемы были без брокера, однако, мы будем соединять разношёрстные системы (SaaS-решения и софт на разных языках), а точкой распределения данных будет брокер. Хотя изначально вопрос ставился о том, нужно ли присоединять к нему REST API, через этот диалог постепенно прихожу к выводу, что это как минимум разделит ответственность между FastAPI-приложением и воркерами. Но теперь главный фокус будет на брокера, чтобы в нём не было никакого простоя.

[Vitsliputsli]

Borisawa, архитектура вещь сложная, любой архитектор всегда смотрит субъективно, поэтому хорошая практика обсуждение архитектуры между несколькими лицами. Мое мнение не важно, смотрите на саму информацию и на сколько она вам подходит. Ну т.е. для 1 небольшой очереди действительно может быть избыточным, но вдруг это только первый шаг и у вас там глобальные планы по расширению проекта, тогда разумеется стоит сразу закладываться на более сложное, но универсальное решение.

[Borisawa]

Vitsliputsli, спасибо вам за мини-консультацию. Теперь у меня хотя бы есть понимание в какую сторону двигаться и в каких парадигмах сочетаются REST API и брокеры. Думаю, что ветку можно считать закрытой.

Answer 1

[Анатолий Емелин]

Это будет какой-то сервис между брокером и клиентами брокера. Такое делают если у клиента нет возможности работать с брокером напрямую (нет нативного клиента). Например, 1С. Там нет возможности напрямую подключится к RabbitMQ, вот для этого делают прокладку, которая умеет работать с api 1С сервера и коннектиться RabbitMQ, . Транспортом может быть HTTP, WebSocet ... да могут быть даже ftp и просто файлы в общих папках))). Да все будет асинхронно. Вообще синхронность какойто большой системы такой же большой вопрос. По большому счету синхронным бывает только эхо запрос). Это вечное "а клиент/сервер может подождать ответа?" ))) Тут скорее важна гарантированная доставка с гарантированной очередностью например по времени.
По схеме вижу идею какого-то нотификатора, которым A пинает B когда отправил ему сообщение, а тот должен синхронно отреагировать на этот запрос или просто сказать: "Посмотрю и отпишусь"? ...

Comments

[Borisawa]

На самом деле эта схема уже сильно устарела) Однако, касательно именно этого рисунка - здесь сервисы "А" и "Б" вообще не знают о существовании друг друга. "А" просто кидает сообщение в RabbitMQ, а "Б" отрабатывает все новые, без передачи какой-либо обратной связи.
В результате просто распилили REST API и интеграционную шину на несвязанные между собой сервисы, т.е. REST API просто получает данные от клиентов и мнгновенно заносит их куда нужно, а шина уже работает с данными в своём темпе.