Centra úloh v Durable Functions (Azure Functions)

Centrum úloh v Durable Functions představuje aktuální stav aplikace v úložišti, včetně všech čekajících prací. Zatímco je aplikace funkcí spuštěná, průběh orchestrace, aktivit a funkcí entit se průběžně ukládá v centru úloh. Tím se zajistí, že aplikace může obnovit zpracování tam, kde skončila, pokud by po dočasném zastavení nebo přerušení z nějakého důvodu vyžadovalo restartování. Umožňuje také aplikaci funkcí dynamicky škálovat výpočetní pracovní procesy.

V centru úloh se koncepčně ukládají následující informace:

• Stavy instancí všech instancí orchestrace a entit.
• Zprávy, které se mají zpracovat, včetně
  • všechny zprávy o aktivitách , které představují aktivity čekající na spuštění.
  • všechny zprávy instance , které čekají na doručení do instancí.

Rozdíl mezi zprávami aktivit a zpráv instancí je v tom, že zprávy aktivit jsou bezstavové, a proto je možné je zpracovat kdekoli, zatímco zprávy instance je potřeba doručit do konkrétní stavové instance (orchestrace nebo entity) identifikované id instance.

Interně může každý poskytovatel úložiště používat k reprezentaci stavů a zpráv instancí jinou organizaci. Například zprávy jsou uloženy ve frontách služby Azure Storage poskytovatelem služby Azure Storage, ale v relačních tabulkách poskytovatelem MSSQL. Tyto rozdíly nezáleží na návrhu aplikace, ale některé z nich můžou mít vliv na charakteristiky výkonu. Probereme je v části Reprezentace v úložišti níže.

Pracovní položky

Zprávy aktivit a zprávy instancí v centru úloh představují práci, kterou musí aplikace funkcí zpracovat. Zatímco je aplikace funkcí spuštěná, průběžně načítá pracovní položky z centra úloh. Každá pracovní položka zpracovává jednu nebo více zpráv. Rozlišujeme dva typy pracovních položek:

• Pracovní položky aktivity: Spuštěním funkce aktivity zpracujte zprávu o aktivitě.
• Pracovní položka orchestrátoru: Spuštění orchestrátoru nebo funkce entity pro zpracování jedné nebo více zpráv instance.

Pracovní procesy můžou zpracovávat více pracovních položek najednou, a to v souladu s nakonfigurovaným limitem souběžnosti jednotlivých pracovních procesů.

Jakmile pracovní proces dokončí pracovní položku, potvrdí účinky zpět do centra úkolů. Tyto efekty se liší podle typu spuštěné funkce:

• Dokončená funkce aktivity vytvoří zprávu instance obsahující výsledek adresovaný nadřazené instanci orchestrátoru.
• Dokončená funkce orchestrátoru aktualizuje stav a historii orchestrace a může vytvářet nové zprávy.
• Dokončená funkce entity aktualizuje stav entity a může také vytvářet nové zprávy instance.

U orchestrací každá pracovní položka představuje jednu epizodu provedení této orchestrace. Epizoda začíná, když orchestrátor zpracuje nové zprávy. Taková zpráva může znamenat, že orchestrace by měla začít; nebo může znamenat, že byla dokončena aktivita, volání entity, časovač nebo suborchestrace; nebo může představovat externí událost. Zpráva aktivuje pracovní položku, která orchestrátoru umožňuje zpracovat výsledek a pokračovat v další epizodě. Tato epizoda končí, když se orchestrátor dokončí, nebo dosáhne bodu, kdy musí čekat na nové zprávy.

Příklad spuštění

Zvažte orchestraci fan-out-fan-in, která spustí dvě aktivity paralelně a počká na jejich dokončení:

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

Po zahájení této orchestrace klientem se aplikace funkcí zpracuje jako posloupnost pracovních položek. Každá dokončená pracovní položka aktualizuje stav centra úloh při potvrzení. Proveďte tyto kroky:

1. Klient požádá o zahájení nové orchestrace s ID instance 123. Jakmile klient dokončí tento požadavek, bude centrum úloh obsahovat zástupný symbol pro stav orchestrace a zprávu instance:

   

   Popisek ExecutionStarted je jedním z mnoha typů událostí historie , které identifikují různé typy zpráv a událostí, které se účastní historie orchestrace.

2. Pracovní proces spustí pracovní položku orchestrátoruExecutionStarted pro zpracování zprávy. Volá funkci orchestrátoru, která spustí kód orchestrace. Tento kód naplánuje dvě aktivity a při čekání na výsledky se zastaví. Jakmile pracovní proces potvrdí tuto pracovní položku, centrum úkolů obsahuje

   

   Stav modulu runtime je nyní Running, byly přidány dvě nové TaskScheduled zprávy a historie teď obsahuje pět událostí OrchestratorStarted, ExecutionStarted, , TaskScheduled, TaskScheduled. OrchestratorCompleted Tyto události představují první epizodu provedení této orchestrace.

3. Pracovní proces spustí pracovní položku aktivity , která zpracuje jednu ze TaskScheduled zpráv. Volá funkci aktivity se vstupem "2". Po dokončení funkce aktivity se vytvoří TaskCompleted zpráva obsahující výsledek. Jakmile pracovní proces potvrdí tuto pracovní položku, centrum úkolů obsahuje

   

4. Pracovní proces spustí pracovní položku orchestrátoruTaskCompleted pro zpracování zprávy. Pokud je orchestrace stále uložená v mezipaměti, může jednoduše pokračovat v provádění. Jinak pracovní proces nejprve přehraje historii, aby obnovil aktuální stav orchestrace. Pak pokračuje v orchestraci a doručuje výsledek aktivity. Po přijetí tohoto výsledku orchestrace stále čeká na výsledek druhé aktivity, takže se znovu zastaví. Jakmile pracovní proces potvrdí tuto pracovní položku, centrum úkolů obsahuje

   

   Historie orchestrace teď obsahuje další tři události OrchestratorStarted, TaskCompleted, . OrchestratorCompleted Tyto události představují druhou epizodu provedení této orchestrace.

5. Pracovní proces spustí pracovní položku aktivity , která zpracuje zbývající TaskScheduled zprávu. Zavolá funkci aktivity se vstupem "1". Jakmile pracovní proces potvrdí tuto pracovní položku, centrum úkolů obsahuje

   

6. Pracovní proces spustí další pracovní položku orchestrátoruTaskCompleted pro zpracování zprávy. Po obdržení tohoto druhého výsledku se orchestrace dokončí. Jakmile pracovní proces potvrdí tuto pracovní položku, centrum úkolů obsahuje

   

   Stav modulu runtime je teď Completeda historie orchestrace teď obsahuje další čtyři události OrchestratorStarted, , TaskCompleted, ExecutionCompleted. OrchestratorCompleted Tyto události představují třetí a poslední epizodu provedení této orchestrace.

Konečná historie provádění této orchestrace pak obsahuje 12 událostí OrchestratorStarted, ExecutionStarted, , , TaskScheduledTaskScheduled, TaskCompletedOrchestratorStartedOrchestratorCompletedOrchestratorStartedOrchestratorCompleted, , TaskCompleted, , , . OrchestratorCompletedExecutionCompleted

Poznámka

Zobrazený plán není jediný: existuje mnoho mírně odlišných plánů. Pokud se například dokončí druhá aktivita dříve, mohou být zprávy obou TaskCompleted instancí zpracovány jednou pracovní položkou. V takovém případě je historie provádění o něco kratší, protože existují pouze dvě epizody a obsahuje následujících 10 událostí: OrchestratorStarted, ExecutionStarted, , TaskScheduled, OrchestratorCompletedTaskScheduled, OrchestratorStarted, TaskCompleted, , TaskCompleted, , ExecutionCompleted, . OrchestratorCompleted

Správa centra úloh

Dále se podrobněji podíváme na to, jak se centra úloh vytvářejí nebo odstraňují, jak správně používat centra úloh při spouštění více aplikací funkcí a jak je možné kontrolovat obsah center úloh.

Vytvoření a odstranění

Při prvním spuštění aplikace funkcí se v úložišti automaticky vytvoří prázdné centrum úloh se všemi požadovanými prostředky.

Pokud používáte výchozího poskytovatele služby Azure Storage, nevyžaduje se žádná další konfigurace. V opačném případě postupujte podle pokynů ke konfiguraci poskytovatelů úložiště a ujistěte se, že poskytovatel úložiště může správně zřizovat a přistupovat k prostředkům úložiště požadovaným pro centrum úloh.

Poznámka

Centrum úloh se při zastavení nebo odstranění aplikace funkcí automaticky neodstraní . Pokud už tato data nechcete zachovat, musíte centrum úloh, jeho obsah nebo účet úložiště, který obsahuje, odstranit ručně.

Tip

Ve vývojovém scénáři může být často potřeba restartovat počítač z čistého stavu. Pokud to chcete udělat rychle, stačí změnit nakonfigurovaný název centra úloh. To vynutí vytvoření nového prázdného centra úloh při restartování aplikace. Mějte na paměti, že v tomto případě se neodstraní stará data.

Více aplikací funkcí

Pokud účet úložiště sdílí více aplikací funkcí, musí být každá aplikace funkcí nakonfigurovaná se samostatným názvem centra úloh. Tento požadavek platí také pro přípravné sloty: každý přípravný slot musí být nakonfigurovaný s jedinečným názvem centra úloh. Jeden účet úložiště může obsahovat více center úloh. Toto omezení se obecně vztahuje také na jiné poskytovatele úložiště.

Následující diagram znázorňuje jedno centrum úloh na aplikaci funkcí ve sdílených a vyhrazených účtech Azure Storage.

Poznámka

Výjimkou z pravidla sdílení centra úloh je, pokud aplikaci konfigurujete pro regionální zotavení po havárii. Další informace najdete v článku zotavení po havárii a geografická distribuce .

Kontrola obsahu

Existuje několik běžných způsobů, jak zkontrolovat obsah centra úloh:

1. V rámci aplikace funkcí poskytuje objekt klienta metody pro dotazování úložiště instancí. Další informace o podporovaných typech dotazů najdete v článku Správa instancí .
2. Podobně rozhraní HTTP API nabízí požadavky REST pro dotazování stavu orchestrací a entit. Další podrobnosti najdete v referenčních informacích k rozhraní HTTP API .
3. Nástroj Durable Functions Monitor může kontrolovat centra úloh a nabízí různé možnosti vizuálního zobrazení.

U některých poskytovatelů úložiště je také možné zkontrolovat centrum úloh tak, že přejdete přímo do základního úložiště:

• Pokud používáte poskytovatele služby Azure Storage, stavy instancí se ukládají do tabulky instance a tabulky historie, které je možné zkontrolovat pomocí nástrojů, jako je Průzkumník služby Azure Storage.
• Pokud používáte poskytovatele úložiště MSSQL, můžete použít dotazy a nástroje SQL ke kontrole obsahu centra úloh uvnitř databáze.

Reprezentace v úložišti

Každý poskytovatel úložiště používá k reprezentaci center úloh v úložišti jinou interní organizaci. Pochopení této organizace, i když to není nutné, může být užitečné při řešení potíží s aplikací funkcí nebo při pokusu o zajištění výkonu, škálovatelnosti nebo nákladových cílů. Stručně tedy u každého poskytovatele úložiště vysvětlíme, jak jsou data uspořádaná v úložišti. Další informace o různých možnostech zprostředkovatele úložiště a jejich porovnání najdete v tématu Durable Functions poskytovatelé úložiště.

Poskytovatel služby Azure Storage

Poskytovatel služby Azure Storage představuje centrum úloh v úložišti pomocí následujících komponent:

• Stavy instance jsou uložené ve dvou tabulkách Azure.
• Jedna fronta Azure ukládá zprávy o aktivitách.
• V jedné nebo několika frontách Azure se ukládají zprávy instance. Každá z těchto takzvaných řídicích front představuje oddíl , kterému je přiřazena podmnožina všech zpráv instance na základě hodnoty hash ID instance.
• Několik dalších kontejnerů objektů blob, které se používají k zapůjčení objektů blob nebo velkých zpráv.

Například centrum úloh s názvem xyz s PartitionCount = 4 obsahuje následující fronty a tabulky:

Dále tyto komponenty a roli, kterou hrají, popíšeme podrobněji.

Další informace o tom, jak zprostředkovatel služby Azure Storage reprezentuje centra úloh, najdete v dokumentaci k poskytovateli služby Azure Storage .

Netherite storage provider (Netherite Storage Provider)

Rozdělí všechny stavy centra úloh do zadaného počtu oddílů. V úložišti se používají následující prostředky:

• Jeden kontejner objektů blob služby Azure Storage, který obsahuje všechny objekty blob seskupené podle oddílů.
• Jedna tabulka Azure, která obsahuje publikované metriky o oddílech.
• Obor názvů Azure Event Hubs pro doručování zpráv mezi oddíly.

Například centrum úloh s názvem mytaskhub s PartitionCount = 32 názvem je v úložišti reprezentováno takto:

Poznámka

Veškerý stav centra úloh je uložený v kontejneru x-storage objektů blob. Tabulka DurableTaskPartitions a obor názvů EventHubs obsahují redundantní data: pokud dojde ke ztrátě jejich obsahu, je možné je automaticky obnovit. Proto není nutné konfigurovat obor názvů Azure Event Hubs pro uchovávání zpráv po uplynutí výchozího času vypršení platnosti.

Netherite používá mechanismus event-sourcing založený na protokolu a kontrolních bodech k reprezentaci aktuálního stavu oddílu. Používají se objekty blob bloku i objekty blob stránky. Tento formát není možné číst přímo z úložiště, takže při dotazování úložiště instancí musí být spuštěná aplikace funkcí.

Další informace o centrech úloh pro poskytovatele úložiště Netherite najdete v tématu Informace o centru úloh pro poskytovatele úložiště Netherite.

Poskytovatel úložiště MSSQL

Všechna data centra úloh jsou uložená v jedné relační databázi pomocí několika tabulek:

• V dt.Instances tabulkách a dt.History se ukládají stavy instance.
• V tabulce jsou dt.NewEvents uloženy zprávy instance.
• V tabulce se dt.NewTasks ukládají zprávy o aktivitách.

Aby bylo možné nezávisle na stejné databázi existovat více center úloh, obsahuje TaskHub každá tabulka sloupec jako součást svého primárního klíče. Na rozdíl od ostatních dvou poskytovatelů nemá poskytovatel MSSQL koncept oddílů.

Další informace o centrech úloh pro poskytovatele úložiště MSSQL najdete v tématu Informace o centru úloh pro poskytovatele úložiště Microsoft SQL (MSSQL).

Názvy centra úloh

Centra úloh jsou označená názvem, který musí odpovídat těmto pravidlům:

• Obsahuje pouze alfanumerické znaky.
• Začíná písmenem
• Má minimální délku 3 znaků, maximální délka je 45 znaků.

Název centra úloh je deklarován v souboru host.json , jak je znázorněno v následujícím příkladu:

host.json (Functions 2.0)

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

host.json (Functions 1.x)

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

Centra úloh je také možné nakonfigurovat pomocí nastavení aplikace, jak je znázorněno v následujícím host.json ukázkovém souboru:

host.json (Functions 1.0)

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

host.json (Functions 2.0)

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

Název centra úkolů se nastaví na hodnotu MyTaskHub nastavení aplikace. Následující local.settings.json příklad ukazuje, jak definovat MyTaskHub nastavení jako samplehubname:

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

Poznámka

Při použití slotů nasazení je osvědčeným postupem nakonfigurovat název centra úloh pomocí nastavení aplikace. Pokud chcete zajistit, aby konkrétní slot vždy používal konkrétní centrum úloh, použijte nastavení aplikace "slot-sticky".

Kromě souboru host.json je možné názvy centra úloh nakonfigurovat také v metadatech vazby klienta orchestrace . To je užitečné, pokud potřebujete přístup k orchestracím nebo entitami, které jsou v samostatné aplikaci funkcí. Následující kód ukazuje, jak napsat funkci, která používá vazbu klienta orchestrace pro práci s centrem úloh nakonfigurovaným jako nastavení aplikace:

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

Poznámka

Předchozí příklad je pro Durable Functions 2.x. Pro Durable Functions 1.x musíte místo IDurableOrchestrationContextpoužít DurableOrchestrationContext . Další informace o rozdílech mezi verzemi najdete v článku Durable Functions verze.

JavaScript

Vlastnost centra úloh v function.json souboru se nastavuje prostřednictvím nastavení aplikace:

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

Poznámka

Tento příklad cílí Durable Functions verze 2.x. Ve verzi 1.x použijte orchestrationClient místo durableClient.

Python

Vlastnost centra úloh v function.json souboru se nastavuje prostřednictvím nastavení aplikace:

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

Poznámka

Tento příklad cílí Durable Functions verze 2.x. Ve verzi 1.x použijte orchestrationClient místo durableClient.

PowerShell

Vlastnost centra úloh v function.json souboru se nastavuje prostřednictvím nastavení aplikace:

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

Poznámka

Tento příklad cílí Durable Functions verze 2.x. Ve verzi 1.x použijte orchestrationClient místo .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);
}

Poznámka

Konfigurace názvů centra úloh v metadatech klientských vazeb je nutná pouze v případě, že používáte jednu aplikaci funkcí pro přístup k orchestraci a entitami v jiné aplikaci funkcí. Pokud jsou funkce klienta definované ve stejné aplikaci funkcí jako orchestrace a entity, měli byste se vyhnout zadávání názvů center úloh v metadatech vazby. Ve výchozím nastavení získají všechny klientské vazby metadata centra úloh z nastavení host.json .

Názvy center úloh musí začínat písmenem a skládat se pouze z písmen a číslic. Pokud není zadaný, použije se výchozí název centra úloh, jak je znázorněno v následující tabulce:

Verze rozšíření Durable	Výchozí název centra úloh
2.x	Při nasazení v Azure se název centra úloh odvozuje od názvu aplikace funkcí. Při spuštění mimo Azure je TestHubNamevýchozí název centra úloh .
1.x	Výchozí název centra úloh pro všechna prostředí je DurableFunctionsHub.

Další informace o rozdílech mezi verzemi rozšíření najdete v článku Durable Functions verze.

Poznámka

Název je tím, co odlišuje jedno centrum úloh od druhého, když je ve sdíleném účtu úložiště více center úloh. Pokud máte více aplikací funkcí, které sdílejí sdílený účet úložiště, musíte explicitně nakonfigurovat různé názvy pro každé centrum úloh v souborech host.json . V opačném případě budou aplikace s více funkcemi vzájemně soupeřit o zprávy, což může vést k nedefinovaným chováním, včetně neočekávaně "zablokovaných" orchestrací ve Pending stavu nebo Running .

Další kroky

Naučte se zpracovávat správu verzí orchestrace.