Комментарии 13
Угу, тоже было ощущение, что немного костыльное решение. А что за взаимодействие с тикетами, не подбросите ссылку для вдумчивого самостоятельного чтения, пожалуйста?
Ну наверное отправляется запрос на который создаётся тикет к которой привязывается какая нить бекграунд задача, уникальный номер тикета возвращается клиенту моментально, и клиент в свою очередь ждёт пока бекграунд таска выполняться и сможет вернуть результат. Клиент по уникальному ид тикета на запрос /poll эндпоинта как раз это и проверяет, готов результат или нет.
не смог убедить что это ерунда и так делать не надо
Я видел проект где абсолютно все вызовы через очередь (RabbitMQ + MassTransit) были сделаны по паттерну "request/response". Объяснить людям: "А, дескать, зачем вам вообще нужны очереди если вы все равно через них все синхронно вызываете?" было совершенно нереально.
end-point, в свою очередь, будет принимать обычную строку, отправлять её второму сервису и ждать от него ответа в Kafka.
омг зачем? звучит как "создаем проблему на ровном месте и героически ее превозмогаем".
Данная статья это просто демонстрация решения. В целом задачи бывают разные, и иногда данное решение необходимо. В нашем случае было сделано именно так, потому что по REST отдавали "легкие данные" для фильтрации, а получали "тяжелые" данные в кафку, поэтому и было использовано такое решение.
Ничего подобного в интренете не нашел. REST и KAFKA можно заменить на что угодно, самая главная идея статьи это показать, как мы можем перейти из плоскости "ассинхронное взаимодействие" в "синхронное".
Ничего не нашли наверное потому, что это какое то извращение, уж простите за откровение. Незнаю что значит "тяжёлые" данные, но могу предположить что это их размер и если так то вы наверное вкурсе что в кафку сообщения больше одного метра складывать нельзя, так как она начинает жутко тормозить.
В спринге есть ReplyingKafkaTemplate
Такое бывает если есть легаси система, у которой только асинхронный интерфейс, а потребителю нужен синхронный, тогда и появляется такой адаптер - sync 2 async
Есть ещё один вариант использования схемы rest<=>kafka.
Например, когда инстансы имеют некий высонагруженный и очень большой (сотни гигабайт) кеш, обновляемый, к примеру, через консюмер Кафки по ключу сообщения. В результате мы имеем этот большой кеш размазанный по всем инстансам.
Подход rest<=> kafka в данном случае позволит использовать тот же ключ в сообщении к Кафке, чтобы запрос был обработан именно тем инстансом, где этот кеш точно есть.
Такой подход позволит снизить до нуля обновление кеша из БД, к примеру. БД будет работать только при прогреве инстанса.
Доброго дня! А можно ли какуюто схему неольшую добавить в статью, чтобы лучше понять порядок вызова сервисов? Хоть sequence диаграмму, например...
А почему бы не использовать пакет какаренси, а конкретно java.util.concurrent.Exchanger<T>?
Синхронизируем через эксченжер поток запроса в кафку и поток получения ответа, на событии обмена лиснер кафки отдает сообщение (естессно через мапу все это дело, как в примере), а сендер, ожидающий ответ, отдает ничего. Насколько я помню там и таймауты настраиваются легко. Что-то подобное было, но с очередями веблоджика, хотя смысл от реализации асинхронного транспорта не меняется.
Синхронный «запрос-ответ» с использованием REST и Apache Kafka