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

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

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

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

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

Терминология

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

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

Вот несколько примеров фоновых заданий:

• Задания с большим объемом ЦП, такие как математические вычисления или анализ структурной модели.

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

• Пакетные задания, такие как ночное обновление данных или запланированная обработка.

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

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

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

Запустите фоновые задания с помощью следующих триггеров:

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

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

Триггеры, управляемые событиями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задания фонового разделения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сделать задания устойчивыми

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

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

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

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

Messages

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Среды окружения

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

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

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

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

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

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

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

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

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

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

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

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

  • Для триггерного развертывания: site/wwwroot/app_data/jobs/triggered/<имя задачи>

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

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

  • Для инициированной развертки: Vfs/data/jobs/triggered/<job name>

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

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

  • { "stopping_wait_time": 60 }

  • { "is_singleton": true }

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

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

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

Azure Functions

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

Используйте устойчивые функции Azure для оркестрации сложных рабочих процессов и длительных процессов. Устойчивые функции (Durable Functions) позволяют определять рабочие процессы с отслеживанием состояния в бессерверной среде, что может быть особенно полезно для фоновых задач, требующих координации и управления состоянием.

Рекомендации по функциям Azure

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

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

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

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

• Варианты размещения Функций Azure
• Триггер таймера для Azure Functions

Приложения логики Azure

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

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

Рекомендации по Azure Logic Apps

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

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

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

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

• Соединители приложений логики
• Справочник по ограничениям и конфигурации для Azure Logic Apps

Virtual Machines

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

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

• Выбор службы вычислений Azure
• Размеры виртуальных машин в Azure
• Маркетплейс виртуальных машин

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

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

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

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

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

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

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

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

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

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

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

• Шаблон мониторинга конечных точек работоспособности
• виртуальные машины
• Вопросы и ответы о виртуальных машинах

Azure Batch

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

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

Рассмотрение пакетной обработки

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

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

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

• Узлы и пулы в Batch
• Что такое Batch?
• Задания и задачи в Batch
• HPC в Azure
• Рабочий процесс и ресурсы пакетной службы

Azure Kubernetes Service

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

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

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

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

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

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

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

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

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

• Общие сведения о контейнерах в Azure
• Общие сведения о реестрах контейнеров в Azure

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

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

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

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

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

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

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

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

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

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

• Общие сведения о контейнерах приложений
• Краткое руководство по началу работы: Развертывание вашего первого контейнерного приложения

Связанные ссылки

• шаблон компенсации транзакций
• Шаблон конкурирующих потребителей
• Шаблон выборов лидера
• Шаблон каналов и фильтров
• Шаблон очереди приоритета
• шаблон выравнивания нагрузкиQueue-Based
• Шаблон супервизора агента планировщика

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

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