Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Расширение Устойчивых функций вводит три привязки-триггеры, которые управляют выполнением функций оркестратора, действий и сущностей. Она также вводит выходную привязку, которая функционирует как клиент среды выполнения Durable Functions.
В этой статье рассматривается использование этих четырех привязок и приведены примеры кода. Он также содержит сведения о свойствах конфигурации устойчивых функций в host.json, файле метаданных, который содержит параметры, влияющие на все функции в приложении-функции.
Выберите язык разработки устойчивых функций в верхней части статьи.
Обе версии модели программирования Python для функций Azure поддерживаются устойчивыми функциями. Так как Python v2 является рекомендуемой, примеры в этой статье представлены исключительно в этой версии.
Предпосылки
- Пакет Durable Functions SDK, который является пакетом
azure-functions-durablePython Package Index (PyPI), версии1.2.2или более поздней версии. - Пакет расширений версии 4.x (или более поздняя версия), который устанавливается в файле проекта host.json
Вы можете предоставить отзывы и предложения в пакете SDK устойчивых функций для репозитория Python.
Триггер оркестрации
Триггер оркестрации можно использовать для разработки устойчивых функций оркестратора. Этот триггер выполняется в момент, когда планируется новый экземпляр оркестрации, и в момент, когда существующий экземпляр оркестрации получает событие. Примеры событий, которые могут активировать функции оркестратора, включают истечения срока действия долговечного таймера, ответы функций активности и события, вызываемые внешними клиентами.
При разработке функций в .NET используйте атрибут OrchestrationTriggerAttribute .NET для настройки триггера оркестрации.
Для Java используется аннотация @DurableOrchestrationTrigger для настройки триггера оркестрации.
При использовании версии 4 модели программирования Node.js для разработки функций вы импортируете app объект из @azure/functions npm модуля. Затем вы вызываете app.orchestration метод API устойчивых функций непосредственно в коде функции. Этот метод регистрирует функцию оркестратора в платформе устойчивых функций.
При записи функций оркестратора необходимо определить триггер оркестрации с помощью следующего объекта JSON в массиве bindings файла function.json :
{
"name": "<name-of-input-parameter-in-function-signature>",
"orchestration": "<optional-name-of-orchestration>",
"type": "orchestrationTrigger",
"direction": "in"
}
Значением orchestration является имя оркестрации, которую клиенты должны использовать при запуске новых экземпляров функции оркестратора. Это свойство является необязательным. Если он не указан, используется имя функции.
При использовании модели программирования Python версии 2 можно определить триггер оркестрации с помощью orchestration_trigger декоратора непосредственно в коде функции Python.
В модели версии 2 вы обращаетесь к триггерам и привязкам устойчивых функций из экземпляра DFApp. Этот подкласс FunctionApp можно использовать для экспорта декораторов, относящихся к устойчивым функциям.
Внутри этого триггера привязка проверяет настроенное долгосрочное хранилище на наличие новых событий управления оркестрацией. Примеры событий включают события запуска оркестрации, события истечения срока действия таймера, события ответа функции активности и внешние события, вызванные другими функциями.
Поведение триггера
Ниже приведены некоторые заметки о триггере оркестрации:
- Однопоточность: Один диспетчерский поток используется для выполнения всех функций оркестратора в одном узле. По этой причине важно убедиться, что код функции оркестратора эффективен и не выполняет никаких операций ввода-вывода. Кроме того, важно убедиться, что этот поток не выполняет асинхронную работу, за исключением случаев ожидания типов задач, относящихся к устойчивым функциям.
- Обработка ядовитых сообщений: в триггерах оркестрации нет поддержки ядовитых сообщений.
- Видимость сообщений: оркестрационные триггерные сообщения извлекаются из очереди и остаются невидимыми в течение настраиваемой длительности. Видимость этих сообщений обновляется автоматически, пока приложение-функция работает исправно.
- Возвращаемые значения: возвращаемые значения сериализуются в JSON и сохраняются в таблице журнала оркестрации в хранилище таблиц Azure. Эти возвращаемые значения можно запросить с помощью привязки клиентского оркестратора, которая будет описана далее.
Предупреждение
Функции оркестратора никогда не должны использовать входные или выходные привязки, отличные от привязки триггера оркестрации. Использование других привязок может вызвать проблемы с расширением Durable Task, так как эти привязки могут не подчиняться правилам однопоточности и ввода-вывода. Если вы хотите использовать другие привязки, добавьте их в функцию действия, вызванную из функции оркестратора. Дополнительные сведения о ограничениях кода для функций оркестратора см. в разделе "Ограничения кода функции Orchestrator".
Предупреждение
Функции оркестратора никогда не должны объявляться async.
Использование триггера
Привязка (биндинг) триггера оркестрации поддерживает входные и выходные данные. Ниже приведены некоторые заметки о обработке входных и выходных данных:
- Входные данные: можно вызвать триггеры оркестрации, имеющие входные данные. Входные данные доступны через объект входных данных контекста. Все входные данные должны быть сериализуемыми в формате JSON.
- Выходные данные: триггеры оркестрации поддерживают как входные, так и выходные значения. Возвращаемое значение функции используется для назначения выходного значения. Возвращаемое значение должно быть сериализуемым в формате JSON.
Пример триггера
В следующем коде представлен пример базовой функции оркестратора Hello World . В этом примере оркестратор не планирует никаких задач.
Атрибут, используемый для определения триггера, зависит от того, выполняете ли функции C# в том же процессе, что и процесс хоста функций или в изолированном рабочем процессе.
[FunctionName("HelloWorld")]
public static string RunOrchestrator([OrchestrationTrigger] IDurableOrchestrationContext context)
{
string name = context.GetInput<string>();
return $"Hello {name}!";
}
Примечание.
Предыдущий код предназначен для устойчивых функций 2.x. Для Durable Functions 1.x необходимо использовать DurableOrchestrationContext вместо IDurableOrchestrationContext. Дополнительные сведения о различиях между версиями см. в обзоре версий устойчивых функций.
const { app } = require('@azure/functions');
const df = require('durable-functions');
df.app.orchestration('helloOrchestrator', function* (context) {
const name = context.df.getInput();
return `Hello ${name}`;
});
Примечание.
Библиотека durable-functions вызывает синхронный context.done метод при выходе функции генератора.
import azure.functions as func
import azure.durable_functions as df
myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@myApp.orchestration_trigger(context_name="context")
def my_orchestrator(context):
result = yield context.call_activity("Hello", "Tokyo")
return result
param($Context)
$InputData = $Context.Input
$InputData
@FunctionName("HelloWorldOrchestration")
public String helloWorldOrchestration(
@DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
return String.format("Hello %s!", ctx.getInput(String.class));
}
Большинство функций оркестратора вызывают функции действия. В следующем коде представлен пример Hello World , демонстрирующий вызов функции действия:
[FunctionName("HelloWorld")]
public static async Task<string> RunOrchestrator(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
string name = context.GetInput<string>();
string result = await context.CallActivityAsync<string>("SayHello", name);
return result;
}
Примечание.
Предыдущий код предназначен для устойчивых функций 2.x. Для Durable Functions 1.x необходимо использовать DurableOrchestrationContext вместо IDurableOrchestrationContext. Дополнительные сведения о различиях между версиями см. в обзоре версий устойчивых функций.
const { app } = require('@azure/functions');
const df = require('durable-functions');
const activityName = 'hello';
df.app.orchestration('helloOrchestrator', function* (context) {
const name = context.df.getInput();
const result = yield context.df.callActivity(activityName, name);
return result;
});
@FunctionName("HelloWorld")
public String helloWorldOrchestration(
@DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
String input = ctx.getInput(String.class);
String result = ctx.callActivity("SayHello", input, String.class).await();
return result;
}
Триггер действия
Триггер действия можно использовать для разработки функций, называемых функциями действий , которые вызываются функциями оркестратора.
Для настройки триггера действия используется атрибут ActivityTriggerAttribute .NET.
С помощью заметки @DurableActivityTrigger можно настроить триггер действия.
Чтобы зарегистрировать функцию действия, импортируйте app объект из @azure/functions npm модуля. Затем вы вызываете app.activity метод API устойчивых функций непосредственно в коде функции.
Чтобы определить триггер действия, используйте следующий объект JSON в массиве bindingsfunction.json:
{
"name": "<name-of-input-parameter-in-function-signature>",
"activity": "<optional-name-of-activity>",
"type": "activityTrigger",
"direction": "in"
}
Значением activity является имя действия. Это значение — имя, используемое функциями оркестратора для вызова этой функции действия. Это свойство является необязательным. Если он не указан, используется имя функции.
Триггер действия можно определить с помощью activity_trigger декоратора непосредственно в коде функции Python.
В этой триггерной привязке система опрашивает настроенное устойчивое хранилище на предмет новых событий выполнения активности.
Поведение триггера
Ниже приведены некоторые заметки о триггере действия:
- Потоки. В отличие от триггера оркестрации, триггеры действий не имеют ограничений на потоки или операции ввода-вывода. Их можно рассматривать как обычные функции.
- Обработка подозрительных сообщений: в триггерах активности нет поддержки подозрительных сообщений.
- Видимость сообщения: сообщения триггеров активности извлекаются из очереди и сохраняются невидимыми в течение настраиваемой продолжительности. Видимость этих сообщений обновляется автоматически, пока приложение-функция работает исправно.
- Возвращаемые значения: возвращаемые значения сериализуются в JSON и сохраняются в настроенном устойчивом хранилище.
Использование триггера
Привязка триггера действия поддерживает как входные данные, так и выходные, как и триггер оркестрации. Ниже приведены некоторые заметки о обработке входных и выходных данных:
- Входные данные: триггеры действий можно вызывать с помощью входных данных из функции оркестратора. Все входные данные должны быть сериализуемыми в формате JSON.
- Выходные данные: функции действий поддерживают как выходные, так и входные значения. Возвращаемое значение функции используется для назначения выходного значения и должно быть сериализуемым в формате JSON.
-
Метаданные: функции активности .NET могут использовать параметр
string instanceId, чтобы получить идентификатор экземпляра вызывающей оркестрации.
Пример триггера
В следующем коде представлен пример базовой функции действия Hello World .
[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] IDurableActivityContext helloContext)
{
string name = helloContext.GetInput<string>();
return $"Hello {name}!";
}
Тип параметра по умолчанию для привязки .NET ActivityTriggerAttribute — IDurableActivityContext (или DurableActivityContext для устойчивых функций 1.x). Однако триггеры действий .NET также поддерживают привязку непосредственно к сериализуемым типам JSON (включая примитивные типы), поэтому можно также использовать следующую упрощенную версию функции:
[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] string name)
{
return $"Hello {name}!";
}
const { app } = require('@azure/functions');
const df = require('durable-functions');
const activityName = 'hello';
df.app.activity(activityName, {
handler: (input) => {
return `Hello, ${input}`;
},
});
import azure.functions as func
import azure.durable_functions as df
myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@myApp.activity_trigger(input_name="myInput")
def my_activity(myInput: str):
return "Hello " + myInput
param($name)
"Hello $name!"
@FunctionName("SayHello")
public String sayHello(@DurableActivityTrigger(name = "name") String name) {
return String.format("Hello %s!", name);
}
Использование входных и выходных привязок
Помимо привязки триггера действия можно также использовать обычные входные и выходные привязки.
Например, функция действия может получать входные данные из функции оркестратора. Затем функция активности может отправлять эти входные данные в центры событий Azure.
const { app } = require('@azure/functions');
const df = require('durable-functions');
df.app.orchestration('helloOrchestrator', function* (context) {
const input = context.df.getInput();
yield context.df.callActivity('sendToEventHub', input);
return `Message sent: ${input}`;
});
const { EventHubProducerClient } = require("@azure/event-hubs");
const connectionString = process.env.EVENT_HUB_CONNECTION_STRING;
const eventHubName = process.env.EVENT_HUB_NAME;
df.app.activity("sendToEventHub", {
handler: async (message, context) => {
const producer = new EventHubProducerClient(connectionString, eventHubName);
try {
const batch = await producer.createBatch();
batch.tryAdd({ body: message });
await producer.sendBatch(batch);
context.log(`Message sent to Event Hubs: ${message}`);
} catch (err) {
context.log.error("Failed to send message to Event Hubs:", err);
throw err;
} finally {
await producer.close();
}
},
});
app.storageQueue('helloQueueStart', {
queueName: 'start-orchestration',
extraInputs: [df.input.durableClient()],
handler: async (message, context) => {
const client = df.getClient(context);
const orchestratorName = message.orchestratorName || 'helloOrchestrator';
const input = message.input || null;
const instanceId = await client.startNew(orchestratorName, { input });
context.log(`Started orchestration with ID = '${instanceId}'`);
},
});
Клиент для оркестрации систем
Вы можете использовать привязку клиента оркестрации для записи функций, взаимодействующих с функциями оркестратора. Эти функции часто называются клиентскими функциями. Например, вы можете выполнять действия с экземплярами оркестрации следующими методами:
- Запустите их.
- Запросить их статус.
- Устраните их.
- Отправка событий им, пока они выполняются.
- Очистить историю экземпляров.
Вы можете привязаться к клиенту оркестрации с помощью атрибута DurableClientAttribute (OrchestrationClientAttribute в Устойчивых функциях 1.x).
Вы можете привязаться к клиенту оркестрации с помощью аннотации @DurableClientInput.
Чтобы зарегистрировать клиентную функцию, импортируйте app объект из @azure/functions npm модуля. Затем вы вызываете метод API устойчивых функций, который зависит от типа триггера. Например, для триггера HTTP вызывается app.http метод. Для триггера очереди вызывается app.storageQueue метод.
Чтобы определить устойчивый триггер клиента, используйте следующий объект JSON в массиве bindingsfunction.json:
{
"name": "<name-of-input-parameter-in-function-signature>",
"taskHub": "<optional-name-of-task-hub>",
"connectionName": "<optional-name-of-connection-string-app-setting>",
"type": "orchestrationClient",
"direction": "in"
}
- Это
taskHubсвойство используется, если несколько приложений-функций используют одну и ту же учетную запись хранения, но их необходимо изолировать друг от друга. Если это свойство не указано, используется значение по умолчанию из host.json . Это значение должно соответствовать значению, используемому целевыми функциями оркестратора. - Значением
connectionNameявляется имя параметра приложения, содержащего строку подключения учетной записи хранения. Учетная запись хранения, связанная с этой строкой подключения, должна совпадать с той, которую используют функции целевого оркестратора. Если это свойство не указано, используется строка подключения учетной записи хранения по умолчанию для функционального приложения.
Примечание.
В большинстве случаев рекомендуется опустить эти свойства и полагаться на поведение по умолчанию.
Вы можете определить устойчивый триггер клиента с помощью durable_client_input декоратора непосредственно в коде функции Python.
Использование клиента
Обычно выполняется привязка к реализации IDurableClient (DurableOrchestrationClient в Durable Functions версии 1.x), которая обеспечивает полный доступ ко всем API клиента оркестрации, поддерживаемым Durable Functions.
Обычно вы привязываетесь к классу DurableClientContext.
Чтобы получить доступ к объекту клиента, необходимо использовать пакет SDK для конкретного языка.
В следующем коде представлен пример функции, активируемой очередью, которая запускает оркестрацию Hello World.
[FunctionName("QueueStart")]
public static Task Run(
[QueueTrigger("durable-function-trigger")] string input,
[DurableClient] IDurableOrchestrationClient starter)
{
// Orchestration input comes from the queue message content.
return starter.StartNewAsync<string>("HelloWorld", input);
}
Примечание.
Предыдущий код C# предназначен для устойчивых функций 2.x. Для устойчивых функций 1.x необходимо использовать атрибут OrchestrationClient вместо атрибута DurableClient, а тип параметра DurableOrchestrationClient вместо IDurableOrchestrationClient. Дополнительные сведения о различиях между версиями см. в обзоре версий устойчивых функций.
const { app } = require('@azure/functions');
const df = require('durable-functions');
app.storageQueue('helloQueueStart', {
queueName: 'start-orchestration',
extraInputs: [df.input.durableClient()],
handler: async (message, context) => {
const client = df.getClient(context);
const orchestratorName = message.orchestratorName || 'helloOrchestrator';
const input = message.input || null;
const instanceId = await client.startNew(orchestratorName, { input });
context.log(`Started orchestration with ID = '${instanceId}' from queue message.`);
},
});
import azure.functions as func
import azure.durable_functions as df
myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@myApp.queue_trigger(
arg_name="msg",
queue_name="start-orchestration",
connection="AzureWebJobsStorage"
)
@myApp.durable_client_input(client_name="client")
async def client_function(msg: func.QueueMessage, client: df.DurableOrchestrationClient):
input_data = msg.get_body().decode("utf-8")
await client.start_new("my_orchestrator", None, input_data)
return None
function.json
{
"bindings": [
{
"name": "InputData",
"type": "queueTrigger",
"queueName": "durable-function-trigger",
"direction": "in"
},
{
"name": "starter",
"type": "durableClient",
"direction": "in"
}
]
}
run.ps1
param([string]$InputData, $TriggerMetadata)
$InstanceId = Start-DurableOrchestration -FunctionName 'HelloWorld' -Input $InputData
@FunctionName("QueueStart")
public void queueStart(
@QueueTrigger(name = "input", queueName = "durable-function-trigger", connection = "Storage") String input,
@DurableClientInput(name = "durableContext") DurableClientContext durableContext) {
// Orchestration input comes from the queue message content.
durableContext.getClient().scheduleNewOrchestrationInstance("HelloWorld", input);
}
Подробные сведения о запуске экземпляров см. в статье "Управление экземплярами в устойчивых функциях" в Azure.
Триггер сущности
Триггер сущности можно использовать для разработки функции сущности. Этот триггер поддерживает обработку событий для конкретного экземпляра сущности.
Примечание.
Триггеры сущностей доступны начиная с устойчивых функций 2.x.
Внутренне, эта триггерная привязка инспектирует настроенное длительно сохраняющее хранилище для новых операций сущностей, которые необходимо выполнить.
Для настройки триггера сущности используется атрибут EntityTriggerAttribute .NET.
Чтобы зарегистрировать триггер сущности, импортируйте объект app из модуля @azure/functions npm. Затем вы вызываете app.entity метод API устойчивых функций непосредственно в коде функции.
const df = require('durable-functions');
df.app.entity('counter', (context) => {
const currentValue = context.df.getState(() => 0);
switch (context.df.operationName) {
case 'add':
context.df.setState(currentValue + context.df.getInput());
break;
case 'reset':
context.df.setState(0);
break;
case 'get':
context.df.return(currentValue);
break;
}
});
Примечание.
Триггеры сущностей пока не поддерживаются для Java.
Примечание.
Триггеры сущностей пока не поддерживаются для PowerShell.
Триггер сущности можно определить с помощью entity_trigger декоратора непосредственно в коде функции Python.
Поведение триггера
Несколько заметок о триггере объекта:
- Однопоточный режим: один поток диспетчера используется для обработки операций для конкретной сущности. Если несколько сообщений отправляются в одну сущность одновременно, операции обрабатываются одновременно.
- Обработка подозрительных сообщений: в триггерах сущностей нет поддержки подозрительных сообщений.
- Видимость сообщения: сообщения триггера сущности выталкиваются из очереди и остаются невидимыми на заданное время. Видимость этих сообщений обновляется автоматически, пока приложение-функция работает исправно.
- Возвращаемые значения: функции сущностей не поддерживают возвращаемые значения. Существуют специфические API, которые можно использовать для сохранения состояния, или передачи значений обратно в оркестрации.
Все изменения состояния, внесенные в сущность во время его выполнения, автоматически сохраняются после завершения выполнения.
Дополнительные сведения и примеры определения и взаимодействия с триггерами сущностей см. в разделе "Функции сущности".
Клиент организации
Вы можете использовать привязку клиента сущности для асинхронной активации функций сущностей. Эти функции иногда называются клиентскими функциями.
Вы можете привязаться к клиенту сущности с помощью атрибута DurableClientAttribute .NET в функциях библиотеки классов .NET.
Примечание.
Вы также можете использовать [DurableClientAttribute] для привязки к клиенту оркестрации.
Вместо регистрации клиента сущности, вы используете signalEntity или callEntity, чтобы вызвать метод триггера сущности из любой зарегистрированной функции.
Из функции, триггеруемой очередью, можно использовать
client.signalEntity:const { app } = require('@azure/functions'); const df = require('durable-functions'); app.storageQueue('helloQueueStart', { queueName: 'start-orchestration', extraInputs: [df.input.durableClient()], handler: async (message, context) => { const client = df.getClient(context); const entityId = new df.EntityId('counter', 'myCounter'); await client.signalEntity(entityId, 'add', 5); }, });Из функции оркестратора можно использовать
context.df.callEntity:const { app } = require('@azure/functions'); const df = require('durable-functions'); df.app.orchestration('entityCaller', function* (context) { const entityId = new df.EntityId('counter', 'myCounter'); yield context.df.callEntity(entityId, 'add', 5); yield context.df.callEntity(entityId, 'add', 5); const result = yield context.df.callEntity(entityId, 'get'); return result; });
Клиента сущности можно определить с помощью durable_client_input декоратора непосредственно в функции на Python.
Примечание.
Клиенты сущностей пока не поддерживаются для Java.
Примечание.
Клиенты сущностей пока не поддерживаются для PowerShell.
Дополнительные сведения и примеры взаимодействия с сущностями в качестве клиента см. в разделе "Доступ".
Параметры устойчивых функций в host.json
В этом разделе содержатся сведения о свойствах конфигурации устойчивых функций в host.json. Сведения об общих параметрах в host.jsonсм. в host.json справочнике по функциям Azure 1.x или host.json справочнике по функциям Azure 2.x и более поздних версий.
Параметры конфигурации для устойчивых функций.
Примечание.
Все основные версии Устойчивых функций поддерживаются во всех версиях среды выполнения Функций Azure. Однако схема конфигурации host.json немного отличается в зависимости от версии среды выполнения Функций Azure и версии используемого расширения устойчивых функций.
Следующий код содержит два примера durableTask параметров в host.json: один для устойчивых функций 2.x и один для устойчивых функций 1.x. Вы можете использовать оба примера с функциями Azure 2.0 и 3.0. При использовании Azure Functions 1.0 доступные параметры одинаковы, но раздел host.json расположен в корне конфигурации host.json, а не является полем в разделе extensions.
{
"extensions": {
"durableTask": {
"hubName": "MyTaskHub",
"defaultVersion": "1.0",
"versionMatchStrategy": "CurrentOrOlder",
"versionFailureStrategy": "Reject",
"storageProvider": {
"connectionStringName": "AzureWebJobsStorage",
"controlQueueBatchSize": 32,
"controlQueueBufferThreshold": 256,
"controlQueueVisibilityTimeout": "00:05:00",
"FetchLargeMessagesAutomatically": true,
"maxQueuePollingInterval": "00:00:30",
"partitionCount": 4,
"trackingStoreConnectionStringName": "TrackingStorage",
"trackingStoreNamePrefix": "DurableTask",
"useLegacyPartitionManagement": false,
"useTablePartitionManagement": true,
"workItemQueueVisibilityTimeout": "00:05:00",
"QueueClientMessageEncoding": "UTF8"
},
"tracing": {
"traceInputsAndOutputs": false,
"traceReplayEvents": false,
},
"notifications": {
"eventGrid": {
"topicEndpoint": "https://topic_name.westus2-1.eventgrid.azure.net/api/events",
"keySettingName": "EventGridKey",
"publishRetryCount": 3,
"publishRetryInterval": "00:00:30",
"publishEventTypes": [
"Started",
"Completed",
"Failed",
"Terminated"
]
}
},
"maxConcurrentActivityFunctions": 10,
"maxConcurrentOrchestratorFunctions": 10,
"maxConcurrentEntityFunctions": 10,
"extendedSessionsEnabled": false,
"extendedSessionIdleTimeoutInSeconds": 30,
"useAppLease": true,
"useGracefulShutdown": false,
"maxEntityOperationBatchSize": 50,
"maxOrchestrationActions": 100000,
"storeInputsInOrchestrationHistory": false
}
}
}
| Недвижимость | Значение по умолчанию | Описание |
|---|---|---|
| имя узла | TestHubName (DurableFunctionsHub в версии 1.x) | Имя концентратора, в который хранится текущее состояние приложения-функции. Имена центров задач должны начинаться с буквы и содержать только буквы и цифры. Если имя не указано, используется значение по умолчанию. Альтернативные имена концентраторов задач можно использовать для изоляции нескольких приложений устойчивых функций друг от друга, даже если они используют одну и ту же серверную часть хранилища. Дополнительные сведения см. в разделе "Центры задач". |
| defaultVersion | Версия по умолчанию для присваивания новым экземплярам оркестрации. При указании версии новые экземпляры оркестрации навсегда связаны с этим значением версии. Этот параметр используется функцией оркестрации версий для включения таких сценариев, как развертывания без времени простоя с критическими изменениями. Для версии можно использовать любое строковое значение. | |
| стратегияСопоставленияВерсий | ТекущаяИлиБолееСтарая | Значение, определяющее, как осуществляется сопоставление версий оркестрации при загрузке функций оркестратора. Допустимые значения: None, Strictи CurrentOrOlder. Подробные объяснения см. в разделе "Управление версиями". |
| Стратегия обработки отказов версий | Отклонение | Значение, указывающее, что происходит, если версия оркестрации не соответствует текущему defaultVersion значению. Допустимые значения — Reject и Fail. Подробные объяснения см. в разделе "Управление версиями". |
| controlQueueBatchSize | 32 | Количество сообщений, которые нужно извлечь из очереди управления за раз. |
| контрольный порог буфера очереди |
План потребления для Python: 32 План потребления для других языков: 128 Выделенный или премиум план: 256 |
Количество сообщений очереди управления, которые можно буферизовать в памяти одновременно. По достижении указанного числа диспетчер ожидает, прежде чем удалить другие сообщения из очереди. В некоторых ситуациях снижение этого значения может значительно снизить потребление памяти. |
| Количество разделов | 4 | Количество разделов для очереди управления. Это значение должно быть положительным целым числом от 1 до 16. Изменение этого значения требует настройки нового концентратора задач. |
| управление тайм-аутом видимости очереди | 00:05:00 | Время ожидания видимости сообщений из управляющей очереди в формате hh:mm:ss. |
| workItemQueueVisibilityTimeout (таймаут видимости очереди рабочих элементов) | 00:05:00 | Время ожидания видимости сообщений очереди рабочих элементов в формате hh:mm:ss . |
| АвтоматическиЗагружатьБольшиеСообщения | правда | Значение, указывающее, нужно ли получать большие сообщения в запросах состояния оркестрации. Если этот параметр задан true, извлекаются большие сообщения, превышающие ограничение размера очереди. Если этот параметр задан false, извлекается URL-адрес блоба, указывающий на каждое большое сообщение. |
| максимальное количество параллельных функций активности |
План потребления: 10 Выделенный или премиум-план: 10 раз больше процессоров на текущем компьютере |
Максимальное число функций активности, которые могут одновременно обрабатываться на одном экземпляре узла. |
| максимальное количество одновременно работающих оркестровщиков (maxConcurrentOrchestratorFunctions) |
План потребления: 5 Выделенный или премиум-план: 10 раз больше процессоров на текущем компьютере |
Максимальное количество функций оркестратора, которые могут быть обработаны одновременно на одной хостовой инстанции. |
| Максимальное количество одновременных функций сущности |
План потребления: 5 Выделенный или премиум-план: 10 раз больше процессоров на текущем компьютере |
Максимальное количество функций сущностей, которые могут обрабатываться одновременно на одном экземпляре узла. Этот параметр применим только при использовании планировщика устойчивых задач. В противном случае максимальное число параллельных выполнений сущностей ограничено значением maxConcurrentOrchestratorFunctions . |
| максимальный интервал опроса очереди | 00:00:30 | Максимальный интервал опроса очереди рабочих элементов в формате hh:mm:ss. Высокие значения могут привести к увеличению задержек при обработке сообщений. Низкие значения могут привести к повышению затрат на хранение из-за увеличенного объема транзакций с хранилищем. |
| maxOrchestrationActions | 100,000 | Максимальное количество действий, выполняемых функцией оркестратора, может выполняться в течение одного цикла выполнения. |
| connectionName (версия 2.7.0 и более поздние версии) connectionStringName (v2.x) azureStorageConnectionStringName (v1.x) |
AzureWebJobsStorage | Имя параметра или коллекции параметров приложения, указывающих, как подключиться к базовым ресурсам службы хранилища Azure. Если вы предоставляете один параметр приложения, это должна быть строка подключения к службе хранилища Azure. |
| trackingStoreConnectionName (версия 2.7.0 и более поздние версии) trackingStoreConnectionStringName |
Имя параметра или коллекции параметров приложения, указывает, как подключиться к таблицам Истории и Экземпляров, где хранятся история выполнения и метаданные об экземплярах оркестрации. Если вы предоставляете один параметр приложения, это должна быть строка подключения к службе хранилища Azure. Если вы не укажете параметр, будет использовано соединение со значением connectionStringName (v2.x) или azureStorageConnectionStringName (v1.x). |
|
| trackingStoreNamePrefix | Префикс, который необходимо использовать для таблиц Истории и Экземпляров, когда задано значение trackingStoreConnectionStringName. Если префикс не указан, используется значение DurableTask по умолчанию. Если trackingStoreConnectionStringName не указано, таблицы истории и экземпляров используют значение hubName в качестве префикса, а параметр trackingStoreNamePrefix игнорируется. |
|
| traceInputsAndOutputs (проследитьВходыИВыходы) | неправда | Значение, указывающее, следует ли отслеживать входные и выходные данные вызовов функций. При трассировке событий выполнения функции поведение по умолчанию заключается в том, чтобы включить количество байтов в сериализованные входные и выходные данные для вызовов функций. Это поведение обеспечивает минимальную информацию о входных и выходных данных, чтобы не перегружать журналы или непреднамеренно раскрывать конфиденциальную информацию. Если это свойство имеет значение true, все содержимое входных и выходных данных функции регистрируется. |
| отслеживание событий воспроизведения | неправда | Значение, указывающее, следует ли записывать события воспроизведения оркестрации в Application Insights. |
| logReplayEvents | неправда | Значение, указывающее, следует ли регистрировать повторяющиеся выполнения в журналах приложений. |
| eventGridTopicEndpoint | URL-адрес конечной точки пользовательской темы службы Azure Event Grid. При установке этого свойства события уведомления жизненного цикла оркестрации публикуются в этой конечной точке. Это свойство поддерживает разрешение параметров приложения. | |
| ИмяНастройкиКлючаEventGrid | Имя параметра приложения, содержащего ключ, используемый для проверки подлинности с помощью настраиваемого раздела сетки событий по EventGridTopicEndpoint URL-адресу. |
|
| eventGridКоличествоПовторовПубликации | 0 | Число повторных попыток, если публикация в сетке событий выполняется неудачно. |
| ИнтервалПовторнойПопыткиПубликацииEventGrid | 00:05:00 | Интервал публикации и повтора сетки событий в формате hh:mm:ss . |
| eventGridPublishEventTypes | Список типов событий для публикации в Сетке событий. Если вы не указываете какие-либо типы, публикуются все типы событий. Допустимые значения: Started, Completedи FailedTerminated. |
|
| extendedSessionsEnabled | неправда | Значение, указывающее, кэшируются ли сеансы оркестратора и сеансы функций сущностей. |
| extendedSessionIdleTimeoutInSeconds (время простоя продленной сессии в секундах) | 30 | Количество секунд, в течение которых бездействующий оркестратор или функция сущности остается в памяти перед выгрузкой. Этот параметр используется только в том случае, если параметр extendedSessionsEnabled установлен как true. |
| useAppLease | правда | Значение, указывающее, должны ли приложения получать аренду BLOB-объекта на уровне приложения перед обработкой сообщений из концентратора заданий. Дополнительные сведения см. в разделе "Аварийное восстановление и геораспределение в Устойчивых функциях". Этот параметр доступен начиная с версии 2.3.0. |
| использовать устаревшее управление разделами | неправда | Значение, указывающее тип используемого алгоритма управления секциями. При использовании этого параметра falseиспользуется алгоритм, который снижает вероятность дублирования выполнения функции при масштабировании. Этот параметр доступен начиная с версии 2.3.0.
Не рекомендуется задавать это значениеtrue. |
| использоватьУправлениеРазделамиТаблиц | В версии 3.x: true В версии 2.x: false |
Значение, указывающее тип используемого алгоритма управления секциями. Если этот параметр задан true, используется алгоритм, предназначенный для снижения затрат на учетные записи службы хранилища Azure версии 2. Этот параметр доступен начиная с webJobs.Extensions.DurableTask версии 2.10.0. Для использования этого параметра с управляемым удостоверением требуется webJobs.Extensions.DurableTask версии 3.x или более поздней версии, или Worker.Extensions.DurableTask версии 1.2.x или более поздней версии. |
| useGracefulShutdown (использовать плавное завершение) | неправда | (предварительная версия) Значение, указывающее, следует ли корректно завершить работу, чтобы снизить вероятность сбоя выполнения функций в процессе, вызванного завершением работы узла. |
| maxEntityOperationBatchSize (максимальный размер партии операций с сущностями) |
План потребления: 50 Выделенный или премиум тариф: 5,000 |
Максимальное количество операций с сущностями, обрабатываемых в виде пакета. Если это значение равно 1, пакетная обработка отключена, а отдельный вызов функции обрабатывает каждое сообщение операции. Этот параметр доступен начиная с версии 2.6.1. |
| сохранитьВходныеДанныеВОркестрационнойИстории | неправда | Значение, указывающее, как хранить входные данные. Если этот параметр задан true, платформа устойчивых задач сохраняет входные данные действий в таблице истории, а входные данные функции действий отображаются в результатах запроса истории оркестрации. |
| maxGrpcMessageSizeInBytes (максимальный размер сообщения gRPC в байтах) | 4,194,304 | Целочисленное значение, задающее максимальный размер в байтах сообщений, которые может получать универсальный клиент удаленного вызова процедур (gRPC).
DurableTaskClient Реализация использует клиент gRPC для управления экземплярами оркестрации. Этот параметр применяется к изолированным рабочим .NET и приложениям Java для Durable Functions. |
| grpcHttpClientTimeout (тайм-аут HTTP-клиента gRPC) | 00:01:40 | Время ожидания в формате hh:mm:ss для HTTP-клиента, используемого клиентом gRPC в Durable Functions. Клиент в настоящее время поддерживается для изолированных рабочих приложений .NET (.NET 6 и более поздних версий) и для приложений Java. |
| QueueClientMessageEncoding | UTF8 | Стратегия кодирования сообщений хранилища очередей Azure. Допустимые стратегии: формат преобразования Юникода—8-разрядный (UTF8) и Base64. Этот параметр применяется при использовании Microsoft.Azure.WebJobs.Extensions.DurableTask 3.4.0 или более поздней версии или Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.7.0 или более поздней версии. |
Многие из этих параметров предназначены для оптимизации производительности. Дополнительные сведения см. в разделе "Производительность и масштабирование".