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

Question

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

Мне интересно, возможно ли и / или имеет ли смысл обрабатывать сообщений в одном и том же приложении ASP.NET.

Основная причина, по которой я спрашиваю, - кеширование . Процесс может идти примерно так:

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

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

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

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

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

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

Answer 1

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

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

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

Помогает ли это уточнить?

Answer 2

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