Центры задач в устойчивых функциях (Функции Azure)

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

Фактически в центре задач хранятся следующие сведения:

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

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

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

Рабочие элементы

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

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

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

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

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

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

Пример выполнения

Рассмотрим оркестрацию развертывания и объединения, которая запускает два действия в параллельном режиме и ожидает завершения обоих действий:

C#

C#

[FunctionName("Example")]
public static async Task Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    Task t1 = context.CallActivityAsync<int>("MyActivity", 1);
    Task t2 = context.CallActivityAsync<int>("MyActivity", 2);
    await Task.WhenAll(t1, t2);
}

JavaScript

JavaScript

module.exports = df.orchestrator(function*(context){
    const tasks = [];
    tasks.push(context.df.callActivity("MyActivity", 1));
    tasks.push(context.df.callActivity("MyActivity", 2));
    yield context.df.Task.all(tasks);
});

Python

Python

def orchestrator_function(context: df.DurableOrchestrationContext):
    tasks = []
    tasks.append(context.call_activity("MyActivity", 1))
    tasks.append(context.call_activity("MyActivity", 2))
    yield context.task_all(tasks)

PowerShell

PowerShell

param($Context)

$Tasks = @()

$Tasks += Invoke-DurableActivity -FunctionName 'MyActivity' -Input 1 -NoWait
$Tasks += Invoke-DurableActivity -FunctionName 'MyActivity' -Input 2 -NoWait

Wait-DurableTask -Task $Tasks

Java

Java

@FunctionName("Example")
public void exampleOrchestrator(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    Task<Void> t1 = ctx.callActivity("MyActivity", 1);
    Task<Void> t2 = ctx.callActivity("MyActivity", 2);
    ctx.allOf(List.of(t1, t2)).await();
}

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

1. Клиент запрашивает запуск новой оркестрации с идентификатором экземпляра "123". После завершения этого запроса клиент содержит заполнитель состояния оркестрации и сообщение экземпляра:

   

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

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

   

   Теперь среда выполнения находится в состоянии Running, добавлены два новых сообщения TaskScheduled, а журнал содержит пять событий: OrchestratorStarted, ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted. Эти события представляют собой первый эпизод выполнения оркестрации.

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

   

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

   

   Журнал оркестрации теперь содержит еще три события: OrchestratorStarted, TaskCompleted, OrchestratorCompleted. Эти события представляют собой второй эпизод выполнения оркестрации.

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

   

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

   

   Теперь среда выполнения находится в состоянии Completed, а журнал оркестрации содержит еще четыре события: OrchestratorStarted, TaskCompleted, ExecutionCompleted, OrchestratorCompleted. Эти события представляют собой третий и последний эпизод выполнения оркестрации.

Последний журнал этого выполнения оркестрации содержит 12 событий: OrchestratorStarted, ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted, OrchestratorStarted, TaskCompleted, OrchestratorCompleted, OrchestratorStarted, TaskCompleted, ExecutionCompleted, OrchestratorCompleted.

Ескерім

Показанное расписание не является единственным: существует несколько различных возможных расписаний. Например, если второе действие завершается раньше, то оба сообщения экземпляров TaskCompleted могут обрабатываться одним рабочим элементом. В этом случае журнал выполнения немного короче, поскольку существует только два эпизода, и он содержит следующие 10 событий: OrchestratorStarted, ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted, OrchestratorStarted, TaskCompleted, TaskCompleted, ExecutionCompleted, OrchestratorCompleted.

Управление центрами задач

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

Создание и удаление

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

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

Ескерім

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

Шайпұл

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

Несколько приложений-функций

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

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

Ескерім

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

Проверка содержимого

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

1. В приложении-функции клиентский объект предоставляет методы для отправки запросов к хранилищу экземпляров. Дополнительные сведения о поддерживаемых типах запросов см. в разделе Управление экземплярами.
2. Аналогичным образом API HTTP предоставляет запросы REST для запроса состояния оркестрации и сущностей. Дополнительные сведения см. в справочнике по API HTTP.
3. Средство Монитор устойчивых функций может проверять центры задач и предлагает различные варианты визуального отображения данных.

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

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

Представление в хранилище

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

Поставщик хранилищ Azure

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

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

Например, центр задач с именем xyz с PartitionCount = 4 содержит следующие очереди и таблицы:

Ниже мы подробно опишем эти компоненты и их роль.

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

Поставщик хранилищ Netherite

Netherite разделяет все состояние центра задач на указанное количество секций. В хранилище используются следующие ресурсы:

• один контейнер BLOB-объектов службы хранилища Azure, содержащий все BLOB-объекты, сгруппированные по секциям;
• одна Таблица Azure, содержащая опубликованные метрики секций;
• пространство имен Центров событий Azure для доставки сообщений между секциями.

Например, центр задач с именем mytaskhub с PartitionCount = 32 представлен в хранилище следующим образом:

Ескерім

Все состояние центра задач хранится в контейнере BLOB-объектов x-storage. Таблица DurableTaskPartitions и пространство имен Центров событий содержат избыточные данные: если их содержимое утеряно, данные можно восстановить автоматически. Поэтому не нужно настраивать пространство имен Центров событий Azure для хранения сообщений после истечения срока действия по умолчанию.

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

Дополнительные сведения о центрах задач для поставщика хранилища Netherite см. в разделе Информация о центрах задач для поставщика хранилища Netherite.

Поставщик хранилищ MSSQL

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

• таблиц dt.Instances и dt.History, в которых хранятся состояния экземпляров;
• таблицы dt.NewEvents, в которой хранятся сообщения экземпляров;
• таблицы dt.NewTasks, в которой хранятся сообщения о действиях.

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

Дополнительные сведения о центрах задач для поставщика хранилища MSSQL см. в разделе Информация о центрах задач для поставщика хранилища Microsoft SQL (MSSQL).

Имена центров задач

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

• Содержит только буквенно-цифровые символы.
• Начинается с буквы.
• Имеет длину от 3 до 45 символов.

Имя центра задач объявляется в файле host.json, как показано в следующем примере:

host.json (Функции, версия 2.0)

JSON

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub"
    }
  }
}

host.json (Функции, версия 1.x)

JSON

{
  "durableTask": {
    "hubName": "MyTaskHub"
  }
}

Центры задач также можно настроить с помощью параметров приложения, как показано на примере файла host.json:

host.json (Функции, версия 1.0)

JSON

{
  "durableTask": {
    "hubName": "%MyTaskHub%"
  }
}

host.json (Функции, версия 2.0)

JSON

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "hubName": "%MyTaskHub%"
    }
  }
}

Для имени центра задач будет установлено значение параметра приложения MyTaskHub. В следующем файле local.settings.json показано, как определить параметр MyTaskHub как samplehubname:

JSON

{
  "IsEncrypted": false,
  "Values": {
    "MyTaskHub" : "samplehubname"
  }
}

Ескерім

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

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

C#

C#

[FunctionName("HttpStart")]
public static async Task<HttpResponseMessage> Run(
    [HttpTrigger(AuthorizationLevel.Function, methods: "post", Route = "orchestrators/{functionName}")] HttpRequestMessage req,
    [DurableClient(TaskHub = "%MyTaskHub%")] IDurableOrchestrationClient starter,
    string functionName,
    ILogger log)
{
    // Function input comes from the request content.
    object eventData = await req.Content.ReadAsAsync<object>();
    string instanceId = await starter.StartNewAsync(functionName, eventData);

    log.LogInformation($"Started orchestration with ID = '{instanceId}'.");

    return starter.CreateCheckStatusResponse(req, instanceId);
}

Ескерім

Предыдущий пример предназначен для Устойчивые функции 2.x. Для расширения "Устойчивые функции" версии 1.x необходимо использовать DurableOrchestrationContext вместо IDurableOrchestrationContext. Дополнительные сведения о различиях между версиями см. в статье Версии устойчивых функций.

JavaScript

Свойство центра задач в файле function.json задается с помощью параметра приложения:

JSON

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Ескерім

Этот пример предназначен для Устойчивых функций версии 2.x. В версии 1.x используйте orchestrationClient вместо durableClient.

Python

Свойство центра задач в файле function.json задается с помощью параметра приложения:

JSON

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Ескерім

Этот пример предназначен для Устойчивых функций версии 2.x. В версии 1.x используйте orchestrationClient вместо durableClient.

PowerShell

Свойство центра задач в файле function.json задается с помощью параметра приложения:

JSON

{
    "name": "input",
    "taskHub": "%MyTaskHub%",
    "type": "durableClient",
    "direction": "in"
}

Ескерім

Этот пример предназначен для Устойчивых функций версии 2.x. В версии 1.x используйте orchestrationClient вместо durableClient.

Java

Java

@FunctionName("HttpStart")
public HttpResponseMessage httpStart(
        @HttpTrigger(name = "req", route = "orchestrators/{functionName}") HttpRequestMessage<?> req,
        @DurableClientInput(name = "durableContext", taskHub = "%MyTaskHub%") DurableClientContext durableContext,
        @BindingName("functionName") String functionName,
        final ExecutionContext context) {

    DurableTaskClient client = durableContext.getClient();
    String instanceId = client.scheduleNewOrchestrationInstance(functionName);
    context.getLogger().info("Created new Java orchestration with instance ID = " + instanceId);
    return durableContext.createCheckStatusResponse(req, instanceId);
}

Ескерім

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

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

Версия устойчивых функций	Имя центра задач по умолчанию
2.x	При развертывании в Azure имя центра задач создается на основе имени приложения-функции. При выполнении за пределами Azure имя центра задач по умолчанию — TestHubName.
1.x	Имя центра задач по умолчанию для всех сред — DurableFunctionsHub.

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

Ескерім

Имя —это то, что отличает один центр задач от другого, если в общей учетной записи хранения таких центров несколько. Если общую учетную запись хранения используют несколько приложений-функций, вам нужно задать разные имена для каждого центра задач в файлах host.json. В противном случае несколько приложений-функций будут конкурировать друг с другом за сообщения, что может привести к неопределенному поведению, включая оркестрации, приводящие к неожиданному "зависанию" в состоянии Pending или Running.

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

Сведения об управлении версиями оркестрации