1

Я собираюсь переместить свой сайт, базу данных и фоновый планировщик на платформу Azure.Можем ли мы иметь роль рабочего и веб-роли в одном экземпляре Azure Cloud Services

Я должен использовать облачные сервисы с помощью сети & Рабочая роль. Теперь мой вопрос в том, что мне нужны отдельные экземпляры для каждого типа роли, или один экземпляр способен размещать несколько типов роли?

+0

Вот аналогичный вопрос http://stackoverflow.com/q/6266560/57428 – sharptooth

ответ

3

У вас не может быть объединенный экземпляр роли веб-и рабочей группы. Это может быть одно или другое. Тем не менее, возможно, что роль в Интернете выполняет фоновая обработка, поэтому она может размещать фоновую нагрузку.

Смотрите этот вопрос SO пару вариантов

Azure WebRole Scheduled Task Every Morning

Это говорит о запуске задачи каждое утро. Очевидно, вы можете делать это чаще, в зависимости от вашего приложения.

Помните об ограничениях на масштабируемость этого. Как только ваш трафик начнет расти, будет иметь смысл разбить его на отдельные роли в сети и рабочих.

Фактически, даже если фоновая рабочая нагрузка светлая, вам все же может быть разумнее перейти от отдельной архитектуры с самого начала и использовать экземпляры XS для фоновой обработки.

+0

Спасибо. Был еще один пост, который подробно разъяснил это. http://stackoverflow.com/questions/3582598/how-many-roles-can-you-have-per-azure-instance?rq=1 –

2

Технически вы не можете играть роль обоих типов. Тем не менее, веб-роль такая же, как и роль рабочего, она просто настроена на IIS. Таким образом, вы можете объединить их в одну веб-роль - IIS будет запускаться в отдельном процессе, а точка ввода роли Run() будет запускать бесконечный цикл для обработки «бэкэнд». См. this similar question.

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

Похоже, что когда вы объедините две роли в одну, вы больше не сможете их масштабировать. В большинстве случаев это не так - вам просто нужно изменить показатели.

Например, вы хотели запустить один экземпляр веб-роли для каждой тысячи HTTP-запросов в минуту и ​​один экземпляр рабочей роли для каждых десяти запросов в промежуточной очереди. Хорошо, это означает, что каждая тысяча HTTP-запросов нуждается в том же объеме обработки, что и десять элементов в промежуточной очереди. Таким образом, вы создаете новую метрику, которая принимает оба параметра и выводит несколько экземпляров. Например, у вас есть пять тысяч запросов в минуту и ​​двадцать запросов в очереди бэкэнда - вам нужно семь экземпляров объединенной роли.

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