Может ли приложение ASP.NET обрабатывать события NServiceBus?

Question

Большинство, если не все примеры NSB для ASP.NET (или MVC) имеют веб-приложение, отправляющее сообщение с использованием Bus.Send и, возможно, регистрацию для простого обратного вызова, что по сути является тем, как я использую его в своем приложении.

Что мне интересно, если это возможно и/или имеет смысл для дескрипторов сообщений в том же приложении ASP.NET.

Основная причина, по которой я прошу, это caching. Процесс может выглядеть примерно так:

1. Пользователь инициирует запрос из веб-приложения.
2. Веб-приложение отправляет сообщение на автономный сервер приложений и регистрирует изменение в локальной базе данных.
3. В будущих запросах страницы от одного и того же пользователя веб-приложение знает об изменениях и перечисляет их в состоянии ожидания.
4. На заднем конце происходит куча вещей, и в конце концов заявки принимаются или отклоняются. Событие публикуется с ссылкой на исходный запрос.
5. На данный момент веб-приложение должно начать отображение самой последней информации.

Теперь, в реальном веб-приложении, почти уверен, что этот ожидающий запрос будет кэшироваться, возможно, в течение длительного периода времени, потому что в противном случае приложение должно запрашивать базу данных для ожидающих изменений каждый раз, когда пользователь запрашивает текущую информацию.

Таким образом, когда запрос, наконец, завершается в фоновом режиме, что может занять минуту или день, веб-приложение, как минимум, должно аннулировать эту запись кэша и выполнять другой поиск в БД.

Теперь я понимаю, что с этим можно управлять с помощью объектов SqlDependency и т. Д., Но предположим, что они недоступны - возможно, это не серверный сервер SQL Server, или, возможно, запрос текущей информации относится к веб-службе , без разницы. Вопрос в том, как веб-приложение стало известно об изменении статуса?

Если is можно обрабатывать сообщения NServiceBus в приложении ASP.NET, каков контекст обработчика? Другими словами, контейнеру IoC придется вводить кучу зависимостей, но каков их объем? Выполняется ли это все в контексте HTTP-запроса? Или все должно быть static/singleton для обработчика сообщений?

Есть ли лучший/рекомендуемый подход к этому типу проблем?

Answer 1

Конечная точка (NSB) может быть создана для подписки на опубликованное событие и обновления кеша. Мероприятие не должно публиковаться до тех пор, пока не будет сделано фактическое обновление, чтобы вы не синхронизировались. Веб-приложение будет продолжать извлекать данные из кеша при следующем запросе, или вы можете построить какую-то задержку.

Answer 2

Я сам тоже задавался вопросом - какой подходящий уровень сцепления для веб-приложения с инфраструктурой NServiceBus? В моем домене у меня есть аналогичная проблема для решения проблемы использования SignalR вместо кеша. Как и вы, я не нашел много документации об этом конкретном шаблоне. Тем не менее, я думаю, что можно объяснить некоторые из последствий следования за ним, а затем решить, имеет ли это смысл в вашей среде.

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

1. Соответствующий вопрос, который необходимо задать, относится к вашей реализации кеша. Если это распределенная или централизованная модель (думаю, SQL, MongoDB, Memcached и т. Д.), То подход, который @Adam Fyles предлагает, звучит как хорошая идея. Вы не должны нуждаться в, чтобы уведомить каждое веб-приложение - обновление кеша может быть выполнено с помощью одной конечной точки NServiceBus, которая составляет , а не часть вашего веб-приложения. Другими словами, каждый экземпляр вашего веб-приложения и конечная точка «кеш-обновление» будут обращаться к одному и тому же общему кэшу. Однако, если ваш кеш находится в процессе, как, например, веб-кэш Microsoft, то, конечно, вам остается решать гораздо более сложную задачу, если вы не можете опираться на Eventual Consistency, как было предложено.
2. Если ваше веб-приложение подписывается на конкретное событие NServiceBus, вам будет необходимо иметь уникальную очередь ввода для каждого экземпляра вашего веб-приложения. Поскольку лучше всего учитывать масштабирование вашего веб-приложения с помощью балансировщика нагрузки, это означает, что вы можете получить N очередей и, по крайней мере, N подписки, что больше беспокоит, чем постоянное количество подписки. Опять же, не технический дорожный блок, просто что-то, что заставит меня поднять бровь.
3. Статья, связанная с Дэвидом Бойке, вызывает интересную мысль о пулах приложений и о том, как их жизнь может быть неопределенной. Кроме того, если у вас есть несколько пулов приложений, работающих одновременно для одного и того же приложения на сервере (общий сценарий), все они будут пытаться читать из одной очереди сообщений, и нет хорошего способа определить, какой из них будет обрабатывать сообщение , Больше, чем нет, это будет иметь значение. Отправка команд, напротив, не требует очереди ввода в соответствии с this post by Udi Dahan. Вот почему я думаю, что односторонние команды, отправленные веб-приложениями, гораздо чаще встречаются на практике.
4. Здесь можно многое сказать о принципе единой ответственности. В общем, я бы сказал, что если вы можете как можно больше делегировать «экспертизу» отправки и получения сообщений в NServiceBus Host, ваша общая архитектура будет более чистой и управляемой. По опыту я обнаружил, что если я рассматриваю свою веб-ферму как единую сущность, то есть отменяю все подтверждения индивидуального идентификатора веб-сервера, на которые я, как правило, меньше беспокоиться. Если каждый веб-сервер будет конечной точкой в ​​шинах, это означает, что теперь «какой сервер» снова появляется в виде очередей сообщений.

Это помогает прояснить ситуацию?