Использование веб-приложений ASP.NET в качестве SignalR клиента

Question

Моя команда находится в середине решении архитектуру нашей серверной системы:

1. Вебсервер А представляет собой приложение ASP.NET MVC с ASP.NET Web API компонент, размещенный на веб-сайте Azure.
2. Служба Windows B является самообслуживаемым сервером OWIN, который будет периодически отправлять уведомления клиентам, которые подписываются на уведомление, размещенное на Azure VM.
3. Служба Windows C является клиентом, который подписывается на уведомление от B, размещенное на Azure VM.

Так как мы более или менее укоренились в .NET стека, мы реализовали В качестве SignalR сервера с С является клиент SignalR. Эта часть, похоже, работает хорошо.

Теперь наступает момент, когда мы также хотим, чтобы A подписалась на B, но я понимаю, что это означает, что веб-сервер ASP.NET будет действовать как SignalR CLIENT, вместо типичного сценария, где он действует как сервер SignalR.

Я предполагаю, что мы можем инициализировать соединение SignalR в Global.asax и сделать процесс вечным, чтобы избежать перезарядки AppDomain. Тем не менее, я чувствую себя немного неудобно, когда веб-сервер создан для выполнения чего-то другого, кроме обслуживания веб-запросов. Это решение также делает веб-сервер не апатридом, поскольку ему необходимо поддерживать соединение веб-сокета вживую.

Есть ли что-то принципиально неправильное при создании приложения ASP.NET a SignalR? Есть ли какая-нибудь возможность получить эту настройку?

Answer 1

В Azure вы не можете сказать, что ваш AppDomain не будет перерабатываться. Из-за многих причин он может перезапустить себя, чтобы исцелить, а затем вы получите новое соединение с сервером SingleR. Это тебя устраивает?

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