Powiązania dla Durable Functions (Azure Functions)

  • Artykuł

Rozszerzenie Durable Functions wprowadza trzy powiązania wyzwalacza, które kontrolują wykonywanie funkcji orkiestratora, jednostki i działania. Wprowadzono również powiązanie wyjściowe, które działa jako klient środowiska uruchomieniowego Durable Functions.

Pamiętaj, aby wybrać język programowania Durable Functions w górnej części artykułu.

Ważne

Ten artykuł obsługuje zarówno modele programowania Python w wersji 1, jak i Python w wersji 2 dla Durable Functions.

Model programowania w języku Python w wersji 2

Durable Functions zapewnia obsługę wersji zapoznawczej nowego modelu programowania w języku Python w wersji 2. Aby użyć modelu w wersji 2, należy zainstalować zestaw SDK Durable Functions, który jest pakietem azure-functions-durablePyPI, wersją 1.2.2 lub nowszą wersją. W wersji zapoznawczej możesz przekazać opinię i sugestie w repozytorium Durable Functions SDK dla języka Python.

Używanie pakietów rozszerzeń nie jest obecnie obsługiwane dla modelu w wersji 2 z Durable Functions. Zamiast tego należy ręcznie zarządzać rozszerzeniami w następujący sposób:

  1. Usuń sekcję extensionBundlehost.json pliku.

  2. func extensions install --package Microsoft.Azure.WebJobs.Extensions.DurableTask --version 2.9.1 Uruchom polecenie w terminalu. Spowoduje to zainstalowanie rozszerzenia Durable Functions dla aplikacji, które umożliwia korzystanie z wersji zapoznawczej modelu w wersji 2. Aby uzyskać więcej informacji, zobacz instalowanie rozszerzeń func.

Wyzwalacz orkiestracji

Wyzwalacz orkiestracji umożliwia tworzenie trwałych funkcji orkiestratora. Ten wyzwalacz jest wykonywany po zaplanowaniu nowego wystąpienia orkiestracji i odebraniu zdarzenia przez istniejące wystąpienie orkiestracji. Przykłady zdarzeń, które mogą wyzwalać funkcje orkiestratora, to trwałe wygaśnięcia czasomierza, odpowiedzi funkcji działania i zdarzenia zgłaszane przez klientów zewnętrznych.

Podczas tworzenia funkcji na platformie .NET wyzwalacz orkiestracji jest konfigurowany przy użyciu atrybutu OrchestrationTriggerAttribute .NET.

W przypadku języka Java adnotacja @DurableOrchestrationTrigger służy do konfigurowania wyzwalacza aranżacji.

Podczas pisania funkcji orkiestratora wyzwalacz orkiestracji jest definiowany przez następujący obiekt JSON w bindings tablicy pliku function.json :

{
    "name": "<Name of input parameter in function signature>",
    "orchestration": "<Optional - name of the orchestration>",
    "type": "orchestrationTrigger",
    "direction": "in"
}
  • orchestration to nazwa orkiestracji, której klienci muszą używać, gdy chcą uruchomić nowe wystąpienia tej funkcji orkiestratora. Ta właściwość jest opcjonalna. Jeśli nie zostanie określona, zostanie użyta nazwa funkcji.

Azure Functions obsługuje dwa modele programowania dla języka Python. Sposób definiowania wyzwalacza aranżacji zależy od wybranego modelu programowania.

Model programowania w języku Python w wersji 2 umożliwia zdefiniowanie wyzwalacza orkiestracji przy użyciu dekoratora orchestration_trigger bezpośrednio w kodzie funkcji języka Python.

W modelu w wersji 2 dostęp do wyzwalaczy i powiązań Durable Functions uzyskuje się z wystąpienia klasy DFApp, która jest podklasąFunctionApp, która dodatkowo eksportuje Durable Functions dekoratorów specyficznych dla danego dekoratora.

Wewnętrznie to powiązanie wyzwalacza sonduje skonfigurowany trwały magazyn dla nowych zdarzeń aranżacji, takich jak zdarzenia rozpoczęcia aranżacji, zdarzenia wygaśnięcia trwałego czasomierza, zdarzenia odpowiedzi funkcji działania i zdarzenia zewnętrzne zgłaszane przez inne funkcje.

Zachowanie wyzwalacza

Oto kilka uwag dotyczących wyzwalacza orkiestracji:

  • Pojedyncze wątki — pojedynczy wątek dyspozytora jest używany do wykonywania wszystkich funkcji orkiestratora w jednym wystąpieniu hosta. Z tego powodu ważne jest, aby upewnić się, że kod funkcji orkiestratora jest wydajny i nie wykonuje żadnych operacji we/wy. Należy również upewnić się, że ten wątek nie wykonuje żadnej pracy asynchronicznych, z wyjątkiem sytuacji, w których oczekuje się na typy zadań specyficznych dla Durable Functions.
  • Obsługa komunikatów zatrutych — nie ma obsługi zatrutych komunikatów w wyzwalaczach orkiestracji.
  • Widoczność komunikatów — komunikaty wyzwalacza orkiestracji są odsłaniane i niewidoczne przez konfigurowalny czas trwania. Widoczność tych komunikatów jest odnawiana automatycznie, o ile aplikacja funkcji działa i jest w dobrej kondycji.
  • Wartości zwracane — wartości zwracane są serializowane do formatu JSON i utrwalane w tabeli historii aranżacji w usłudze Azure Table Storage. Te wartości zwracane mogą być odpytywane przez powiązanie klienta aranżacji opisane w dalszej części.

Ostrzeżenie

Funkcje programu Orchestrator nigdy nie powinny używać żadnych powiązań wejściowych lub wyjściowych innych niż powiązanie wyzwalacza aranżacji. Może to spowodować problemy z rozszerzeniem Durable Task, ponieważ te powiązania mogą nie być zgodne z regułami pojedynczego wątku i we/wy. Jeśli chcesz użyć innych powiązań, dodaj je do funkcji działania wywoływanej z funkcji orkiestratora. Aby uzyskać więcej informacji na temat ograniczeń kodowania funkcji orkiestratora, zobacz dokumentację ograniczeń kodu funkcji orchestrator .

Ostrzeżenie

Funkcje programu Orchestrator nigdy nie powinny być deklarowane async.

Wyzwalanie użycia

Powiązanie wyzwalacza aranżacji obsługuje zarówno dane wejściowe, jak i wyjściowe. Oto kilka rzeczy, które należy wiedzieć o obsłudze danych wejściowych i wyjściowych:

  • inputs — wyzwalacze orkiestracji można wywołać przy użyciu danych wejściowych, do których uzyskuje się dostęp za pośrednictwem obiektu wejściowego kontekstu. Wszystkie dane wejściowe muszą być serializowalne w formacie JSON.
  • outputs — wyzwalacze orkiestracji obsługują wartości wyjściowe, a także dane wejściowe. Zwracana wartość funkcji służy do przypisywania wartości wyjściowej i musi być serializowalne w formacie JSON.

Przykład wyzwalacza

Poniższy przykładowy kod pokazuje, jak może wyglądać najprostsza funkcja orkiestratora "Hello world". Należy pamiętać, że ten przykładowy koordynator nie planuje żadnych zadań.

Określony atrybut używany do definiowania wyzwalacza zależy od tego, czy uruchamiasz funkcje języka C# w procesie, czy w izolowanym procesie roboczym.

[FunctionName("HelloWorld")]
public static string Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string name = context.GetInput<string>();
    return $"Hello {name}!";
}

Uwaga

Poprzedni kod dotyczy Durable Functions 2.x. W przypadku Durable Functions 1.x należy użyć DurableOrchestrationContext polecenia zamiast IDurableOrchestrationContext. Aby uzyskać więcej informacji na temat różnic między wersjami, zobacz artykuł Durable Functions Versions (Wersje Durable Functions).

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context) {
    const name = context.df.getInput();
    return `Hello ${name}!`;
});

Uwaga

Biblioteka durable-functions zajmuje się wywoływanie metody synchronicznej context.done , gdy funkcja generatora kończy działanie.

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

Większość funkcji orkiestratora wywołuje funkcje działania, więc oto przykład "Hello world", który pokazuje, jak wywołać funkcję działania:

[FunctionName("HelloWorld")]
public static async Task<string> Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string name = context.GetInput<string>();
    string result = await context.CallActivityAsync<string>("SayHello", name);
    return result;
}

Uwaga

Poprzedni kod dotyczy Durable Functions 2.x. W przypadku Durable Functions 1.x należy użyć DurableOrchestrationContext polecenia zamiast IDurableOrchestrationContext. Aby uzyskać więcej informacji na temat różnic między wersjami, zobacz artykuł dotyczący wersji Durable Functions.

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context) {
    const name = context.df.getInput();
    const result = yield context.df.callActivity("SayHello", 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;
}

Wyzwalacz działania

Wyzwalacz działania umożliwia tworzenie funkcji wywoływanych przez funkcje orkiestratora, znane jako funkcje działania.

Wyzwalacz działania jest konfigurowany przy użyciu atrybutu ActivityTriggerAttribute .NET.

Wyzwalacz działania jest konfigurowany przy użyciu adnotacji @DurableActivityTrigger .

Wyzwalacz działania jest definiowany przez następujący obiekt JSON w bindings tablicy pliku function.json:

{
    "name": "<Name of input parameter in function signature>",
    "activity": "<Optional - name of the activity>",
    "type": "activityTrigger",
    "direction": "in"
}
  • activity to nazwa działania. Ta wartość jest nazwą używaną przez funkcje orkiestratora do wywoływania tej funkcji działania. Ta właściwość jest opcjonalna. Jeśli nie zostanie określona, zostanie użyta nazwa funkcji.

Sposób definiowania wyzwalacza działania zależy od wybranego modelu programowania.

Używanie dekoratora activity_trigger bezpośrednio w kodzie funkcji języka Python.

Wewnętrznie to powiązanie wyzwalacza sonduje skonfigurowany trwały magazyn dla nowych zdarzeń wykonywania działań.

Zachowanie wyzwalacza

Poniżej przedstawiono kilka notatek dotyczących wyzwalacza działania:

  • Wątkowanie — w przeciwieństwie do wyzwalacza aranżacji wyzwalacze działania nie mają żadnych ograniczeń dotyczących wątkowania ani we/wy. Mogą być traktowane jak zwykłe funkcje.
  • Obsługa komunikatów zatrutych — nie ma obsługi komunikatów o truciznie w wyzwalaczach działań.
  • Widoczność komunikatów — komunikaty wyzwalacza działania są w kolejce i są niewidoczne przez konfigurowalny czas trwania. Widoczność tych komunikatów jest odnawiana automatycznie, o ile aplikacja funkcji działa i jest w dobrej kondycji.
  • Zwracane wartości — wartości zwracane są serializowane do formatu JSON i utrwalane w skonfigurowanym magazynie trwałym.

Wyzwalanie użycia

Powiązanie wyzwalacza działania obsługuje zarówno dane wejściowe, jak i wyjściowe, podobnie jak wyzwalacz aranżacji. Oto kilka rzeczy, które należy wiedzieć o obsłudze danych wejściowych i wyjściowych:

  • inputs — wyzwalacze działań można wywołać przy użyciu danych wejściowych z funkcji orkiestratora. Wszystkie dane wejściowe muszą być serializowalne w formacie JSON.
  • outputs — funkcje działania obsługują wartości wyjściowe, a także dane wejściowe. Zwracana wartość funkcji służy do przypisywania wartości wyjściowej i musi być serializowalne w formacie JSON.
  • metadata — funkcje działań platformy .NET mogą wiązać się z parametrem string instanceId w celu uzyskania identyfikatora wystąpienia wywołującej aranżacji.

Przykład wyzwalacza

Poniższy przykładowy kod pokazuje, jak może wyglądać prosta SayHello funkcja działania.

[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] IDurableActivityContext helloContext)
{
    string name = helloContext.GetInput<string>();
    return $"Hello {name}!";
}

Domyślnym typem parametru powiązania platformy .NET ActivityTriggerAttribute jest IDurableActivityContext (lub DurableActivityContext dla Durable Functions v1). Jednak wyzwalacze działań platformy .NET obsługują również powiązanie bezpośrednio z typami serializacji JSON (w tym typami pierwotnymi), dzięki czemu ta sama funkcja może zostać uproszczona w następujący sposób:

[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] string name)
{
    return $"Hello {name}!";
}

module.exports = async function(context) {
    return `Hello ${context.bindings.name}!`;
};

Powiązania języka JavaScript można również przekazać jako dodatkowe parametry, dzięki czemu ta sama funkcja może zostać uproszczona w następujący sposób:

module.exports = async function(context, name) {
    return `Hello ${name}!`;
};

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

Używanie powiązań wejściowych i wyjściowych

Oprócz powiązania wyzwalacza działania można używać regularnych powiązań wejściowych i wyjściowych.

Możesz na przykład przekazać dane wejściowe do powiązania działania i wysłać komunikat do usługi EventHub przy użyciu powiązania wyjściowego usługi EventHub:

{
  "bindings": [
    {
      "name": "message",
      "type": "activityTrigger",
      "direction": "in"
    },
    {
      "type": "eventHub",
      "name": "outputEventHubMessage",
      "connection": "EventhubConnectionSetting",
      "eventHubName": "eh_messages",
      "direction": "out"
  }
  ]
}

module.exports = async function (context) {
    context.bindings.outputEventHubMessage = context.bindings.message;
};

Klient orkiestracji

Powiązanie klienta orkiestracji umożliwia pisanie funkcji, które współdziałają z funkcjami orkiestratora. Te funkcje są często określane jako funkcje klienta. Można na przykład wykonywać działania na wystąpieniach orkiestracji w następujący sposób:

  • Uruchom je.
  • Wykonywanie zapytań o ich stan.
  • Zakończ je.
  • Wysyłaj zdarzenia do nich, gdy są uruchomione.
  • Przeczyszczanie historii wystąpień.

Można powiązać z klientem aranżacji przy użyciu atrybutu DurableClientAttribute (OrchestrationClientAttribute w Durable Functions v1.x).

Możesz powiązać z klientem aranżacji przy użyciu adnotacji @DurableClientInput .

Wyzwalacz trwałego klienta jest definiowany przez następujący obiekt JSON w bindings tablicy pliku function.json:

{
    "name": "<Name of input parameter in function signature>",
    "taskHub": "<Optional - name of the task hub>",
    "connectionName": "<Optional - name of the connection string app setting>",
    "type": "orchestrationClient",
    "direction": "in"
}
  • taskHub — Używane w scenariuszach, w których wiele aplikacji funkcji współużytkuje to samo konto magazynu, ale musi być odizolowane od siebie. Jeśli nie zostanie określona, zostanie użyta wartość host.json domyślna. Ta wartość musi być zgodna z wartością używaną przez funkcje orkiestratora docelowego.
  • connectionName - Nazwa ustawienia aplikacji zawierającego parametry połączenia konta magazynu. Konto magazynu reprezentowane przez te parametry połączenia musi być takie samo, które jest używane przez funkcje koordynatora docelowego. Jeśli nie zostanie określony, zostaną użyte domyślne parametry połączenia konta magazynu dla aplikacji funkcji.

Uwaga

W większości przypadków zalecamy pominięcie tych właściwości i poleganie na domyślnym zachowaniu.

Sposób definiowania trwałego wyzwalacza klienta zależy od wybranego modelu programowania.

Używanie dekoratora durable_client_input bezpośrednio w kodzie funkcji języka Python.

Użycie klienta

Zwykle wiążesz się z elementem IDurableClient (DurableOrchestrationClient w wersji Durable Functions v1.x), co zapewnia pełny dostęp do wszystkich interfejsów API klienta aranżacji obsługiwanych przez Durable Functions.

Zazwyczaj wiążesz się z klasą DurableClientContext .

Aby uzyskać dostęp do obiektu klienta, należy użyć zestawu SDK specyficznego dla języka.

Oto przykładowa funkcja wyzwalana w kolejce, która uruchamia orkiestrację "HelloWorld".

[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("HelloWorld", input);
}

Uwaga

Poprzedni kod języka C# jest przeznaczony dla Durable Functions 2.x. W przypadku Durable Functions 1.x należy użyć OrchestrationClient atrybutu zamiast atrybutu DurableClient i należy użyć typu parametru DurableOrchestrationClient zamiast IDurableOrchestrationClient. Aby uzyskać więcej informacji na temat różnic między wersjami, zobacz artykuł Durable Functions Versions (Wersje Durable Functions).

function.json

{
  "bindings": [
    {
      "name": "input",
      "type": "queueTrigger",
      "queueName": "durable-function-trigger",
      "direction": "in"
    },
    {
      "name": "starter",
      "type": "durableClient",
      "direction": "in"
    }
  ]
}

index.js

const df = require("durable-functions");

module.exports = async function (context) {
    const client = df.getClient(context);
    return instanceId = await client.startNew("HelloWorld", undefined, context.bindings.input);
};

run.ps1

param([string] $input, $TriggerMetadata)

$InstanceId = Start-DurableOrchestration -FunctionName $FunctionName -Input $input

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.route(route="orchestrators/{functionName}")
@myApp.durable_client_input(client_name="client")
async def durable_trigger(req: func.HttpRequest, client):
    function_name = req.route_params.get('functionName')
    instance_id = await client.start_new(function_name)
    response = client.create_check_status_response(req, instance_id)
    return response

function.json

{
  "bindings": [
    {
      "name": "input",
      "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);
}

Więcej szczegółów na temat uruchamiania wystąpień można znaleźć w temacie Zarządzanie wystąpieniami.

Wyzwalacz jednostki

Wyzwalacze jednostek umożliwiają tworzenie funkcji jednostek. Ten wyzwalacz obsługuje przetwarzanie zdarzeń dla określonego wystąpienia jednostki.

Uwaga

Wyzwalacze jednostek są dostępne od Durable Functions 2.x.

Wewnętrznie to powiązanie wyzwalacza sonduje skonfigurowany trwały magazyn dla nowych operacji jednostki, które należy wykonać.

Wyzwalacz jednostki jest skonfigurowany przy użyciu atrybutu EntityTriggerAttribute .NET.

Uwaga

Wyzwalacze jednostek nie są jeszcze obsługiwane w przypadku izolowanych aplikacji procesów roboczych.

Wyzwalacz jednostki jest definiowany przez następujący obiekt JSON w bindings tablicy pliku function.json:

{
    "name": "<Name of input parameter in function signature>",
    "entityName": "<Optional - name of the entity>",
    "type": "entityTrigger",
    "direction": "in"
}

Domyślnie nazwa jednostki jest nazwą funkcji.

Uwaga

Wyzwalacze jednostek nie są jeszcze obsługiwane dla języka Java.

Sposób definiowania wyzwalacza jednostki zależy od wybranego modelu programowania.

Używanie dekoratora entity_trigger bezpośrednio w kodzie funkcji języka Python.

Zachowanie wyzwalacza

Oto kilka uwag dotyczących wyzwalacza jednostki:

  • Jednowątkowy: pojedynczy wątek dyspozytora służy do przetwarzania operacji dla określonej jednostki. Jeśli wiele komunikatów jest wysyłanych jednocześnie do jednej jednostki, operacje zostaną przetworzone pojedynczo.
  • Obsługa komunikatów zatrutych — w wyzwalaczach jednostek nie ma obsługi komunikatów trucizny.
  • Widoczność komunikatów — komunikaty wyzwalacza jednostki są w kolejce i są niewidoczne przez konfigurowalny czas trwania. Widoczność tych komunikatów jest odnawiana automatycznie, o ile aplikacja funkcji jest uruchomiona i jest w dobrej kondycji.
  • Wartości zwracane — funkcje jednostek nie obsługują zwracanych wartości. Istnieją określone interfejsy API, których można użyć do zapisania stanu lub przekazania wartości z powrotem do aranżacji.

Wszelkie zmiany stanu wprowadzone w jednostce podczas wykonywania zostaną automatycznie utrwalone po zakończeniu wykonywania.

Aby uzyskać więcej informacji i przykładów dotyczących definiowania wyzwalaczy jednostek i interakcji z nimi, zobacz dokumentację jednostek trwałych .

Klient jednostki

Powiązanie klienta jednostki umożliwia asynchroniczne wyzwalanie funkcji jednostki. Te funkcje są czasami określane jako funkcje klienta.

Można powiązać z klientem jednostki przy użyciu atrybutu DurableClientAttribute .NET w funkcjach biblioteki klas platformy .NET.

Uwaga

Można [DurableClientAttribute] go również użyć do powiązania z klientem aranżacji.

Klient jednostki jest definiowany przez następujący obiekt JSON w bindings tablicy pliku function.json:

{
    "name": "<Name of input parameter in function signature>",
    "taskHub": "<Optional - name of the task hub>",
    "connectionName": "<Optional - name of the connection string app setting>",
    "type": "durableClient",
    "direction": "in"
}
  • taskHub — Używane w scenariuszach, w których wiele aplikacji funkcji współużytkuje to samo konto magazynu, ale musi być odizolowane od siebie. Jeśli nie zostanie określony, zostanie użyta wartość domyślna z host.json . Ta wartość musi być zgodna z wartością używaną przez funkcje jednostki docelowej.
  • connectionName — Nazwa ustawienia aplikacji zawierającego parametry połączenia konta magazynu. Konto magazynu reprezentowane przez te parametry połączenia musi być takie samo, które jest używane przez funkcje jednostki docelowej. Jeśli nie zostanie określony, zostaną użyte domyślne parametry połączenia konta magazynu dla aplikacji funkcji.

Uwaga

W większości przypadków zalecamy pominięcie opcjonalnych właściwości i poleganie na zachowaniu domyślnym.

Sposób definiowania klienta jednostki zależy od wybranego modelu programowania.

Używanie dekoratora durable_client_input bezpośrednio w kodzie funkcji języka Python.

Uwaga

Klienci jednostek nie są jeszcze obsługiwani w przypadku języka Java.

Aby uzyskać więcej informacji i przykładów dotyczących interakcji z jednostkami jako klientem, zobacz dokumentację jednostek trwałych .

Ustawienia pliku host.json

Ustawienia konfiguracji dla Durable Functions.

Uwaga

Wszystkie główne wersje Durable Functions są obsługiwane we wszystkich wersjach środowiska uruchomieniowego Azure Functions. Jednak schemat konfiguracji host.json jest nieco inny w zależności od wersji środowiska uruchomieniowego Azure Functions i używanej wersji rozszerzenia Durable Functions. Poniższe przykłady służą do użycia z Azure Functions 2.0 i 3.0. W obu przykładach, jeśli używasz Azure Functions 1.0, dostępne ustawienia są takie same, ale sekcja "durableTask" pliku host.json powinna znajdować się w katalogu głównym konfiguracji host.json zamiast jako pole w obszarze "extensions".

{
 "extensions": {
  "durableTask": {
    "hubName": "MyTaskHub",
    "storageProvider": {
      "connectionStringName": "AzureWebJobsStorage",
      "controlQueueBatchSize": 32,
      "controlQueueBufferThreshold": 256,
      "controlQueueVisibilityTimeout": "00:05:00",
      "maxQueuePollingInterval": "00:00:30",
      "partitionCount": 4,
      "trackingStoreConnectionStringName": "TrackingStorage",
      "trackingStoreNamePrefix": "DurableTask",
      "useLegacyPartitionManagement": true,
      "useTablePartitionManagement": false,
      "workItemQueueVisibilityTimeout": "00:05:00",
    },
    "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",
          "Pending",
          "Failed",
          "Terminated"
        ]
      }
    },
    "maxConcurrentActivityFunctions": 10,
    "maxConcurrentOrchestratorFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50
  }
 }
}

Nazwy centrum zadań muszą zaczynać się literą i składać się tylko z liter i cyfr. Jeśli nie zostanie określona, domyślna nazwa centrum zadań dla aplikacji funkcji to TestHubName. Aby uzyskać więcej informacji, zobacz Centra zadań.

Właściwość Domyślny Opis
hubName TestHubName (DurableFunctionsHub, jeśli używasz Durable Functions 1.x) Alternatywne nazwy centrum zadań mogą służyć do izolowania wielu aplikacji Durable Functions od siebie, nawet jeśli używają tego samego zaplecza magazynu.
controlQueueBatchSize 32 Liczba komunikatów do ściągnięcia z kolejki sterowania naraz.
controlQueueBufferThreshold Plan zużycia dla języka Python: 32
Plan zużycia dla języków JavaScript i C#: 128
Plan dedykowany/Premium: 256		 Liczba komunikatów kolejki kontroli, które mogą być buforowane w pamięci w danym momencie, w tym momencie dyspozytor będzie czekać przed usunięciem z kolejki wszelkich dodatkowych komunikatów.
partitionCount 4 Liczba partycji dla kolejki sterowania. Może być dodatnią liczbą całkowitą z zakresu od 1 do 16.
controlQueueVisibilityTimeout 5 min Limit czasu widoczności komunikatów kolejki w kolejce.
workItemQueueVisibilityTimeout 5 min Limit czasu widoczności komunikatów kolejki elementów roboczych w kolejce w kolejce.
maxConcurrentActivityFunctions Plan zużycia: 10
Plan dedykowany/Premium: 10 X liczba procesorów na bieżącej maszynie		 Maksymalna liczba funkcji działań, które mogą być przetwarzane współbieżnie w jednym wystąpieniu hosta.
maxConcurrentOrchestratorFunctions Plan zużycia: 5
Plan dedykowany/Premium: 10 X liczba procesorów na bieżącej maszynie		 Maksymalna liczba funkcji orkiestratora, które mogą być przetwarzane współbieżnie w jednym wystąpieniu hosta.
maxQueuePollingInterval 30 sekund Maksymalny interwał sondowania kolejki elementów roboczych i kontroli elementów roboczych w formacie hh:mm:ss . Wyższe wartości mogą powodować większe opóźnienia przetwarzania komunikatów. Niższe wartości mogą spowodować wyższe koszty magazynowania z powodu zwiększonych transakcji magazynu.
connectionName (2.7.0 i nowsze)
connectionStringName (2.x)
azureStorageConnectionStringName (1.x)		 AzureWebJobsStorage Nazwa ustawienia lub ustawienia kolekcji aplikacji, która określa sposób nawiązywania połączenia z bazowymi zasobami usługi Azure Storage. Po udostępnieniu pojedynczego ustawienia aplikacji powinny to być parametry połączenia usługi Azure Storage.
trackingStoreConnectionName (2.7.0 i nowsze)
trackingStoreConnectionStringName		 Nazwa ustawienia lub ustawienia kolekcji aplikacji, która określa sposób nawiązywania połączenia z tabelami Historia i wystąpienia. Po udostępnieniu pojedynczego ustawienia aplikacji powinny to być parametry połączenia usługi Azure Storage. Jeśli nie zostanie określone, connectionStringName zostanie użyte połączenie (Durable 2.x) lub azureStorageConnectionStringName (Durable 1.x).
trackingStoreNamePrefix Prefiks używany dla tabel Historia i wystąpienia, gdy trackingStoreConnectionStringName jest określony. Jeśli nie zostanie ustawiona, domyślną wartością prefiksu będzie DurableTask. Jeśli trackingStoreConnectionStringName nie zostanie określony, tabele Historia i wystąpienia będą używać wartości jako prefiksu hubName , a każde ustawienie dla trackingStoreNamePrefix elementu zostanie zignorowane.
traceInputsAndOutputs fałsz Wartość wskazująca, czy śledzić dane wejściowe i wyjściowe wywołań funkcji. Domyślnym zachowaniem podczas śledzenia zdarzeń wykonywania funkcji jest uwzględnienie liczby bajtów w serializowanych danych wejściowych i wyjściowych wywołań funkcji. To zachowanie zapewnia minimalne informacje o tym, jak wyglądają dane wejściowe i wyjściowe bez wdychania dzienników lub przypadkowo ujawniania poufnych informacji. Ustawienie tej właściwości na wartość true powoduje, że domyślne rejestrowanie funkcji powoduje rejestrowanie całej zawartości danych wejściowych i wyjściowych funkcji.
traceReplayEvents fałsz Wartość wskazująca, czy mają być zapisywane zdarzenia odtwarzania orkiestracji w usłudze Application Insights.
eventGridTopicEndpoint Adres URL niestandardowego punktu końcowego tematu Azure Event Grid. Po ustawieniu tej właściwości zdarzenia powiadomień cyklu życia są publikowane w tym punkcie końcowym. Ta właściwość obsługuje rozpoznawanie ustawień aplikacji.
eventGridKeySettingName Nazwa ustawienia aplikacji zawierającego klucz używany do uwierzytelniania za pomocą tematu niestandardowego Azure Event Grid pod adresem EventGridTopicEndpoint.
eventGridPublishRetryCount 0 Liczba ponownych prób w przypadku niepowodzenia publikowania w temacie usługi Event Grid.
eventGridPublishRetryInterval 5 min Usługa Event Grid publikuje interwał ponawiania prób w formacie hh:mm:ss .
eventGridPublishEventTypes Lista typów zdarzeń do opublikowania w usłudze Event Grid. Jeśli nie zostanie określony, wszystkie typy zdarzeń zostaną opublikowane. Dozwolone wartości to Started, , FailedCompleted, Terminated.
useAppLease true Po ustawieniu wartości trueaplikacje będą wymagać uzyskania dzierżawy obiektu blob na poziomie aplikacji przed przetworzeniem komunikatów centrum zadań. Aby uzyskać więcej informacji, zobacz dokumentację odzyskiwania po awarii i dystrybucji geograficznej . Dostępne od wersji 2.3.0.
useLegacyPartitionManagement fałsz W przypadku ustawienia na wartość falseprogram używa algorytmu zarządzania partycjami, który zmniejsza możliwość zduplikowania wykonywania funkcji podczas skalowania w górę. Dostępne od wersji 2.3.0.
useTablePartitionManagement fałsz W przypadku ustawienia na truewartość użyje algorytmu zarządzania partycjami zaprojektowanego w celu zmniejszenia kosztów kont usługi Azure Storage w wersji 2. Dostępne od wersji 2.10.0. Ta funkcja jest obecnie w wersji zapoznawczej i nie jest jeszcze zgodna z planem Zużycie.
useGracefulShutdown fałsz (Wersja zapoznawcza) Włącz bezproblemowe zamykanie, aby zmniejszyć prawdopodobieństwo, że zamknięcia hosta kończą się niepowodzeniem wykonywania funkcji w procesie.
maxEntityOperationBatchSize(2.6.1) Plan zużycia: 50
Plan dedykowany/Premium: 5000		 Maksymalna liczba operacji jednostki przetwarzanych jako partia. Jeśli ustawiono wartość 1, przetwarzanie wsadowe jest wyłączone, a każdy komunikat operacji jest przetwarzany przez osobne wywołanie funkcji.

Wiele z tych ustawień jest przeznaczonych do optymalizacji wydajności. Aby uzyskać więcej informacji, zobacz Wydajność i skala.

Następne kroki

Wbudowana dokumentacja interfejsu API HTTP na potrzeby zarządzania wystąpieniami