Я изучаю реструктуризацию приложения, над которым я работаю, чтобы найти способ сократить расходы и предоставить нам гораздо больше возможностей для масштабируемости. По сути, приложение в настоящее время размещено на Azure как одно крупное веб-приложение, в которое пользователи могут войти в систему, выполнить некоторые вычислительно дорогостоящие работы с данными, хранящимися в памяти в веб-приложении, а затем, в конечном итоге, выйти из системы.Управлять масштабированием роли рабочего программного обеспечения
При изучении другого способа масштабирования одной из идей было использование рабочих ролей. Вместо того, чтобы обрабатывать веб-приложение, которое в настоящее время требует от нас использования довольно дорогого уровня цен, мы могли бы использовать служебную шину для передачи сообщений с соответствующими данными экземпляру рабочей роли, который бы выполнял эту обработку и отправлял результаты ,
Самый эффективный способ сделать это, похоже, - создать небольшой экземпляр роли рабочего для каждого пользователя, который будет работать в сети, что будет касаться исключительно их запросов (используя, например, очередь с именем после идентификатора пользователя), а затем будет уничтожен при завершении сеанса пользователя.
У меня есть код, чтобы определить, когда нужно развернуть экземпляр, как передавать эти сообщения взад и вперед и когда закрыть экземпляр, но мне трудно найти документацию для любых методов или вызовов API, которые позволят я делаю это легко. Самое близкое, что я могу найти для удаления экземпляра, описано here, но я не могу найти что-либо для их создания.
Каков наилучший способ вращения экземпляров вверх и вниз по Azure? Какие альтернативы доступны мне? Я также рад услышать альтернативные предложения о том, как это сделать.
Спасибо за этот весьма исчерпывающий ответ. У меня были подозрения, что это может не работать по нескольким причинам, спасибо за это. Таким образом, моя проблема с ограниченным числом рабочих ролей заключается в том, что эти задания нужно начинать немедленно, а продолжительность этих заданий может варьироваться от миллисекунд до минут. Мое беспокойство заключается в том, что при ограниченном числе одноядерных рабочих ролей (пытаясь снизить издержки), если одновременно выполнялись несколько длительных заданий, другие пользователи были бы эффективно заблокированы. Извините за то, что вы не более конкретно о приложении. –
Дэн, поэтому рекомендуется использовать метод масштабирования. По мере того, как все больше клиентов запускают работу, которая должна выполняться вашими экземплярами рабочей роли, в очереди будет больше сообщений. Автосканирование может запускаться на основе количества сообщений. Если есть больше сообщений, чем порог (который вы решите), это будет признаком того, что вам понадобятся дополнительные экземпляры рабочей роли, и затем можно соответствующим образом масштабировать ваши экземпляры. Вы можете захотеть просмотреть экземпляры XS вместо небольших, если ваша задача не является интенсивной в процессе. Последнее, что я проверил, может иметь 6 экземпляров XS по цене 1 Small instance. –
С помощью узлов XS вы ссылаетесь на узлы A0, подробно описанные здесь? http://azure.microsoft.com/en-us/pricing/details/cloud-services/ Если это так, я думаю, что мне понадобится хотя бы одно выделенное ядро на одну рабочую роль, хотя желательно больше (некоторые задания будут полезны для мульти- нарезание резьбы, и все они являются достаточно интенсивными процессами). Имеет ли следующий вид жизнеспособный подход: 2 очереди, один для отправки заданий, а другой для отправки результатов. Роли рабочих снимают задания с очереди, запускают задачу (которая не ожидается) и отмечают сообщение как завершенное, а затем через обработчик события отправляет сообщение после завершения? –