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

  • Статья

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

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

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

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

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

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

Ключевые стратегии проектирования

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

Типы фоновых заданий

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

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

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

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

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

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

Триггеры

Инициируйте фоновые задания с помощью:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возврат результатов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конфликты

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

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

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

Координация

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

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

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

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

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

Рекомендации по обеспечению устойчивости

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

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

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

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

Сообщения

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

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

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

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

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

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

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

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

Рекомендации по производительности и масштабированию

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

  • Виртуальные машины 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 предоставляет доступ к файлам журнала действий веб-заданий.

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

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

  • Поддерживаемые типы файлов: определение веб-заданий с помощью скриптов команд (CMD), пакетных файлов (.bat), сценариев PowerShell (.ps1), скриптов оболочки Bash (SH), скриптов PHP (PHP), скриптов Python (PY), кода JavaScript (.js) и исполняемых программ (.exe и JAR).

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

    • Для активированного развертывания: 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.

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

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

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

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

Служба Azure Kubernetes

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

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

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

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

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

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

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

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

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

Приложения-контейнеры

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

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

  • Используется на базе Kubernetes и технологий с открытым кодом, таких как Dapr, автомасштабирование на основе событий Kubernetes (KEDA) и Envoy.

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

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

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

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

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

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

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

См. полный набор рекомендаций.

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