Лучший способ связи между приложением ASP.NET и рабочей ролью

Как указано выше, требуется немного больше контекста. По сути, у вас есть два основных варианта: очереди Windows Azure и очереди/темы служебной шины Windows Azure. Мой личный совет — использовать очереди Azure, если веб-роли и рабочие роли расположены в одном регионе, и очереди служебной шины, если это не так. Я должен спросить, почему вы не размещаете свои веб-роли и рабочие роли вместе, если у вас есть географическое развертывание вашего приложения, тогда посмотрите на развертывание всех ваших веб-ролей и рабочих ролей в каждом регионе, например. США, Европа и Азия, а затем используйте Диспетчер трафика, чтобы направить пользователя в оптимальный регион.

В блоге есть хорошая запись о том, когда какую очередь использовать «Очереди Windows Azure и очереди служебной шины Windows Azure — сравнение и сопоставление»: http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx

ХТН

ИЗМЕНИТЬ

Ниже приведен хороший подход к общению между веб-ролями и рабочими ролями (я украл это из недавней темы, на которую ответил @smarx)

1 Веб-роль записывает в очередь сообщение, содержащее идентификатор задания.

2 Рабочая роль выполняет работу и записывает результат в таблицу с ключом раздела.

3 Веб-роль опрашивает эту строку таблицы. Как только он существует, ответ возвращается.

В вашем случае вы могли бы сделать так, чтобы рабочая роль обновляла хранилище таблиц обновлениями статуса, а затем ваша веб-роль собирала их и отображала для пользователя. например 20%, 50%, полный и т.д...

Я действительно не вижу задержек в этом типе связи, если вы достаточно опрашиваете из веб-роли (* обратите внимание на затраты на транзакции)

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

http://msdn.microsoft.com/en-us/library/windowsazure/hh180158.aspx

Я рекомендую взглянуть на CQRS, что означает разделение ответственности за запросы команд.

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

http://cqrsjourney.github.com/

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

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

Подход использует такие понятия, как команды, запросы, объекты домена. CQRS становится чрезвычайно мощным способом достижения целей, которые, как мне кажется, вы ищете.

Поисковая система может дать вам много хороших ресурсов. Вот несколько полезных видео: Грег Янг http://www.youtube.com/watch?v=KXqrBySgX-s Мой друг Ринат http://www.youtube.com/watch?v=CnvO_nlvrps

Удачи!

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

Файл Global.asax.cs:

private static System.Timers.Timer _timer;

protected void Application_Start()
{
     //Start the timer job
     _timer = new System.Timers.Timer(3000);
     _timer.Elapsed += new ElapsedEventHandler(WebRoleTimerJob);
     _timer.Start();
}


/// <summary>
/// This event will be fired intervally every 3 seconds to broadcast messsage to all registered client pages using SignalR
/// </summary>        
public static void WebRoleTimerJob(object sender, ElapsedEventArgs e)
{               
      // Here, you can read Azure table storage to detect any changes    
      // or notification from Worker role
      // ....

      //If there is any changes, then broadcast message 
      // to all relevant client pages using SignalR   

      var context = GlobalHost.ConnectionManager.GetHubContext<Hub>();       
      context.Clients.All.addNewMessageToPage("your_message_name", "message_content");
}