Рекомендации по разработке фоновых заданий

  • Статья

Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:

RE:07 Повышение устойчивости и возможности восстановления рабочей нагрузки путем реализации мер самосохранения и самовосстановления. Создайте возможности в решении с помощью шаблонов надежности на основе инфраструктуры и шаблонов проектирования на основе программного обеспечения для обработки сбоев компонентов и временных ошибок. Создайте возможности в системе для обнаружения сбоев компонентов решения и автоматического запуска корректирующего действия, пока рабочая нагрузка продолжает работать в полной или ограниченной функциональности.

Связанные руководства. Временные | ошибки самосохранения

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

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

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

Основные стратегии проектирования

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

Оценка необходимости фоновых заданий

Ниже приведены некоторые примеры фоновых заданий:

  • Задания, интенсивно использующие ЦП, например математические вычисления или анализ структурных моделей.

  • Задания с интенсивным вводом-выводом, например выполнение ряда транзакций хранения или индексирования файлов.

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

  • Длительные рабочие процессы, такие как выполнение заказов или подготовка служб и систем.

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

Выбор правильных триггеров

Запуск фоновых заданий с помощью:

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

  • Триггеры на основе расписания: расписание, основанное на таймере, вызывает задачу. Задание можно запланировать на регулярной основе или для одного запуска.

Запуск при определенном событии

Действие запускает вызов на основе событий, который запускает фоновую задачу. Ниже приведены примеры триггеров на основе событий:

  • Пользовательский интерфейс или другое задание помещает сообщение в очередь, как описано в стиле архитектуры web-Queue-Worker. Сообщение содержит данные о ранее выполненном действии, например клиенте, который разместил заказ. Фоновое задание отслеживает эту очередь и обнаруживает прибытие нового сообщения. Он считывает сообщение и использует данные сообщения в качестве входных данных для фонового задания. Этот шаблон называется асинхронным взаимодействием на основе сообщений.

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

  • Пользовательский интерфейс или другое задание выполняет запрос к конечной точке, например URI HTTPS или API, предоставляемый в качестве веб-службы. В рамках запроса пользовательский интерфейс или задание передает данные, необходимые фоновой задаче. Конечная точка или веб-служба вызывает фоновую задачу, которая использует эти данные в качестве входных.

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

Триггеры, управляемые расписанием

Таймер запускает вызов на основе расписания, который запускает фоновую задачу. Ниже приведены примеры триггеров на основе расписания:

  • Таймер, выполняющийся локально в приложении или в составе операционной системы приложения, регулярно вызывает фоновую задачу.

  • Таймер, работающий в другом приложении, например Azure Logic Apps, регулярно отправляет запрос в API или веб-службу. API или веб-служба вызывает фоновую задачу.

  • Отдельный процесс или приложение запускает таймер, который вызывает фоновую задачу после задержки времени или в определенное время.

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

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

  • Если вычислительный экземпляр, на котором выполняется планировщик, например виртуальная машина, использующая запланированные задачи Windows, масштабируется, выполняется несколько экземпляров планировщика. Несколько экземпляров планировщика могут запускать несколько экземпляров задачи. Дополнительные сведения см. в разделе "Что означает идемпотентное" в программных системах?

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

Возврат данных в рабочую нагрузку

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

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

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

  • Установите очередь ответа, отслеживаемую пользовательским интерфейсом или вызывающим элементом. Фоновая задача может отправлять сообщения в очередь, указывающую состояние. Данные, возвращаемые фоновой задачей вызывающей программе, можно поместить в сообщения. Для Служебная шина Azure используйте ReplyTo свойства для CorrelationId реализации этой возможности.

  • Предоставление из фоновой задачи API или конечной точки, к которой может обратиться пользовательский интерфейс или вызывающая задача, чтобы получить информацию о состоянии. Ответ может включать данные, возвращаемые фоновой задачей вызывающей функции.

  • Настройте фоновую задачу, чтобы вернуться к пользовательскому интерфейсу или вызывающей стороне через API, чтобы указать состояние в предопределенных точках или при завершении. Вы можете использовать события, возникающие локально или механизм публикации и подписки. Запрос или полезные данные события могут включать данные, возвращаемые фоновой задачей вызывающей.

Фоновые задания секционирования

Если включить фоновые задания в существующий вычислительный экземпляр, рассмотрите, как эти изменения влияют на качество атрибутов вычислительного экземпляра и фонового задания. Рассмотрите эти факторы, чтобы решить, следует ли объединить задачи с существующим вычислительным экземпляром или разделить их на другой вычислительный экземпляр:

  • Доступность. Фоновые задачи могут не нуждаться в том же уровне доступности, что и другие части приложения, в частности пользовательский интерфейс и части, которые напрямую связаны с взаимодействием с пользователем. Фоновые задачи могут иметь более высокую устойчивость к задержке, повторным сбоям подключения и другим факторам, влияющим на доступность, так как операции могут быть в очереди. Однако для предотвращения резервного копирования запросов, которые могут блокировать очереди и влиять на все приложение, должно быть достаточно емкости.

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

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

  • Безопасность: фоновые задачи могут иметь различные требования к безопасности или ограничения по сравнению с пользовательским интерфейсом или другими частями приложения. Используйте отдельный вычислительный экземпляр, чтобы указать другую среду безопасности для задач. Чтобы максимально повысить безопасность и разделение, можно также использовать такие шаблоны, как Gatekeeper, чтобы изолировать фоновые вычислительные экземпляры от пользовательского интерфейса.

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

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

  • Стоимость: если вы добавляете вычислительные экземпляры для выполнения фоновых задач, увеличение затрат на размещение. Тщательно рассмотрите компромисс между большей емкостью и дополнительными затратами.

Дополнительные сведения см. в шаблоне выборов лидера и шаблоне конкурирующих потребителей.

Предотвращение конфликта ресурсов

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

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

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

Оркестрация нескольких задач

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

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

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

  • Управление оркестрацией шагов для задачи. Приложение может выполнять задачи, составляющие множество шагов, некоторые из которых могут вызывать удаленные службы или получать доступ к удаленным ресурсам. Иногда отдельные шаги не зависят друг от друга, но они управляются логикой приложения, реализующей задачу. Дополнительные сведения см. в статье Шаблон супервизора агента планировщика.

  • Управление восстановлением для шагов задачи, которые завершаются сбоем. Если один или несколько шагов завершаются сбоем, приложению может потребоваться отменить работу, выполняемую рядом шагов, которые вместе определяют согласованную операцию. Дополнительные сведения см . в разделе "Компенсирующая транзакция".

Создание устойчивых заданий

Создайте устойчивые фоновые задачи для предоставления надежных служб для приложения. При планировании и проектировании фоновых задач рассмотрите следующие моменты:

  • Фоновые задачи должны корректно обрабатывать перезапуски без повреждения данных или несогласованности в приложении. Для длительных или многоэтапных задач рекомендуется использовать контрольные точки. Используйте контрольные точки для сохранения состояния заданий в постоянном хранилище или в виде сообщений в очереди. Например, можно хранить сведения о состоянии в сообщении, которое находится в очереди и постепенно обновлять эти сведения о состоянии с выполнением задачи. Задача может обрабатываться из последней известной контрольной точки вместо перезапуска с самого начала.

    Для очередей служебная шина используйте сеансы сообщений для этой цели. С помощью сеансов сообщений сохраните и получите состояние обработки приложения с помощью методов SetState и GetState. Дополнительные сведения о проектировании надежных многоэтапных процессов и рабочих процессов см . в шаблоне диспетчера агентов планировщика.

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

Сообщения

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

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

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

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

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

  • Очереди — это по крайней мере один раз механизмы доставки, но они могут доставлять одно и то же сообщение более одного раза. Если фоновая задача завершается сбоем после обработки сообщения, но перед его удалением из очереди сообщение будет доступно для повторной обработки.

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

  • Некоторые системы обмена сообщениями, такие как служба хранилища Azure очереди и очереди служебная шина, поддерживают свойство dequeue count, указывающее, сколько раз считывается сообщение из очереди. Эти данные полезны для обработки повторяющихся сообщений и подозрительных сообщений. Дополнительные сведения см. в статье "Асинхронная схема обмена сообщениями" и "Идемпотентность".

Создание масштабируемых заданий

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

  • Azure Виртуальные машины и компонент веб-приложения службы приложение Azure может размещать развертывания. Они поддерживают автоматическое масштабирование и масштабирование. Автоматическое масштабирование определяется запросом и загрузкой или предопределенным расписанием. Используйте автоматическое масштабирование, чтобы обеспечить достаточное количество возможностей производительности приложения при минимизации затрат на среду выполнения.

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

  • Чтобы предотвратить потерю производительности при загрузке, может потребоваться также масштабировать очереди хранилища и другие ресурсы, чтобы одна точка цепочки обработки не приводила к узким местам. Рассмотрим другие ограничения, такие как максимальная пропускная способность хранилища и других служб, которые используются приложением и фоновыми задачами.

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

  • По умолчанию веб-заданий масштабируется с соответствующим экземпляром веб-приложения. Однако если вы хотите, чтобы веб-задание выполнялось только в одном экземпляре, можно создать файл Settings.job, содержащий данные { "is_singleton": true }JSON. Этот метод заставляет Azure запускать только один экземпляр веб-задания, даже если существует несколько экземпляров связанного веб-приложения. Этот метод полезен для запланированных заданий, которые должны выполняться только в одном экземпляре.

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

  • Фоновые задания могут повлиять на взаимодействие с пользователем, если результаты фоновых задач представлены пользователю. Например, фоновые задания могут потребовать от пользователя ожидать уведомления, обновить страницу или вручную проверить состояние задачи. Это поведение может повысить сложность взаимодействия с пользователем и негативно повлиять на взаимодействие с пользователем.

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

Упрощение функций Azure

В следующих разделах описаны службы Azure, которые можно использовать для размещения, запуска, настройки и управления фоновыми заданиями.

Среды размещения

Существует несколько служб платформы Azure, которые могут размещать фоновые задачи:

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

  • Функции Azure. Используйте приложения-функции для фоновых заданий, которые не выполняются в течение длительного времени. Вы также можете использовать приложения-функции, если вы размещаете рабочую нагрузку в неиспользуемом плане Служба приложений.

  • Виртуальные машины. Если у вас есть служба Windows или вы хотите использовать планировщик задач Windows, разместите фоновые задачи на выделенной виртуальной машине.

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

  • Служба Azure Kubernetes (AKS):AKS предоставляет управляемую среду размещения для Kubernetes в Azure.

  • Приложения контейнеров Azure. С помощью контейнерных приложений можно создавать бессерверные микрослужбы, основанные на контейнерах.

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

веб-приложения и веб-задания

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

При настройке веб-задания:

  • Если вы хотите, чтобы задание отвечало триггеру на основе событий, настройте его для непрерывного выполнения. Скрипт или программа хранятся в папке с именем site/wwwroot/app_data/jobs/continuous.

  • Если вы хотите, чтобы задание ответило на триггер на основе расписания, настройте его для запуска по расписанию. Сценарий или программа хранится в папке site/wwwroot/app_data/jobs/triggered.

  • Если при настройке задания выбран параметр "Запуск по запросу ", он запускает тот же код, что и параметр "Запуск по расписанию " при запуске задания.

Веб-задание выполняется в песочнице веб-приложения. Он имеет доступ к переменным среды и может совместно использовать информацию, например строка подключения, с веб-приложением. Веб-задание имеет доступ к уникальному идентификатору компьютера, на котором выполняется веб-задание. Строка подключения с именем AzureWebJobsStorage предоставляет доступ к очередям хранилища, большим двоичным объектам и таблицам для данных приложения. Он также предоставляет доступ к служебная шина для обмена сообщениями и обмена данными. Строка подключения с именем AzureWebJobsDashboard предоставляет доступ к файлам журнала действий webJob.

Веб-задания имеют следующие характеристики:

  • Безопасность. Учетные данные развертывания веб-приложения обеспечивают защиту для веб-заданий.

  • Поддерживаемые типы файлов: определение веб-заданий с помощью скриптов команд (.cmd), пакетных файлов (.bat), скриптов PowerShell (PS1), скриптов оболочки Bash (.sh), скриптов PHP (.php), скриптов Python (.py), кода JavaScript (.js) и исполняемых программ (.exe и .jar).

  • Развертывание. Вы можете развертывать скрипты и исполняемые файлы с помощью пакета SDK портал Azure, Visual Studio или веб-заданий или скопировать их непосредственно в следующие расположения:

    • Для запуска развертывания: site/wwwroot/app_data/jobs/triggered/<job name>

    • Для непрерывного развертывания: site/wwwroot/app_data/jobs/continuous/<job name>

  • Файлы журнала: Console.Out обрабатываются или помечены как INFO. Console.Error рассматривается как ERROR. Используйте портал для доступа к данным мониторинга и диагностика. Скачайте файлы журналов непосредственно с веб-сайта. Файлы журналов сохраняются в следующих расположениях:

    • Для запуска развертывания: Vfs/data/jobs/triggered/<job name>

    • Для непрерывного развертывания: Vfs/data/jobs/continuous/<job name>

  • Конфигурация. Настройка веб-заданий с помощью портала, REST API и PowerShell. Используйте файл конфигурации с именем settings.job, который находится в том же корневом каталоге, что и скрипт веб-задания, чтобы предоставить сведения о конфигурации для веб-задания. Например:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

рекомендации по веб-приложения и веб-заданиям

  • По умолчанию веб-задания масштабируются вместе с веб-приложением. Чтобы настроить веб-задания для запуска в одном экземпляре, задайте is_singleton для свойства конфигурации значение true. Веб-задания одного экземпляра полезны для задач, которые не нужно масштабировать или запускать как одновременные несколько экземпляров, например переиндексирование или анализ данных.

  • Чтобы свести к минимуму влияние веб-заданий на производительность веб-приложения, создайте пустой экземпляр веб-приложения в новом Служба приложений плане размещения длительных или ресурсоемких веб-заданий.

Функции Azure

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

Функции Azure не рекомендуется для больших длительных задач, так как функция может вызвать непредвиденные время ожидания. Однако в зависимости от плана размещения рекомендуется использовать функции для триггеров, управляемых расписанием.

рекомендации по Функции Azure

Если вы ожидаете, что фоновая задача будет выполняться в течение короткой длительности в ответ на событие, рассмотрите возможность выполнения задачи в плане потребления. Вы можете настроить среду выполнения на максимальное время. Чем дольше выполняется функция, тем больше затраты. Задания с большим объемом ЦП, которые используют больше памяти, могут быть более дорогими. Если вы используете дополнительные триггеры для служб в рамках задачи, они выставляются отдельно.

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

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

Дополнительные сведения см. в разделе:

Виртуальные машины

Вы можете реализовать фоновые задачи, чтобы они не развертывались в веб-приложения. Например, можно реализовать задачи с помощью служб Windows, сторонних служебных программ или исполняемых программ. Вы также можете использовать программы, написанные для среды выполнения, отличной от среды, в которой размещено приложение. Например, можно использовать программу Unix или Linux, которую вы хотите запустить из приложения Windows или .NET. Выберите из нескольких операционных систем для виртуальной машины Azure и запустите службу или исполняемый файл на этой виртуальной машине.

Дополнительные сведения см. в разделе:

Чтобы инициировать фоновую задачу на отдельной виртуальной машине, можно:

  • Отправьте запрос в конечную точку, которую задача предоставляет для выполнения задачи по запросу непосредственно из приложения. Запрос передает данные, необходимые задаче. Конечная точка вызывает задачу.

  • Используйте планировщик или таймер из выбранной операционной системы, чтобы настроить задачу для выполнения по расписанию. Например, в Windows можно использовать планировщик задач Windows для выполнения скриптов и задач. Если на виртуальной машине установлен SQL Server, используйте агент SQL Server для выполнения скриптов и задач.

  • Используйте Logic Apps для запуска задачи, добавив сообщение в очередь, отслеживающую задачу или отправив запрос в API, предоставляемый задачей.

Дополнительные сведения о том, как инициировать фоновые задачи, см. в предыдущем разделе "Триггеры ".

рекомендации по Виртуальные машины

При развертывании фоновых задач на виртуальной машине Azure следует учитывать следующие моменты:

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

  • На портале нет возможности автоматического перезапуска для неудачных задач. Но вы можете использовать командлеты Azure Resource Manager для мониторинга состояния виртуальной машины и управления им. Нет средств для управления процессами и потоками в вычислительных узлах. Как правило, при использовании виртуальной машины необходимо реализовать механизм, который собирает данные из инструментирования в задаче, а также из операционной системы на виртуальной машине. Для этого можно использовать пакет управления System Center для Azure .

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

Дополнительные сведения см. в разделе:

Пакетная служба

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

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

Рекомендации по пакетной службе

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

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

Дополнительные сведения см. в разделе:

Служба Azure Kubernetes

Используйте AKS для управления размещенной средой Kubernetes, чтобы легко развертывать контейнерные приложения и управлять ими.

Контейнеры полезны для выполнения фоновых заданий. Вот некоторые преимущества этого решения:

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

  • Используйте оркестратор контейнеров для выполнения внутренней балансировки нагрузки, настройки внутренней сети и выполнения других задач конфигурации.

  • При необходимости можно запускать и останавливать контейнеры.

  • С помощью Реестр контейнеров Azure вы можете зарегистрировать контейнеры в границах Azure, чтобы обеспечить безопасность, конфиденциальность и преимущества близкого взаимодействия.

Рекомендации по AKS

AKS требует понимания того, как использовать оркестратор контейнеров.

Дополнительные сведения см. в разделе:

Контейнеры приложений

С помощью контейнерных приложений можно создавать бессерверные микрослужбы, основанные на контейнерах. Приложения-контейнеры:

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

  • Работает с помощью технологий Kubernetes и open-source, таких как Dapr, Kubernetes Autoscaling (KEDA) и Envoy.

  • поддерживают приложения и микрослужбы в стиле Kubernetes с такими функциями, как обнаружение служб и разделение трафика;

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

  • Поддерживает длительные процессы и может выполнять фоновые задачи.

Рекомендации по приложениям-контейнерам

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

Дополнительные сведения см. в разделе:

Контрольный список надежности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список надежности