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