Запуск нескольких рабочих ролей на экземпляр

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

Есть ли способ создать "многопользовательскую роль" WorkerRole так же, как вы можете создать "несколько сайтов" WebRole?

В отрицательном случае я могу создать "роль главного работника", которая может загружать сборки из заданной папки, искать классы, основанные на RoleEntryPoint, с отражением, создавать экземпляры и вызывать .Run() или .OnStart() метод. Эта "роль мастера-работника" также отобразит неожиданные исключения и вызовет .OnStop() во всех sub RoleEntryPoint, когда .OnStop() вызывается в главном. Будет ли это работать? Что я должен знать?

Ответ 1

Как уже упоминалось другими, это очень распространенный метод максимизации использования ваших экземпляров. Могут быть примеры и "рамки", которые абстрагируют рабочую инфраструктуру и фактическую работу, которую вы хотите выполнить, в том числе один в этом (нашем) примере: http://msdn.microsoft.com/en-us/library/ff966483.aspx (прокрутка вплоть до "внутри реализации" )

Наиболее распространенными способами запуска работы являются:

Временные работники (например, "cron" работы)
На основе сообщений работают сотрудники (работа, вызванная присутствием сообщения).

В приведенном выше примере кода реализованы дополнительные абстракции для # 2 и легко расширяемы для # 1.

Имейте в виду, что все взаимодействия с очередями основаны на опросе. Рабочий не проснется с новым сообщением в очереди. Вам нужно активно запросить очередь для новых сообщений. Запросы слишком часто заставят Microsoft радоваться, но, вероятно, не вы:-). Каждый запрос считается транзакцией, которая выставлена на счет (10K из них = 0,01 доллара США). Хорошей практикой является опрос очереди на сообщения с каким-то отсроченным отклонением. Также, получайте сообщения в партиях.

Наконец, сделав это предельно, вы также можете объединить роли в сети и рабочие роли в одном экземпляре. См. Здесь пример: http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure

Ответ 2

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

Ролевое объединение - это обычная модель, которую я видел, работая с ISV в их развертываниях Windows Azure. У вас может быть фоновый поток, который просыпается так часто и запускает процесс. Другим распространенным методом реализации является использование очереди Azure для отправки сообщения, представляющего процесс для выполнения. Вы можете иметь несколько очередей, если хотите, или одну очередь команд. В любом случае у вас будет прослушиватель очереди в фоновом потоке, который будет запускаться в каждом экземпляре. Первый, кто получает сообщение, обрабатывает его. Вы можете принять его дальше, и у вас есть синхронизированный процесс, который выталкивает эти сообщения в очередь (может быть, каждые 24 часа или каждый час).

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

EDIT: по состоянию на сентябрь 2011 года настройка ролей стала намного более гибкой, теперь у вас есть 25 конечных точек входа (доступны из внешнего мира) и 25 внутренних конечных точек (используемых для связи между ролями) по всему развертыванию. Статья MSDN здесь

Недавно я писал о перегрузке веб-роли, что несколько связано.

Ответ 3

В то время как нет реальной проблемы с решениями, которые были указаны для поиска способов сделать несколько рабочих компонентов в рамках одной рабочей роли, я просто хочу, чтобы вы имели в виду весь смысл наличия определенных Ролей Рабочих, определенных в первом место - это изоляция перед лицом недостатков. Если вы просто запихнете все в один экземпляр рабочей роли, только один из тех рабочих компонентов, которые ведут себя плохо, имеет возможность удалить все остальные рабочие компоненты в этой роли. Теперь вы внезапно пишете много инфраструктуры, чтобы обеспечить изоляцию и отказоустойчивость компонентов, что в значительной степени является тем, что Azure предоставляет вам.

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

Ответ 4

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

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

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