Структурирование решения Azure с несколькими ролями

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

В моем конкретном случае у нас есть веб-роль, на которой размещается веб-приложение и API. Это меняется быстро, иногда по нескольку раз в день. У нас также есть несколько разных рабочих ролей для таких задач, как обработка видео, отправка электронной почты и отчетность/аналитика. Рабочие меняются редко, иногда реже, чем раз в месяц. У нас все это работает в одной подписке. Каждая роль находится в собственной размещенной службе.

Эта настройка позволяет нам легко развернуть одну роль, не затрагивая другие. Это также позволяет избежать ненужного прерывания рабочих ролей, поскольку они иногда находятся в середине длительных (10+ минут) заданий по обработке, которые необходимо перезапустить.

Так как вы, ребята, это делаете?

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


azure azure-web-roles azure-worker-roles
person Brian Reischl    schedule 11.06.2012    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Это немного мнение, но я думаю, что вы имеете на него право. Развертывание одного пакета для всех ролей, безусловно, дает преимущества (атомарные обновления, управление версиями и т. д.). Однако в более сложных сценариях я обнаружил, что разделение на разные развертывания и размещенные службы работает хорошо. Если вам нужна геоизбыточность, вам все равно придется иметь разные развертывания.

Если вы будете осторожны с управлением версиями (при условии, что ваши развертывания взаимодействуют друг с другом), вы можете легко иметь разные развертывания и получать преимущества более быстрого развертывания. Мы обнаружили, что наши рабочие роли имеют гораздо более высокий коэффициент развертывания, чем наши веб-роли, поэтому имеет смысл разделить веб-роли. С новой функцией Windows Azure для веб-сайтов мы серьезно рассматриваем возможность их еще большего разделения и простого запуска веб-части нашего приложения из нее. Наш API может пойти туда или даже развернуться в других выделенных экземплярах.

Единственное, что мы не сделали, так это не разделили подписки. Я не думаю, что есть техническая причина для этого. Может быть бизнес, чтобы обойти квоты, но реальность такова, что подписка не имеет такого большого значения. Однако позже это может стать настоящей проблемой, если вы используете Mgmt API для использования разных идентификаторов подписки для разных размещенных сервисов. Я бы также не стал смешивать и сопоставлять службы хранения и хостинга из разных подписок для целей управления. Вероятно, это хорошая идея, чтобы держать все это в одном сабвуфере.

person dunnry    schedule 11.06.2012
comment
Я просил мнения, так что спасибо за ваше! Я определенно согласен с тем, что не нужно разделять подписки. Мы случайно закончили тем, что сделали это на раннем этапе, и это было больно. К сожалению, исправить эту ошибку очень сложно, так как нет возможности перемещать хранилище данных между подписками. - person Brian Reischl; 11.06.2012