Поделиться через

Фоновые задачи

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

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

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

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

Фоновые задания обычно включают одно или несколько следующих типов заданий:

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

Триггеры

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

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

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

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

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

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

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

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

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

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

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

Возвращение результатов

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

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

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

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

Фоновые задачи можно разместить с помощью различных служб платформы Azure:

  • Веб-приложения Azure и веб-задания. Веб-задания можно использовать для выполнения пользовательских заданий на основе различных типов скриптов или исполняемых программ в контексте веб-приложения.
  • Функции Azure. Функции можно использовать для фоновых заданий, которые не выполняются в течение длительного времени. Другой вариант использования — это когда рабочая нагрузка уже размещена в плане службы приложений, но используется неэффективно.
  • Виртуальные машины Azure. Если у вас есть служба Windows или вы хотите использовать планировщик задач Windows, обычно приходится размещать фоновые задачи в выделенной виртуальной машине.
  • Пакетная служба Azure. Batch — это сервис на платформе, который составляет расписание для выполнения вычислительных задач на управляемой коллекции виртуальных машин. Он может автоматически масштабировать вычислительные ресурсы.
  • Служба Azure Kubernetes (AKS). Служба Azure Kubernetes предоставляет управляемую среду размещения для Kubernetes в Azure.
  • Приложения контейнеров Azure. Приложения-контейнеры Azure позволяют создавать бессерверные микрослужбы на основе контейнеров.

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

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

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

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

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

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

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

  • Безопасность: веб-задания защищены учетными данными развертывания веб-приложения.
  • Поддерживаемые типы файлов: можно определить веб-задания с помощью скриптов команд (.cmd), пакетных файлов (.bat), сценариев PowerShell (.ps1), скриптов оболочки Bash (.sh), скриптов PHP (.php), скриптов Python (), кода JavaScript (.py.js) и исполняемых программ (.exe.jar, и т. д.).
  • Развертывание. Вы можете развертывать скрипты и исполняемые файлы с помощью портала Azure с помощью Visual Studio, с помощью пакета SDK веб-заданий Azure или путем копирования их непосредственно в следующие расположения:
    • Для выполнения по триггеру: site/wwwroot/app_data/jobs/triggered/{имя задания}
    • Для непрерывного выполнения: site/wwwroot/app_data/jobs/continuous/{имя задания}
  • Ведение журнала: Console.Out обрабатывается (помечается) как INFO. Console.Error рассматривается как ERROR. Вы можете получить доступ к данным мониторинга и диагностики с помощью портала Azure. Файлы журналов можно скачать непосредственно с сайта. Они сохраняются в следующих расположениях:
    • Для запуска выполнения задачи: Vfs/data/jobs/triggered/jobName
    • Для непрерывного выполнения: Vfs/data/jobs/continuous/jobName
  • Конфигурация. Веб-задания можно настроить с помощью портала, REST API и PowerShell. Файл конфигурации с именем settings.job можно использовать в том же корневом каталоге, что и сценарий задания, чтобы предоставить сведения о конфигурации для задания. Например:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": правда }

Соображения

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

Функции Azure

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

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

Соображения

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

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

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

Дополнительные сведения см. в следующих статьях:

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

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

Для помощи в выборе использования виртуальных машин см. сравнение Служб приложений Azure, Облачных служб и Виртуальных машин. Сведения о параметрах виртуальных машин см. в статье "Размеры виртуальных машин Windows" в Azure. Дополнительные сведения об операционных системах и предварительно созданных образах, доступных для виртуальных машин, см. в Azure Virtual Machines Marketplace.

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

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

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

Соображения

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

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

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

Пакетная обработка Azure

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

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

Соображения

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

Задание пакетной службы Azure выполняется в пуле узлов (виртуальных машин). Одним из способов является выделение пула только в случае необходимости, а затем удаление пула после завершения задания. Это обеспечивает максимальное использование, так как узлы активны. Однако, задание должно ждать выделения узлов. Кроме того, можно заранее создать пул. Этот подход сводит к минимуму время, необходимое для запуска задания, но может привести к тому, что узлы становятся неактивными. Дополнительные сведения см. в разделе "Время существования пула и вычислительного узла".

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

Служба Azure Kubernetes

Служба Azure Kubernetes (AKS) управляет размещенной средой Kubernetes, что упрощает развертывание контейнерных приложений и управление ими.

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

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

Соображения

  • Необходимо понимание, как использовать оркестратор контейнеров. В зависимости от набора навыков команды DevOps это может быть или не может быть проблемой.

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

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

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

Соображения

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

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

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

Секционирование

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

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

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

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

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

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

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

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

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

Конфликты

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

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

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

Координация

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

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

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

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

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

Вопросы устойчивости

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

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

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

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

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

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

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

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

Замечания, связанные с масштабированием и быстродействием

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

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

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

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

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

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

Дальнейшие действия