Использование SignalR в роли лазурного рабочего

У меня есть веб-приложение, поддерживающее Azure, которое работает рядом с несколькими экземплярами рабочей роли. В настоящее время веб-приложение передает работу этим работникам, помещая сообщения в очередь Azure для рабочих, чтобы забрать. Рабочие передают статус и обрабатывают сообщения назад, помещая сообщения в очередь "обратной связи". На данный момент, чтобы информировать клиентов моего браузера о прогрессе, я делаю периодические опросы на основе ajax в браузере методу контроллера MVC, который, в свою очередь, считывает очередь обратной связи Azure и возвращает эти сообщения как json обратно в браузер.

Очевидно, SignalR выглядит очень привлекательной альтернативой этому неуклюжим методу опроса/опроса, но я нашел очень мало рекомендаций относительно того, как это делать, когда мы говорим о нескольких ролях сотрудников (в отличие от роли в Интернете) необходимо отправить статус отдельным или всем клиентам.

SignalR.WindowsAzureServiceBus от Clemens vasters выглядит превосходно, но в конце остается немного высоким и сухим, т.е. недостатка хорошего примера.

Добавленный комментарий. Из моего чтения до сих пор кажется, что нет связи direct от роли рабочего (в отличие от веб-роли) клиенту браузера с помощью подхода SignalR, Кажется, что работники должны общаться с веб-ролью с помощью очередей. Это, в свою очередь, приводит к подходу к опросу, т.е. Очереди должны быть опрошены для сообщений от рабочих ролей. Этот опрос должен инициироваться (из него выведен) из браузера, который он отображает (как можно настроить петлю опроса в веб-роли?)

Таким образом, SignalR, даже с помощью метода SignalR.WindowsAzureServiceBus для масштабирования Clemens Vasters, не может обрабатывать прямую связь с ролью работника в браузере.

Любые комментарии экспертов будут оценены.

Ответы

Ответ 1

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

Ответ 2

Мы используем очереди службы Azure Service Bus для отправки данных в наши веб-роли SignalR, которые затем передаются клиентам. страницы CAT имеют очень хорошие примеры того, как настроить асинхронные циклы и отправку.

Ответ 3

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

Веб-роли могут подписываться на сервер очереди, где рабочая роль откладывает сообщение?. Если это так, клиент не будет "тянуть", служба очереди обеспечит код веб-сервера новым сообщением, а через SignalR вы будете нажимать изменения на клиент без участия клиентских запросов. Связь между сетью и работником осталась бы такой же (что, на мой взгляд, это правильный способ сделать это).

Ответ 4

Если вы используете одну из объединительных плат SignalR scaleout, вы можете заставить рабочих разговаривать с подключенными клиентами через ваше веб-приложение.

Как публиковать сообщения с помощью SignalR SqlMessageBus объясняет, как это сделать.

Он также ссылается на полностью обработанный пример, который демонстрирует один из способов сделать это.

Ответ 5

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