Имею стек:
1. Визуальная часть чата написана на Vue (Browser, приём и отправка сообщений)
2. Поднял очередь сообщений (RabbitMQ)
3. Бот (NodeJS) он будет принимать и отправлять сообщения.
4. php, mysql (где-то же я должен хранить месседжи)
Так вот, RabbitMQ не совсем про браузер.
Правильно я понимаю, что мне нужно поднять отдельно ноду для ретрансляции из браузера в Node (Например) ===> RabbitMQ?
Да, серверная логика должна присутствовать. А очереди используются в чатах тогда когда у тебя больше одного сервера. И реляционные базы для чатов не применяются
Игорь, Да все можно. Просто при росте чата MySQL масштабировать тяжелее чем просто добавить очередей. Данные они всегда добавляют трудностей. А что до очередей то там еще вопрос какой брокер использовать.
Под организацией очередей я подразумеваю, что это правильная хронология доставки сообщений.
Стоит почитать про exact-one-delivery, at-least-one-delivery и at-most-one-delivery и узнать что:
с очередями будут другие проблемы
хронологию сообщений они тоже не то чтобы рекомендуют, особенно в случаях сбоев, задержек, нескольких параллельных воркерах
но кто я такой чтобы отказывать в этом)
гарантия порядка обработки есть только в определенных жестких условиях в стриминге. Это Кафка.
подтверждение доставки
это делается в принципе на системе событий (читать про Event Sourcing). И опять же, очереди тут не при чем, но опять-же кто я такой чтобы отговаривать)
В чем точно помогут очереди:
проще будет мониторить поток событий/сообщений
проще будет настраивать роутинг
будет меньше кода
еще одна точка отказа. Очереди имеет разные алгоритмы acknowledgement, а также имеют свойства терять сообщения. В кролике я с этим сталкивался даже с одной нодой. Хотя случай и не частый, да.
могу разве что посоветовать до кучи открыть на ютубе тонны разных вариантов архитектур чатов и выбрать что-то для себя
Игорь, это не так работает) архитектура строится под конкретные требования с небольшим запасом прочности. Любая архитектура "на рост" переходит в категорию evolution architecture, создается долгое время и за довольно большие деньги.
Также
Что-то среднее между простым и высоко нагруженным чатом.
Ближе к простому.
Не является конкретным требованием, а лишь субъективным мнением. С таким подходом нельзя строить архитектуру.
Для понимания. Только сейчас в голове я вспомнил десяток разных архитектур с чатов, которые я могу превратить еще в сотню при некоторых изменениях.
Сейчас бы любое решение, которое отдалённо походит на чат.
Стек:
Vue
Symfony 5
MySQL 8
NodeJS
Тут как бы чат с боку, но и одновременно является основной идеей вокруг чего строится приложение.
Я в самом начале сделал простой чат с использованием SSE, но потом понял какую хрень, сделал.
Сообщения должны храниться в MySQL так как требуется дальнейший анализ.
Игорь, ну так и перестать заниматься фигней. есть nodejs, есть прекрасный протокол вебсокетов, которым учиться и не долго, либо grpc (но тут придется узнавать что такое http2 и как это все работает). Не знаю каким образом в этом всем Симфони образовалась, но это личное дело каждого. MySQL на первое время сгодится, но если это бизнес то нет - в помойку сразу
Игорь, диаграмма не верна и ужасна) стоит почитать хотябы про Layered Diahram, а лучше про C4 Model. Код - последнее что вас должно волновать. Ну и синхронизации между базами не должно быть. Я устал это всем объяснять уже. Если у вас не Warehouse то ни в коем случае
Игорь, хорошую диаграмму можно легко прочитать и понять. Здесь же каша и ничего непонятно.
Также:
диаграмма которая должна отражать бизнес процессы.
Ни одного бизнес-процесса не обнаружено. Я описываю бизнес-процессы и знаю из чего они состоят. Мимо. Более того, на одной диаграмме бесполезно указывать более одного бизнес-процесса.
Каждый узел это микро сервис
Сервисы не участвуют в бизнес-процессах. Более того в микросервисной архитектуре база данных является частью микросервиса, а шаринг данных между базами данных запрещён.
Ещё раз, я стараюсь мягко выражать мысли. Эта диаграмма бесполезна
Простой
