1

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

enter image description here

Изображение представляет свой выбор. Я создам две вещи (желательно на одном и том же базовом URL-адресе).
1. Веб-сайт (ASP.NET, MVC, скорее всего, питание от Razor)
2. Служба слой (guessingly WCF, так как там не так много еще, чтобы выбрать с сегодняшнего дня)

Итак, в моем наивном невежестве , Я добавил ASP.NET Web Role для первой и WCF Service Web Role для последнего. Затем, согласно подсказке, я также добавил «Роль рабочего». И вот где я смирился и начал подозревать, что мое невежество было скорее высокомерием ...

Нужны ли мне все трое? Или, может быть, так, что роль рабочего охватывает других? Или другие достаточны, и мне нужна роль рабочего? Или я совершенно путаю здесь понятия?

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

ответ

1

Ответ, это зависит ...

Веба роль является по существу работника роли с IIS установленной + настроенной. Вы могли бы разместить процессы WebApi/MVC, WCF и все события из одной и той же веб-роли, если вы действительно этого хотели, и сократить расходы.

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

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

НТН

+0

Возможно, глупый вопрос - что, если я намереваюсь запустить службу и веб-страницу ** без ** найма виртуальной машины? Мне все еще нужны рабочие? (Конечно, я понимаю, что в Azure есть виртуальная машина, но ** что, если я развертываю на веб-странице «thingy», я создал с помощью портала и работаю с созданной там БД? Разве это не позволило бы мне остаться «незнающим» VM и так?) –

+0

Вы могли бы использовать проект «веб-сайтов», а не облачные сервисы. Это еще больше абстрагирует виртуальную машину и не требует больших усилий для переноса на роли Web/Worker, если вам нужно в будущем. Если вы изучаете MVC или веб-материал в целом, лучше всего развернуть проект веб-сайтов на свободном уровне, пока вам не станет удобно. Тогда вы можете принять более обоснованное решение, когда у вас все будет в руках. –

+0

С веб-сайтами вы можете развернуть два приложения на один и тот же веб-сайт под другим URL-адресом и приложением на веб-сайте для каждого. Упрощает стоимость, если вам не нужны специализированные работники или веб-сайты для развертывания нескольких проектов или такого уровня изоляции. – ElvisLives

1

Там нет правильного ответа на сколько ролей использовать в облачной службе. Но важно точно понимать, что это за роли.

Добавление немного к @ ответ Петра: Каждая роль является определение из виртуальной машины (ее содержание) - думать об этом как шаблон VM . И для каждой роли (шаблона) вы должны иметь как минимум один экземпляр (VM). Если у вас есть одна роль, ваш минимальный размер будет одной виртуальной машиной (любого размера, указанного для этой роли). Если у вас три роли, у вас будет минимум 3 виртуальных машины.

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

+0

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