Azure Inter-worker process communication

Я работаю над приложением приложения, которое было разработано для работы в среде, отличной от Azure. Один из элементов архитектуры - одноэлементный, который не масштабируется, и я надеюсь заменить w/несколько рабочих процессов, обслуживающих ресурс, который в настоящее время предоставляет singleton.Azure Inter-worker process communication

У меня есть необходимые изменения для замены синглтона, и я собираюсь построить инфраструктуру связи для обеспечения взаимодействия между серверами пользовательского интерфейса и ресурсами, и мне интересно, следует ли мне просто использовать привязку TCP на службе WCF или будет ли использование Azure Service Bus более разумным. TCP/WCF прост, но не решает полную проблему: как я могу гарантировать, что только один рабочий обрабатывает запрос пользовательского интерфейса?

Из прочтения доступной документации звучит так, что сервисная шина решит это, но я пока не вижу конкретного примера реализации. Я надеюсь, что кто-то здесь может помочь и/или указать мне в правильном направлении.

источник

2013-09-22 John Wollner

Кажется, что Azure Service Bus очереди - правильное решение для вас.

Azure Service Bus может использоваться в 3 различными способами:

Очереди
Темы
Реле

Из окон лазурного сайта:

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

Вы можете найти более подробную информацию по адресу: http://www.windowsazure.com/en-us/develop/net/fundamentals/hybrid-solutions/

источник

2013-09-22 19:39:47

Спасибо за указатель. Любые примеры реализации? –

@JohnWollner Здесь вы можете найти полный пример: http://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-queues/ –

@DavideIcardi Что делать, если я хочу получать ответ от службы, к которой я подключаюсь? Например, если я хочу отправить электронное письмо, связав сообщение с моей рабочей ролью MailSender, а затем получаю и отвечаю, что письмо было отправлено или нет (и описание ошибки). –

Добавление к ответу Давиде в.

Другим вариантом является использование Windows Azure Queues. Они предназначены для облегчения асинхронной связи между ролями сети и рабочих. С вашей веб-роли вы отправляете сообщения в очередь, которая определяется вашими рабочими ролями.

Ваша рабочая роль может "Get" одно или несколько сообщений из очереди и работать над этими сообщениями. Когда вы получаете сообщение из очереди, вы можете поручить службе очереди сделать эти сообщения невидимыми для других вызывающих абонентов на определенное время (известное как message visibility timeout). Это гарантирует, что только экземпляр рабочей роли будет работать над сообщением.

Как только рабочая роль завершила работу, она может просто удалить сообщение. Если при обработке сообщения произошла ошибка, сообщение автоматически появляется в очереди после истечения периода ожидания видимости. Вы можете найти эту ссылку полезной: http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/.

источник

2013-09-23 05:22:41

Очереди служебной шины обеспечивают более богатую семантику обмена сообщениями, чем лазурные очереди. См. Это для сравнения: http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx –

Я считал, что стоит очередь вверх, но я понимаю, что они ограничены полезной нагрузкой 8К, что почти не достаточно для моего приложения. –

8K ограничение был долгое время задний. Теперь это 64K - http://msdn.microsoft.com/en-us/library/windowsazure/dd179363.aspx. –

Очереди Azure не предназначены для взаимодействия между процессами, но между приложениями связи. Задержка доставки сообщений существенна, и сроки поставки не могут быть гарантированы. Websockets или NetTcpBinding более подходят для приложений, которые говорят друг с другом в режиме реального времени. Хотя вы должны признать, что вы получаете некоторые бесплатные вещи с queuez, особенно механизмы блокировки.Просто мои 2 цента

источник

2014-03-11 12:28:00

Azure Inter-worker process communication

ответ

Смежные вопросы