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

  • Статья

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

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

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

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

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

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

Триггеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Веб-приложения Azure и веб-задания. Вы можете использовать веб-задания, чтобы выполнять пользовательские задания на основе диапазона различных типов сценариев или исполняемых файлов в контексте веб-приложения.
  • Функции Azure. Функции можно использовать для фоновых заданий, которые выполняются недолго. Другой вариант использования — рабочая нагрузка, уже размещенная в плане службы приложений, но используемая не полностью.
  • Виртуальные машины Azure. Если вы используете службу Windows или хотите использовать планировщик заданий Windows, обычно для размещения фоновых задач используется выделенная виртуальная машина.
  • Пакетная служба Azure. Пакетная служба — это платформа, которая позволяет запланировать выполнение ресурсоемких вычислений в управляемой коллекции виртуальных машин. Она поддерживает автоматическое масштабирование вычислительных ресурсов.
  • Служба 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.
  • Если при настройке задания выбрать параметр Выполнять по требованию, оно будет выполнять тот же код, что и параметр Выполнять по расписанию, когда вы его запустите.

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

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

  • Безопасность: веб-задания защищены с помощью учетных данных развертывания веб-приложения.
  • Поддерживаемые типы файлов: можно определить веб-задания с помощью скриптов команд (.cmd), пакетных файлов (.bat), сценариев PowerShell (.ps1), скриптов оболочки Bash (.sh), скриптов PHP (.php), скриптов Python (), кода JavaScript (.py.js) и исполняемых программ (.jar.exe, и т. д.).
  • Развертывание. Вы можете развертывать скрипты и исполняемые файлы с помощью портал Azure с помощью Visual Studio, с помощью пакета SDK веб-заданий Azure или путем копирования их непосредственно в следующие расположения:
    • Для выполнения по триггеру: site/wwwroot/app_data/jobs/triggered/{имя задания}
    • Для непрерывного выполнения: site/wwwroot/app_data/jobs/continuous/{имя задания}
  • Ведение журнала: Console.Out обрабатывается (помечается) как информация, а Console.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 значение true. Одноэкземплярные веб-задания удобны для задач, которые не требуется масштабировать или выполнять одновременно в виде нескольких экземпляров: это может быть повторная индексация, анализ данных и схожие задачи.
  • Чтобы свести к минимуму влияние заданий на производительность веб-приложения, рассмотрите возможность создания пустого экземпляра веб-приложения Azure в новом плане службы приложений для размещения веб-заданий, которые могут долго выполняться или потреблять много ресурсов.

Функции Azure

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

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

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

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

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

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

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

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

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

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

Для запуска фоновой задачи в отдельной виртуальной машине имеется целый ряд возможностей:

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

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

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

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

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

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

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

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

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

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

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

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

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

Служба Azure Kubernetes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конфликты

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

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

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

Координация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Следующие шаги