Уместно ли использовать очереди сообщений для синхронных вызовов RPC через AJAX
У меня есть веб-приложение, которое использует плагин автозаполнения jquery, который по сути отправляет через ajax запрос, содержащий текст, который был введен в текстовое поле на наш веб-сервер, и как только веб-сервер получает этот запрос, он затем передается rabbitmq.
Я знаю, что мы получаем выгоду от использования обмена сообщениями, но кажется, что использование его для блокировки вызовов rpc - это неправильное использование, и что-то вроде WCF гораздо более уместно в этом случае, так ли это, или это считается приемлемой архитектурой?
2 ответа
С помощью RabbitMQ можно выполнять синхронные запросы RPC. Здесь это объяснено очень хорошо, с его недостатком! Так что это считается приемлемой архитектурой. Не рекомендуется, но приемлемо, когда синхронный ответ является обязательным.
Как возможный обратный эффект, добавив RabbitMQ посередине, вы добавите задержку к решению.
Однако у вас есть возможность получить с точки зрения надежности, гибкости, масштабируемости,...
Какую пользу вы бы получили от этого? И если честно, если вы поместите сообщение в очередь, как это синхронно? разве тот же процесс, который поместил сообщение в очередь, удаляет его, но это в значительной степени бесполезно, нет?
Теперь, если все, что вы хотите сделать, это поместить сообщение в очередь и обработать его позже, это просто. Также тот факт, что у вас был WCF для смеси, является ИМХО признаком того, что что-то, возможно, недостаточно ясно. Вы можете использовать WCF в качестве шлюза API и использовать его для записи сообщения в очередь, так что на самом деле речь идет не о WCF или очередях, а скорее о синхронизации против асинхронности.
То, как вы высказываете свои идеи, не выглядит хорошо для меня.