У меня есть размещенное в Azure веб-приложение, которое работает вместе с несколькими экземплярами рабочей роли. В настоящее время веб-приложение передает работу этим работникам, помещая сообщения в очередь Azure, чтобы они могли их забрать. Рабочие передают сообщения о состоянии и прогрессе обратно, помещая сообщения в очередь «обратной связи». В настоящее время, чтобы информировать клиентов моего браузера о ходе работы, я выполняю периодические опросы на основе ajax в браузере для метода контроллера MVC, который, в свою очередь, читает очередь «обратной связи» Azure и возвращает эти сообщения в виде json обратно в браузер. .
Очевидно, что SignalR выглядит очень привлекательной альтернативой этому неуклюжему подходу к опросу / очереди, но я нашел очень мало рекомендаций о том, как это делать, когда мы говорим о нескольких рабочих ролях (в отличие от веб-роли) необходимо отправить статус отдельным или всем клиентам.
SignalR.WindowsAzureServiceBus от Clemens vasters выглядит превосходно, но оставляет его немного высоким и сухим в конце, т.е. отсутствует хороший пример решения.
Добавлен комментарий : Из моего чтения до сих пор кажется, что нет прямой связи от работника роли (в отличие от сети роли ) к клиенту браузера через подход SignalR возможно. Кажется, что работники должны общаться с веб-ролью, используя очереди. Это, в свою очередь, заставляет подход опроса, то есть очереди должны быть опрошены для сообщений от рабочих ролей - этот опрос должен исходить (извлекаться из) из браузера, в котором он появляется (как можно настроить цикл опроса в веб-роли?)
Таким образом, SignalR, , даже если SignalR.WindowsAzureServiceBus масштабирует подход Clemens Vasters, не может обрабатывать прямую связь от рабочей роли к браузеру.
Любые комментарии экспертов приветствуются.