|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Привет коллеги. Почему соврменные JMS/MQ системы незаменимы? Является ли это хайпом или технолгическим витком? Почему мы не можем вместо них брать Dbms? Файловую систему? (я видел такие юзкейсы) Можно-ли вообще их исключить из стека технологий? И если исключить то как? Поделитесь вашим опытом. Особенно меня интересуют кейсы когда вы просто выбросили из задачи JMS/MQ и ничего не потеряли. Я долго думал над формулировкой темы топика но так и не придумал. Сначала хотел сравнивать Kafka-RabbitMQ в раздличных конфигурациях устойчивости к сбоям и к пропускной способности. Но задача сравнения в моем плане начала расти до таких космических масштабов что я понял что более-менее объективный сравнительный тест я написать не в состоянии. Тоесть я конечно могу взять любой синтетический бенчмарк. Но он ничего не будет стоить в реальном сетевом окружении. С нагрузкой. С шквальным (периодическим) характером движения сообщений. Со специфичными продуктовыми кейсами (например каждая веб-сессия создаёт подписки только в момент сеанса). Вобщем в конце концов я плюнул и решил что пускай будет обобщенная тема. И если разговор повернется в плоскость сравнения брокеров например HornetQ и ApacheMQ то мы конечно что-то придумаем как сравнить. Если вы в ПРОДЕ конфигурировали особые настройки сети и протоколов для брокера - то поделитесь этими настройками. Если вы знаете какой-то JMS-ный антипаттерн - то тоже прошу поделится. Спасибо всем. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2021, 21:20 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Я для обмена событиями между приложениями теперь использую REST и фиды вместо MQ. Ну, когда есть возможность. Мне очень понравилось. Работает так: 1. Система А хочет получать сообщения от Б 2. Б публикует фид событий которые у него происходят. Ну и ссылки на сущности которые поменялись этим событием. 3. А поллит фид раз в сколько-то секунд и если видит там неизвестные ранее события, то может пойти по ссылкам и скачать все нужные данные. 4. Для этого А должен хранить инфу о последнем считанном событии. Это может быть timestamp если не боимся двух одновременных событий, или ID события. Это очень удобно: а. Если что-то пошло не так, то фид и детали можно смотреть прям из браузера б. Если что-то пошло не так и система А не смогла сохранить/распарсить данные из Б, то эта же система А их потом и перезапросит после того как мы починили все. Т.е. не надо трогать команду Б чтоб те запустили заново событие. в. Не надо изучать/устанавливать доп компоненты (MQ brokers) Но конечно если нужно чтоб А мгновенно узнала о событии в Б, то прийдется все-таки чтоб Б как-то нотифицировала нуждающихся. Либо по тому же HTTP, либо по MQ. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 02:36 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev А поллит фид раз в сколько-то секунд Костыли. Можно было и вебсокет сколхозить раз уж на то пошло. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 04:43 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton Почему соврменные JMS/MQ системы незаменимы? С MQ удобно горизонтально масштабироваться. Выросла нагрузка? Добавил n инстансов (и не обязательно на один сервак). Надо под это затачивать систему, конечно. Можно делать и serverless, вкорячить какой-нибудь zeromq или сделать велик. mayton Является ли это хайпом или технолгическим витком? Это очередной технологический виток хайпа. mayton Почему мы не можем вместо них брать Dbms? Потому что у этих систем нет ничего общего. mayton Файловую систему? (я видел такие юзкейсы) Нужно сделать броадкаст на n сервесов, которые находятся на m серверах. Как это сделать через фс? Монтировать её на этих m серверах? Уровень костылизма зашкалил. mayton Можно-ли вообще их исключить из стека технологий? Не хочешь/нечего разделять на куски - не разделяешь, пилишь дальше свой монолит. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 04:57 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev Работает так: 1. Система А хочет получать сообщения от Б 2. Б публикует фид событий которые у него происходят. Ну и ссылки на сущности которые поменялись этим событием. 3. А поллит фид раз в сколько-то секунд и если видит там неизвестные ранее события, то может пойти по ссылкам и скачать все нужные данные. 4. Для этого А должен хранить инфу о последнем считанном событии. Это может быть timestamp если не боимся двух одновременных событий, или ID события. Это все делается штатными средствами rabbit'а, без изобретения великов. Stanislav Bashkyrtsev Это очень удобно: а. Если что-то пошло не так, то фид и детали можно смотреть прям из браузера Делаешь гейт, который тащит данные из рабита в браузер - profit. Stanislav Bashkyrtsev Если что-то пошло не так и система А не смогла сохранить/распарсить данные из Б, то эта же система А их потом и перезапросит после того как мы починили все. Если система что-то там не смогла, не делаешь подтверждение (ack) запроса, останавливаешь, чинишь, запускаешь заново. Stanislav Bashkyrtsev в. Не надо изучать/устанавливать доп компоненты (MQ brokers) Эпохальная проблема. Зто надо писать свой велик, как-то хранить и выбирать события на Б (т.е. нужна как минимум какая-то субд), которую все будут постоянно запрашивать. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 05:04 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton Привет коллеги. Является ли это хайпом или технолгическим витком? Чта?! Хайп MQ? Мне казалось, что хайп на MQ прошел лет 10 назад. Щас хайп это GraphQL и gRPC. Щас у нас на проекте активно избавляются от REST и переходят на GraphQL для фронта. А микросервисы между собой общаются по gRPC. Только где-то в уголке притаилась Kafka. <:o) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 06:37 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mad_nazgul, Ты прокололся. Ты сравнил асинхронные технологии и синхронные. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 07:06 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Велосипед. REST антипод Message Oriented Middleware ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 07:12 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton Почему соврменные JMS/MQ системы незаменимы? Является ли это хайпом или технолгическим витком? Потому что ТЕОРЕМА https://en.m.wikipedia.org/wiki/CAP_theorem ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 07:26 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mad_nazgul Щас у нас на проекте активно избавляются от REST и переходят на GraphQL для фронта. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 07:28 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
PetroNotC Sharp mad_nazgul, Ты прокололся. Ты сравнил асинхронные технологии и синхронные. Чта?! У нас gRPC в основном асинхронно работает. И graphQL тоже может асинхронно работать. Мы пока пишем синхронные запросы. Т.к. только тренируемся. Но в перспективе будем асинхронные делать. <:o) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 08:03 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
PetroNotC Sharp mad_nazgul Щас у нас на проекте активно избавляются от REST и переходят на GraphQL для фронта. Нет. Всё для удобства фронта. Чтобы они не делали 100500 запросов рест. Всё свести к нескольким запросам GraphQL. Т.к. он позволяет одним запросом обратиться к нескольким ендпоинтам. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 08:06 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mad_nazgul gRPC в основном асинхронно работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 08:38 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev Я для обмена событиями между приложениями теперь использую REST и фиды вместо MQ. Ну, когда есть возможность. Мне очень понравилось. Тут есть нюанс. Как мне кажется это удобно для взаимодействия двух систем. А если их более чем две. Тогда у нас может получится квадратичный рост ресурсов. И кроме того мне непонятно как с фидами поддержать FIFO? Будет ли отслеживаться хронология событий? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:02 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
crutchmasterКостыли.Нет, это не костыли, это вполне известное решение. Не я придумал. Есть спец форматы для фидов: RSS, Atom. Я с такими системами еще в 2009ом работал. crutchmasterМожно было и вебсокет сколхозить раз уж на то пошло.Ну смотря что ты тут имеешь в виду. Если то что система Б в вебсокет просто пишет события, то нет - нельзя было. Если система А может запрашивать по веб сокету фид и события, то да - можно было бы и с ним. crutchmasterЕсли система что-то там не смогла, не делаешь подтверждение (ack) запроса, останавливаешь, чинишь, запускаешь заново.Нет, Ack здесь не поможет. Потому как ты мог послать подтверждение (твоя система посчитала что все хорошо), сохранил данные, но неверно. С поллом все просто: починил, перезапросил данные, они перезаписались в БД. Главное чтоб это идемпотентная операция была. crutchmasterТут есть нюанс. Как мне кажется это удобно для взаимодействия двух систем. А если их более чем две. Тогда у нас может получится квадратичный рост ресурсов.Чем больше систем, тем меньше ресурсов в среднем мы тратим. Эти проблемы все решаются простым кешированием. В открытом вебе еще добавляют тротлинг. В вебе в принципе мы не работаем с MQ (во всяком случае я никогда не видел таких решений), я не уверен что MQ в принципе масштабируется до таких размеров и нагрузок. crutchmasterИ кроме того мне непонятно как с фидами поддержать FIFO? Будет ли отслеживаться хронология событий?Ну тут два варианта: 1. Наши события - эт не события, а просто сущности в БД отсортированные по дате модификации. Но тогда сущность может "прыгать" по фиду. Сначала она была в мартовском фиде, теперь в августовском. Это не требует доп таблиц. 2. Ну или заводим доп таблицу с событиями и записываем их в БД. Это в любом случае нередко удобно для аудитов и дебагинга. В общем как я уже и говорил - я с этим удачно работаю. Это оочень удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:17 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
PetroNotC Sharp mayton Почему соврменные JMS/MQ системы незаменимы? Является ли это хайпом или технолгическим витком? Потому что ТЕОРЕМА https://en.m.wikipedia.org/wiki/CAP_theorem Начало - хорошее. Но неполное. CAP применим в отношении одноранговых систем. Типа узлы кластера dbms. JMS/MQ системы - содержат узлы разного ранга. Потребители. Поставщики событий и брокеры. И как здесь уложить CAP - не совсем понятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:21 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
crutchmaster mayton Почему мы не можем вместо них брать Dbms? Потому что у этих систем нет ничего общего. Это может быть хорошим вопросом на собеседовании. Но нам нужен развернутый ответ. Если JMS/MQ брокер хранит события и предоставляет интерфейс для пуша и полла. И dbms также может хранить таблицу событий и также предоставлять аналогичные возможности - то нам надо подчеркнуть разницу. Так в чем-же разница? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:25 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mad_nazgul PetroNotC Sharp mad_nazgul, Ты прокололся. Ты сравнил асинхронные технологии и синхронные. Чта?! У нас gRPC в основном асинхронно работает. И graphQL тоже может асинхронно работать. Мы пока пишем синхронные запросы. Т.к. только тренируемся. Но в перспективе будем асинхронные делать. <:o) Асинхронность - это хорошо. Но безотносительно синхроннсти или асинхронности поставщик событий и потребитель встречаются в сети и присутсвуют единовременно. Без этого у вас не состоится коннект. В противоположность message broker позволяет событию (бизнес-событию!) существовать отдельно от обоих участников. Тоесть lifecycle такого бизнес-события более сложен чем просто асинхронизм. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:30 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton mad_nazgul пропущено... Чта?! У нас gRPC в основном асинхронно работает. И graphQL тоже может асинхронно работать. Мы пока пишем синхронные запросы. Т.к. только тренируемся. Но в перспективе будем асинхронные делать. <:o) Асинхронность - это хорошо. Но безотносительно синхроннсти или асинхронности поставщик событий и потребитель встречаются в сети и присутсвуют единовременно. Без этого у вас не состоится коннект. В противоположность message broker позволяет событию (бизнес-событию!) существовать отдельно от обоих участников. Тоесть lifecycle такого бизнес-события более сложен чем просто асинхронизм. Так что альтернатива только почта и ямщики на лошадях ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:32 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton Но нам нужен развернутый ответ. Ты и сам знаешь что субд централизована. А сабж распределенные информ системы и бд ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:35 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
PetroNotC Sharp mayton Но нам нужен развернутый ответ. Ты и сам знаешь что субд централизована. А сабж распределенные информ системы и бд Нет. СУБД тоже могут лежать на других уровнях CAP. Посмотри как работает Apache Cassandra. Это СУБД но она не связана обязательством C<->A. Посмотри как работает DynamoDb, Apache Ignite. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:47 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev Нет, это не костыли, это вполне известное решение. Костыльное решение. Для rss это как-то и оправдано, для сообщений - ну так себе. Вот мы тут на форуме сидим и тычим F5. Удобно? Stanislav Bashkyrtsev Ну смотря что ты тут имеешь в виду. Что бы А не дрочило Б запросами раз в n секунд, а событие передавалось тогда, когда оно произошло. Stanislav Bashkyrtsev Нет, Ack здесь не поможет. Ну да, так надо перезапрашивать. Но так не понятно причём тут вообще какое-то mq, если всё завязано на логи запросов и они там кому-то нужны потом целый год. Это всё равно, что финансовые транзакции пытаться с mq хранить. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:49 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev Нет, это не костыли, это вполне известное решение. Не я придумал. Есть спец форматы для фидов: RSS, Atom. Я с такими системами еще в 2009ом работал. Я признаться... про RSS мало знаю. Я считал что это просто статичный файл который сам браузер периодически poll-ает и таким образом узнает о линках на новые события. Я не прав? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:50 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton Я признаться... про RSS мало знаю. Например rss новых тем на форуме (которое работает через одно место). Браузер тыркает форумом запросами, форум иногда его обновляет. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:52 |
|
Зачем мы вообще используем JMS/MQ системы? (четверговый топик)
|
|||
---|---|---|---|
#18+
mayton PetroNotC Sharp пропущено... проект пишу. Некогда лекции писать. Ты и сам знаешь что субд централизована. А сабж распределенные информ системы и бд Нет. СУБД тоже могут лежать на других уровнях CAP. Посмотри как работает Apache Cassandra. Это СУБД но она не связана обязательством C<->A. Посмотри как работает DynamoDb, Apache Ignite. - у решения Клиен-сервер двухзвенка есть СУБД - у решения Message-oriented middleware тоже есть для сообщений своя бд внутри. Ты не понял разницы? Она в каждом из трех слов архитектуры ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 11:56 |
|
|
start [/forum/topic.php?fid=59&fpage=3&tid=2120331]: |
0ms |
get settings: |
18ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
113ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
520ms |
get tp. blocked users: |
2ms |
others: | 375ms |
total: | 1063ms |
0 / 0 |