Я для обмена событиями между приложениями теперь использую REST и фиды вместо MQ. Ну, когда есть возможность. Мне очень понравилось.

Работает так:
1. Система А хочет получать сообщения от Б
2. Б публикует фид событий которые у него происходят. Ну и ссылки на сущности которые поменялись этим событием.
3. А поллит фид раз в сколько-то секунд и если видит там неизвестные ранее события, то может пойти по ссылкам и скачать все нужные данные.
4. Для этого А должен хранить инфу о последнем считанном событии. Это может быть timestamp если не боимся двух одновременных событий, или ID события.

Это очень удобно:
а. Если что-то пошло не так, то фид и детали можно смотреть прям из браузера
б. Если что-то пошло не так и система А не смогла сохранить/распарсить данные из Б, то эта же система А их потом и перезапросит после того как мы починили все. Т.е. не надо трогать команду Б чтоб те запустили заново событие.
в. Не надо изучать/устанавливать доп компоненты (MQ brokers)

Но конечно если нужно чтоб А мгновенно узнала о событии в Б, то прийдется все-таки чтоб Б как-то нотифицировала нуждающихся. Либо по тому же HTTP, либо по MQ.

crutchmasterКостыли.Нет, это не костыли, это вполне известное решение. Не я придумал. Есть спец форматы для фидов: RSS, Atom. Я с такими системами еще в 2009ом работал.
crutchmasterМожно было и вебсокет сколхозить раз уж на то пошло.Ну смотря что ты тут имеешь в виду. Если то что система Б в вебсокет просто пишет события, то нет - нельзя было. Если система А может запрашивать по веб сокету фид и события, то да - можно было бы и с ним.
crutchmasterЕсли система что-то там не смогла, не делаешь подтверждение (ack) запроса, останавливаешь, чинишь, запускаешь заново.Нет, Ack здесь не поможет. Потому как ты мог послать подтверждение (твоя система посчитала что все хорошо), сохранил данные, но неверно. С поллом все просто: починил, перезапросил данные, они перезаписались в БД. Главное чтоб это идемпотентная операция была.
crutchmasterТут есть нюанс. Как мне кажется это удобно для взаимодействия двух систем. А если их более чем две.
Тогда у нас может получится квадратичный рост ресурсов.Чем больше систем, тем меньше ресурсов в среднем мы тратим. Эти проблемы все решаются простым кешированием. В открытом вебе еще добавляют тротлинг. В вебе в принципе мы не работаем с MQ (во всяком случае я никогда не видел таких решений), я не уверен что MQ в принципе масштабируется до таких размеров и нагрузок.

crutchmasterИ кроме того мне непонятно как с фидами поддержать FIFO? Будет ли отслеживаться хронология событий?Ну тут два варианта:
1. Наши события - эт не события, а просто сущности в БД отсортированные по дате модификации. Но тогда сущность может "прыгать" по фиду. Сначала она была в мартовском фиде, теперь в августовском. Это не требует доп таблиц.
2. Ну или заводим доп таблицу с событиями и записываем их в БД. Это в любом случае нередко удобно для аудитов и дебагинга.

В общем как я уже и говорил - я с этим удачно работаю. Это оочень удобно.

Ну чем жесче требования, тем больше прийдется делать. В моем случае прыгающие сущности были норм потому как клиент идемпотентент и ему норм забрать одни и те же изменения два раза. Если это не устраивает, то прийдется создавать таблицу событий.
maytonНо я честно говоря не совсем понимаю какого рода сервис вы предоставляете?
Возможно сервис фидов это не совсем MQ. Это скорее ... SNAPSHOT сервис
где нам предлагается самим собрать последние новости.

Верно ли я понял? И можете привести пример такого ответа от вашего фид-сервиса.
Ну например я захотел фид по ценам на акции it-компаний.В моем случае Системой А пользуется один отдел, он сабмитит данные в Систему Б которой пользуется другой отдел. После того как Отдел Б закончил с заявкой, мы хотим результаты увидеть в Системе А. И вот Система А поллит события и забирает данные. И пользователь из Отдела А видит результаты на UI.

Если быть более конкретными: Отдел А - это химики которые синтезировали вещества, а Отдел Б - это химики которые очищают результат и получают чистый продукт. Система А соответственно сабмитить какие молекулы мы ожидаем, плюс предпочтения по очистке, а Система Б - регистрирует результат очистки (это картинки плюс данные), мол, сколько там получилось, какая чистота, регистрационный номер.

Мне кажется здесь люди не очень понимают программерскую терминологию.. Или просто хочется кинуть камнем, но не умеючи - не выходит :) Велосипед - это создание чего-то, что уже существует. Как в случае собсно велосипеда, который изобретали два раза.

Оповещения о событиях решаться может двумя способами:
- Асинхронно (MQ) - низкий latency, но хуже с масштабируемостью и сложней дебаг
- Синхронно (polling) - высокий latency (хотя это можно обойти добавив таки немного асинхронности), лучше с масштабируемостью (если допустимы кэши), проще дебаг

Это не требование - это результат асинхронной архитектуры.

Сам я с Kafka не работал, но в моем понимании это MQ. Хотя судя по всему она позволяет подписчикам откатывать свой оффсет как в случае фидов. Ну и весь топик можно хранить бесконечно, т.е. это аналог таблицы событий в БД. Веб UI к ней тоже можно подключить.

В общем может быть и можно подобное с помощью Kafka сделать без потери в функциональности. Останутся скорей всего такие проблемы:
- Масштабируемость - потому как она вряд ли будет кэшировать ответ подписчику? Но мне не приходится обычно писать что-то высоконагруженное с большим кол-вом подписчиков, поэтому это я переживу :)
- Лишний компонент который нужно хорошо изучить
- Ну и это доп компонент который прийдется деплоить, поддерживать, бэкапить и пр.
- И я еще не понял что делать если сама кафка лежит и наше приложение не может запаблишить событие. А из БД не обязательно это событие можно будет восстановить. Да и давать возможность кафке читать базу и писать код для вычленения всех типов событий, хм..

Пока я не убежден на 100% что она правда не привнесет больше хлопот чем решит проблем. Но как минимум надо будет дать шанс.

Не, тут все легко решается постраничным выводом. Это не проблема.