Комментарии 5
Хранение сообщений внутри сервиса нужно, что бы уметь повторять сообщения, которые не получилось отправить (ретрай) или что бы поддерживать pull схему, когда к тебе приходят за данными. Но брокер для этих целей не используют ибо у сервиса уже есть что-то, что выполняет его функции. База или просто хранение в памяти. Дополнительно кролик - не нужная сложность, ибо еще придется решать вопрос ошибок записи в этот локальный кролик, т.е. все-равно потребуется какая-то вторая очередь в памяти.
И с точки зрения этой задачи "доставки сообщения" сервису все-равно куда доставлять, в брокера или в другой сервис. Оба могут не принять сообщение. В обоих случаях нужно решать проблему ретраев.
По-этому, если у вас коммуникация "сервис-сервис", то брокер тут избыточен как "посередине", так и "внутри". Т.е. решалась какая-то несуществующая проблема.
Брокер же используют, когда нужна гибкость распределения одного сообщения по разным потребителям (кролик) или же когда нужен накопительный буфер для потоковой работы с данными (кафка).
И вот, для решения гибкого распределения сообщений вы говорите "давайте кролика заменим на сервис, который будет ходить в кролика". В принципе, такое даже делают, но не для того, что бы просто amqp на http заменить (у кролика есть http интерфейс, используйте если так amqp не любите), а решая более комплексные задачи от API композиции до сервис дискавери. А просто написать сервис, который конвертирует amqp кролика под капотом во внешний http - это какое-то усложнение не решающее никаких проблем.
Ваша сравнительна таблица, это такое натягивание совы на глобус, что прям скучно. То брокер сообщений домен размывает, то proto файлы кто-то запретил использовать для сообщений из кролика.
Подождите, если у Вас consumer завис, то таким образом он завешивает и всех publisher'ов, потому, что они будут заниматься повторением отправки сообщений. В итоге всё лежит. Не вижу никаких плюсов в том, чтобы перекладывать доставку сообщений на сервис. Да и зачем каждому сервису очередь? Обычно очередь используется для доставки сообщений между сервисами, а не в пределах одного.
@miksir Возможно не правильно понял вашу мысль, но не согласен с утверждением
По-этому, если у вас коммуникация "сервис-сервис", то брокер тут избыточен как "посередине", так и "внутри". Т.е. решалась какая-то несуществующая проблема.
Брокера нужно рассматривать в данном случае как транспорт, такой же как и http запрос.
Возьмём пример, когда пользователь жме кнопку на сайте, она делает локальные изменения, а затем шлёт информацию в другой сервис. Если мы используем обычный http запрос в обработке нажатия кнопки, то вынуждено поймаем лаг в интерфейсе, пока отправим запрос и пока его отработает другой сервис... (в js это будет диалог со с прогрузкой, а где то в другом месте вплоть до повисания интерфейса (не весь мир радужный, есть старые системы не умеющие многопоток)).
Поэтому мы сохраняем сообщение в локальном сервисе (для истории или дальнейшей обработки после подтверждения другим сервисом). Отправляем в брокера сообщение возвращаем поток в интерфейс пользователя.
Ок рассмотрим вариант когда мы не используем брокера, а сохраняем сообщения для дальнейшей отправки позже. Сохранили локально, вернули в интерфейс пользователя результат что принято на обработку. Как их дальше обработать? Нам нужен сервис или служба локальная, которая пройдёт по этим сообщениям и выполнит запросы к другим сервиса. В дополнение, когда начинать обработку? Вечный цикл с таймаутом в пару сек? При запросе к нашему сервису по обмен?
Что то напоминает? Мы практически сделали свой брокера, кривой, не функциональный, но очень похожий функционал. Вопрос, а зачем мы это сделали, и почему же бы нам не использовать готовые инструменты?
Автор путает базу и субд сервер.
У микросервисов даже когда базы разные очень часто шарится субд сервер.
С очередями так же история. Брокер шарится, а очереди разные
Message broker per service