На самом деле эта схема уже сильно устарела) Однако, касательно именно этого рисунка - здесь сервисы "А" и "Б" вообще не знают о существовании друг друга. "А" просто кидает сообщение в RabbitMQ, а "Б" отрабатывает все новые, без передачи какой-либо обратной связи.
В результате просто распилили REST API и интеграционную шину на несвязанные между собой сервисы, т.е. REST API просто получает данные от клиентов и мнгновенно заносит их куда нужно, а шина уже работает с данными в своём темпе.
Vitsliputsli, спасибо вам за мини-консультацию. Теперь у меня хотя бы есть понимание в какую сторону двигаться и в каких парадигмах сочетаются REST API и брокеры. Думаю, что ветку можно считать закрытой.
Vitsliputsli, я разделяю ваши сомнения насчёт того, что брокер кажется излишним в этой небольшой цепочке сервисов. Изначальные мои схемы были без брокера, однако, мы будем соединять разношёрстные системы (SaaS-решения и софт на разных языках), а точкой распределения данных будет брокер. Хотя изначально вопрос ставился о том, нужно ли присоединять к нему REST API, через этот диалог постепенно прихожу к выводу, что это как минимум разделит ответственность между FastAPI-приложением и воркерами. Но теперь главный фокус будет на брокера, чтобы в нём не было никакого простоя.
Vitsliputsli, в принципе, всё что вы сказали коррелирует с тем, как мы хотим организоваться. Тогда подитожу:
1) Клиент шлёт запрос через API-шлюз, запрос попадает в FastAPI-приложение;
2) Приложение назначает запросу id и размещает его как сообщение в заранее объявленной durable-очереди RabbitMQ и ждет по нему ответа;
3) Сервис-обработчик прослушивает эту очередь, скачивает сообщение, работает с ним, а затем отправляет json с данными и кодом ответа;
4) Приложение обнаруживает, что сообщение обработалось и возвращает клиенту его содержимое;
5) Если всё завершилось ожидаемым сценарием, приложение закрывает сообщение с флагом "ack".
Сейчас у меня такая картина шины данных с брокером. Надеюсь, у вас тоже.
сергей кузьмин, наши шлюзы для API представлены как SaaS-решение, защищены политиками на уровне OpenAPI-3 и балансировщиком нагрузки. Но как передавать запросы со шлюза до сервера и брокера, в принципе, понятно.
Vitsliputsli, сейчас почти все сервисы работают как прямые интеграции, т.е. креды прописаны в каждом сервисе и запись напрямую в боевые БД. Правильно ли я вас понимаю - задача в том, чтобы назначить условный id (например либой uuid) сообщению (которое является post / get запросом клиента), а после этого "скачать" результат исполнения этой очереди и отдать его клиенту? В таком случае http-соединение не порвётся, так? Чувствуется, что время ожидания вырастет, но врядли это критично, если данные станут реально персистентны. P.s. 4я встреча по обсуждению плюсов/минусов послезавтра
В результате просто распилили REST API и интеграционную шину на несвязанные между собой сервисы, т.е. REST API просто получает данные от клиентов и мнгновенно заносит их куда нужно, а шина уже работает с данными в своём темпе.