LINUX.ORG.RU

Объясните некоторые моменты RabbitMQ

 


0

4

Всем привет. В общем сломал всю голову, читая документацию по RabbitMQ, но так и не нашёл ответы на некоторые вопросы. Может кто умеет готовить кролика и подскажет куда копать, а то у меня в голове уже овсянка =(

Если говорить о микросервисах, то пока понятно только то, что на 1 микросервис создаётся 1 подключение. А дальше куча вопросов

Нужен ли второй канал внутри одного подключения или хватит одного? - Ну типа через один канал принимаем сообщения, а через другой отправляем. Где-то читал, что нужно открывать по 1 каналу на поток. Но что в контексте приложения значит «поток»?

Сколько нужно обменников и нужны ли они вообще, если есть стандартные обменники? Как правильно выбрать тип обменника?. Предположу, что это скорее архитектурный вопрос и каждый решает для себя сам, но вдруг есть какая-то конвенция или даже логика.

Сколько нужно очередей?. Пока думаю, что для каждого сервиса нужна только 1 очередь (даже если будет запущено 10 сервисов reports, то они все будут слушать очередь reports)

routeId vs headers - какой вариант лучше использовать в какой ситуации и почему.

если послать запрос в fanout, куда должны отвечать все получатели запроса? как понять, что никто не промолчал? а как понять что какому-то сервису реально нечего ответить? То есть как в итоге понять, что все получили запрос, поняли его и отреагировали если должны, что никто в это время еще не готовит какой-то долгий ответ. Есть подозрение, что ответы от сервисов как бы вообще не стоит ждать но, что тогда делать, если мне нужно в один response клиенту собрать ответы от нескольких сервисов.

А если у меня например что-то типа slack (просто это самый подходящий пример для объяснения сути вопроса), то нужно ли для каждого диалога создавать по 2 очереди или хватит по 1 или вообще сделать просто 1 очередь? а сколько нужно обменников в этом случае? Вот есть у меня пользовательские подписки на события на серверах, стоит ли там юзать rabbit или лучше просто wss subscribe?



Последнее исправление: McLotos (всего исправлений: 1)

Если говорить о микросервисах, то пока понятно только то, что на 1 микросервис создаётся 1 подключение.

с чего ты так решил?

Сколько нужно обменников и нужны ли они вообще, если есть стандартные обменники? Как правильно выбрать тип обменника?

я бы делал кол-во обменников по кол-ву бизнесовых событий. Условно если у нас 2 сервиса которые срут каждый своим сообщением то у нас 2 обменника. Мы заводим обменник на каждый тип сообщений.

Пока думаю, что для каждого сервиса нужна только 1 очередь (даже если будет запущено 10 сервисов reports, то они все будут слушать очередь reports

не сервис, а событие может? ну типо очередь сообщений «по отчетам сверки баланса для сервиса информирования пользователя», очередь сообщений «о изменении статуса заявок для сервиса информирования пользователя» или т.п. итого уже 2 очереди для 1 сервиса по 2 событиям. ну тут и 2 обменника наверно будет чисто по логике.

routeId vs headers - какой вариант лучше использовать в какой ситуации и почему.

route-key может? ну там много нюансов, но я не сильно копал.

Noob_Linux ★★★★
()
Ответ на: комментарий от Noob_Linux

с чего ты так решил?

А зачем одному микросервису держать несколько подключений к rabbit?

Мы заводим обменник на каждый тип сообщений.

Понятно.

не сервис, а событие может?

Да, если ориентироваться на события, тогда всё логично, во всяком случае сильно понятнее чем то, о чем я думал.

Просто я вот думал совсем наоборот - раздавать задания через rabbit для сервисов. У меня с фронтом общается только gateway, он получает с фронта событие, шлет его в rabbit, а на фронт выдает заглушку типа «задача принята в работу». Дальше gateway сидит и слушает свою очередь gateway, а в неё через exchange сыпятся уведомления от всех сервисов, которые участвуют в формировании ответа пользователю. А когда все сервисы закончили работу и сформировали уже финальные ответы, gateway собирает все ответы в один response и шлёт его клиенту через wss.

McLotos
() автор топика

Твои вопросы относятся к архитектуре приложения, сомневаюсь, что ответы на них будут в доках по серверу очередей.

Почитай какие-нибудь книжки по архитектурным паттернам. Но тут есть нюанс. Оно всё тебе для чего?

ya-betmen ★★★★★
()
Ответ на: комментарий от McLotos

А зачем одному микросервису держать несколько подключений к rabbit?

ну все зависит от технологии на которой написан это (микро)сервис. Ну допусти у нас PHP и у тебя сервиси который молоти 1 очередь в 8 потоков. Вот у тебя уже и 8 подключений (по 1 на каждый консьюмер).

Просто я вот думал совсем наоборот - раздавать задания через rabbit для сервисов. У меня с фронтом общается только gateway, он получает с фронта событие, шлет его в rabbit, а на фронт выдает заглушку типа «задача принята в работу». Дальше gateway сидит и слушает свою очередь gateway, а в неё через exchange сыпятся уведомления от всех сервисов, которые участвуют в формировании ответа пользователю. А когда все сервисы закончили работу и сформировали уже финальные ответы, gateway собирает все ответы в один response и шлёт его клиенту через wss.

ну так вопрос то в чем? схема рабочая но свои нюансы конечно с надежностью есть. Задание это и есть тип сообщения 1 эксченж и роутинг на очереди по подтипу через route-key окей схема например.

Noob_Linux ★★★★
()
Ответ на: комментарий от ya-betmen

Твои вопросы относятся к архитектуре приложения, сомневаюсь, что ответы на них будут в доках по серверу очередей.

Да, как раз поэтому я и полез на форум - вся дока уже изучена вдоль и поперек =)

Почитай какие-нибудь книжки по архитектурным паттернам.

Уже в процессе

Но тут есть нюанс. Оно всё тебе для чего?

Декомпозирую многолетний монолит на пыхе, в который срали несколько лет и теперь там скрипты по 30 000 строк инлайна. Часть сервисов переписываю на ноду, часть оставлю на пыхе, что-то переедет на питон

McLotos
() автор топика
Ответ на: комментарий от Noob_Linux

схема рабочая но свои нюансы конечно с надежностью есть.

То есть схема будет примерно такая. 1 сервис gateway, который общается с фронтом и вебсокетами. Через кролика он общается с хреновой тучей сервисов. Получается, что gateway шлет свои запросы в fanout_exchange, а ответы сервисы шлют в gateway_exchange, а gateway забирает их через gateway_queue?

McLotos
() автор топика
Ответ на: комментарий от McLotos

А, тогда понятно.

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

Потом найти куски где нужна персистентность запроса/ответа и переделать их и т.д.

И под каждую ситуацию смотреть какие паттерны использовать, например в приведенном тобой случае возможно, что каждый отдельный кусок ответа можно сразу отсылать на клиента не дожидась всех данных. И либо показывать сразу либо ожидать всех и потом показывать.

ya-betmen ★★★★★
()
Ответ на: комментарий от ya-betmen

Я в программировании уже больше 15 лет. Я знаю к чему приводит чрезмерная увлеченность всякими нововведениями, но вот как раз TDD + DDD + EDA это сейчас как раз тот комплект, который нужен для текущего проекта =)

McLotos
() автор топика