Запускать несколько WorkerRoles для каждого экземпляра

Question

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

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

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

Answer 1

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

Те наиболее распространенные способы запуска работы:

1. Рабочие по расписанию (например, задания "cron")
2. Рабочие на основе сообщений (работа, вызванная наличием сообщения).

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

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

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

Answer 2

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

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

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

РЕДАКТИРОВАТЬ: С сентября 2011 года конфигурация ролей стала намного более гибкой, теперь у вас есть 25 входных конечных точек (доступных из внешнего мира) и 25 внутренних конечных точек (используемых для связи между ролями) во всем развертывании. Статья MSDN здесь

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

Answer 3

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

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

Answer 4

Почему «мульти роль» - это беспорядок? Вы можете написать каждую реализацию рабочей роли как слабо связанный компонент , а затем составить рабочую роль из всех соответствующих компонентов.

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

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