Центры задач

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

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

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

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

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

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

Рабочие задачи

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

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

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

Дополнительные сведения о ограничении параллелизма см. в разделе Производительность и масштабирование.

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

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

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

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

Рассмотрим оркестрацию типа «fan-out-fan-in», которая запускает параллельно выполняемые две действия и ожидает завершения обоих.

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

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

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

param($Context)

$Tasks = @()

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

Wait-DurableTask -Task $Tasks

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();
}

C#

using Microsoft.DurableTask;

public class Example : TaskOrchestrator<object?, object?>
{
    public override async Task<object?> RunAsync(TaskOrchestrationContext context, object? input)
    {
        Task t1 = context.CallActivityAsync("MyActivity", 1);
        Task t2 = context.CallActivityAsync("MyActivity", 2);
        await Task.WhenAll(t1, t2);
        return null;
    }
}

JavaScript

Этот пример показан для .NET, Java и Python.

Python

from durabletask import task

def example_orchestrator(ctx: task.OrchestrationContext, _):
    t1 = ctx.call_activity("my_activity", input=1)
    t2 = ctx.call_activity("my_activity", input=2)
    yield task.when_all([t1, t2])

PowerShell

Этот пример показан для .NET, Java и Python.

Java

import com.microsoft.durabletask.TaskOrchestration;
import com.microsoft.durabletask.TaskOrchestrationContext;

public class Example implements TaskOrchestration {
    @Override
    public void run(TaskOrchestrationContext ctx) {
        Task<Void> t1 = ctx.callActivity("MyActivity", 1, Void.class);
        Task<Void> t2 = ctx.callActivity("MyActivity", 2, Void.class);
        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 CLI, Azure Resource Manager (ARM) или Bicep.

Портал Azure

1. На портале Azure найдите планировщик задач Durable Task Scheduler и выберите его из результатов.

2. Выберите "Создать", чтобы открыть область создания планировщика.

3. Заполните поля на вкладке "Основные сведения" , включая группу ресурсов, имя планировщика, регион и номер SKU. Выберите Review + create.

4. После прохождения проверки выберите Создать. Развертывание занимает до 15 минут.

5. После создания планировщика откройте ресурс планировщика. На странице "Обзор" создайте новый концентратор задач.

Azure CLI

1. Установите или обновите расширение CLI планировщика устойчивых задач.

   az extension add --name durabletask
   az extension update --name durabletask
   

2. Создайте группу ресурсов (при необходимости).

   az group create --name YOUR_RESOURCE_GROUP --location LOCATION
   

3. Создайте планировщик.

   az durabletask scheduler create \
     --name "YOUR_SCHEDULER" \
     --resource-group "YOUR_RESOURCE_GROUP" \
     --location "LOCATION" \
     --ip-allowlist "[0.0.0.0/0]" \
     --sku-name "dedicated" \
     --sku-capacity "1"
   

4. Создайте концентратор задач в планировщике.

   az durabletask taskhub create \
     --resource-group YOUR_RESOURCE_GROUP \
     --scheduler-name YOUR_SCHEDULER \
     --name YOUR_TASKHUB
   

Диспетчер ресурсов Azure

Разверните планировщик и концентратор задач с помощью REST API ARM.

1. Создайте планировщик.

   PUT https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.DurableTask/schedulers/SCHEDULER_NAME?api-version=2025-04-01-preview
   
   {
     "location": "LOCATION",
     "properties": {
       "ipAllowlist": ["0.0.0.0/0"],
       "sku": {
         "name": "Dedicated",
         "capacity": 1
       }
     }
   }
   

2. Создайте концентратор задач в планировщике.

   PUT https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.DurableTask/schedulers/SCHEDULER_NAME/taskHubs/TASKHUB_NAME?api-version=2025-04-01-preview
   
   {
     "properties": {}
   }
   

Бицепс

Определите планировщик и концентратор задач в шаблоне Bicep.

@description('The name of the Durable Task Scheduler.')
param schedulerName string

@description('The name of the task hub.')
param taskHubName string

@description('The location for all resources.')
param location string = resourceGroup().location

resource scheduler 'Microsoft.DurableTask/schedulers@2025-04-01-preview' = {
  name: schedulerName
  location: location
  properties: {
    ipAllowlist: [
      '0.0.0.0/0'
    ]
    sku: {
      name: 'Dedicated'
      capacity: 1
    }
  }
}

resource taskHub 'Microsoft.DurableTask/schedulers/taskHubs@2025-04-01-preview' = {
  parent: scheduler
  name: taskHubName
  properties: {}
}

Это важно

Список допустимых IP-адресов 0.0.0.0/0 позволяет доступ с любого IP-адреса. Для рабочих развертываний это ограничивается только необходимыми диапазонами IP-адресов.

В предыдущих примерах используется выделенный номер SKU. Планировщик устойчивых задач также предлагает номер SKU потребления. Дополнительные сведения об управлении ресурсами планировщика устойчивых задач см. в статье "Разработка с помощью планировщика устойчивых задач".

Настройка проверки подлинности на основе удостоверений

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

Доступны следующие роли:

Роль	Описание
Участник данных для долговременных задач	Полный доступ к данным. Супермножество всех остальных ролей.
Исполнитель устойчивых задач	Взаимодействуйте с планировщиком для обработки оркестраций, активностей и сущностей.
Средство чтения данных устойчивых задач	Доступ только для чтения к данным оркестрации и объектам.

Замечание

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

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

Портал Azure

1. Перейдите к ресурсу планировщика или концентратора задач на портале Azure.

2. В меню слева выберите Управление доступом (IAM).

3. Выберите Добавить>Добавить назначение ролей.

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

5. Чтобы назначить доступ, выберите управляемое удостоверение. Выберите и выберите участников.

6. Выберите пользователем назначаемое управляемое удостоверение, выберите удостоверение и нажмите кнопку "Выбрать".

7. Нажмите кнопку "Проверка и назначение " для завершения.

8. Перейдите в ваше приложение функции и выберите Параметры>Идентификация. Выберите вкладку "Назначаемый пользователем" и добавьте удостоверение.

Azure CLI

1. Создайте управляемый идентификатор, назначенный пользователем.

   az identity create -g YOUR_RESOURCE_GROUP -n YOUR_IDENTITY_NAME
   

2. Назначьте идентификатору роль Durable Task Data Contributor, в рамках планировщика или концентратора задач.

   assignee=$(az identity show --name YOUR_IDENTITY_NAME --resource-group YOUR_RESOURCE_GROUP --query 'clientId' --output tsv)
   
   scope="/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RESOURCE_GROUP/providers/Microsoft.DurableTask/schedulers/YOUR_SCHEDULER"
   
   az role assignment create \
     --assignee "$assignee" \
     --role "Durable Task Data Contributor" \
     --scope "$scope"
   

3. Назначьте удостоверение функциональному приложению.

   resource_id=$(az resource show --resource-group YOUR_RESOURCE_GROUP --name YOUR_IDENTITY_NAME --resource-type Microsoft.ManagedIdentity/userAssignedIdentities --query id --output tsv)
   
   az functionapp identity assign \
     --resource-group YOUR_RESOURCE_GROUP \
     --name YOUR_FUNCTION_APP \
     --identities "$resource_id"
   

Диспетчер ресурсов Azure

Создайте назначение роли для управляемой идентичности с помощью ARM REST API.

PUT https://management.azure.com/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.DurableTask/schedulers/SCHEDULER_NAME/providers/Microsoft.Authorization/roleAssignments/ROLE_ASSIGNMENT_ID?api-version=2022-04-01

{
  "properties": {
    "roleDefinitionId": "/subscriptions/SUBSCRIPTION_ID/providers/Microsoft.Authorization/roleDefinitions/ROLE_DEFINITION_ID",
    "principalId": "MANAGED_IDENTITY_PRINCIPAL_ID",
    "principalType": "ServicePrincipal"
  }
}

Подсказка

Чтобы найти идентификатор определения роли для Участник данных долговечных задач, выполните следующую команду: az role definition list --name "Durable Task Data Contributor" --query "[0].id" -o tsv

Бицепс

Добавьте назначение ролей в шаблон Bicep.

@description('The principal ID of the managed identity.')
param identityPrincipalId string

@description('The Durable Task Data Contributor role definition ID.')
var durableTaskDataContributorRoleId = subscriptionResourceId(
  'Microsoft.Authorization/roleDefinitions',
  'ROLE_DEFINITION_ID'
)

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(scheduler.id, identityPrincipalId, durableTaskDataContributorRoleId)
  scope: scheduler
  properties: {
    roleDefinitionId: durableTaskDataContributorRoleId
    principalId: identityPrincipalId
    principalType: 'ServicePrincipal'
  }
}

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

Variable	Ценность
TASKHUB_NAME	Имя центра задач.
DURABLE_TASK_SCHEDULER_CONNECTION_STRING	Endpoint={scheduler endpoint};Authentication=ManagedIdentity;ClientID={client id}

Замечание

Если вы используете управляемое удостоверение, назначаемое системой, исключите сегмент ClientID из строки подключения: Endpoint={scheduler endpoint};Authentication=ManagedIdentity.

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

Несколько приложений

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

Управление концентратором задач поставщика хранилища BYO

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

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

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

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

Замечание

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

Подсказка

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

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

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

Это важно

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

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

Замечание

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

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

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

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

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

• При использовании поставщика Azure Storage состояния экземпляра хранятся в таблице Instance Table и History Table, которые можно проверить с помощью таких средств, как Azure Storage Explorer.
• Если вы используете поставщик хранилища MSSQL, используйте запросы и средства SQL для проверки содержимого концентратора задач в базе данных.

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

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

Пакеты SDK Durable Task используют планировщик Durable Task в качестве серверной части, которая управляет состоянием центра задач во внутренней системе.

Поставщик планировщика устойчивых задач

Durable Task Scheduler — это полностью управляемый бэкенд-провайдер, который хранит все внутренние состояния узла задач. В отличие от поставщиков хранилища BYO, вам не нужно настраивать базовую инфраструктуру хранилища или управлять ими. Каждый ресурс планировщика (Microsoft.DurableTask/schedulers) имеет выделенные вычислительные ресурсы и ресурсы памяти и может содержать один или несколько центров задач (Microsoft.DurableTask/schedulers/taskHubs).

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

Дополнительные сведения о вариантах поставщиков хранилища BYO и их сравнении см. в разделе Поставщики хранилища для Durable Functions.

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

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

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

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

В следующих разделах подробно описаны эти компоненты и их роли.

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

Поставщик хранилища Netherite (путь выхода на пенсию)

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

• Один Azure Storage контейнер больших двоичных объектов, содержащий все большие двоичные объекты, сгруппированные по секциям.
• Одна таблица Azure, содержащая опубликованные метрики о разделах.
• Пространство имен Azure Event Hubs для доставки сообщений между секциями.

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

Замечание

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

Netherite использует механизм обеспечения событий, основанный на журналах и контрольных точках, для представления текущего состояния секции. Оба блочных BLOB-объектов и страничных 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)

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

host.json (Функции 1.x)

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

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

host.json (Функции 1.x)

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

host.json (Функции 2.0)

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

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

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

Замечание

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

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

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);
}

Замечание

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

JavaScript

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

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

Замечание

Этот пример предназначен для Durable Functions версии 2.x. В версии 1.x используйте orchestrationClient вместо durableClient.

Python

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

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

Замечание

Этот пример предназначен для Durable Functions версии 2.x. В версии 1.x используйте orchestrationClient вместо durableClient.

PowerShell

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

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

Замечание

Этот пример предназначен для Durable Functions версии 2.x. В версии 1.x используйте orchestrationClient вместо durableClient.

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.json .

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

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

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

Замечание

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

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

Узнайте, как работать с версионированием оркестрации

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

Начало работы с Durable Task SDK