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, aktivity a funkcí entit se průběžně ukládá do centra úloh. Tím zajistíte, že aplikace může pokračovat ve zpracování, kde skončila, pokud je nutné ji restartovat po dočasném zastavení nebo přerušení z nějakého důvodu. Umožňuje také aplikaci funkcí dynamicky škálovat výpočetní pracovní procesy.

Diagram znázorňující koncept aplikace funkcí a konceptu centra úloh

Centrum úloh ukládá následující informace:

  • Stavy instancí všech instancí orchestrace a entit.
  • Zprávy, které se mají zpracovat, včetně
    • všechny zprávy aktivit , 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 aktivitami a zprávami instance spočívá v tom, že zprávy aktivit jsou bezstavové a dají se tedy zpracovávat kdekoli, zatímco zprávy instance je potřeba doručit do konkrétní stavové instance (orchestrace nebo entity), které identifikuje ID instance.

Každý poskytovatel úložiště může interně používat jinou organizaci k reprezentaci stavů instancí a zpráv. Zprávy jsou například uložené 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 mohou ovlivnit charakteristiky výkonu. Probereme je v části Reprezentace v úložišti níže.

Pracovní položky

Zprávy aktivit a zprávy instance v centru úloh představují práci, kterou aplikace funkcí potřebuje 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í funkce aktivity pro zpracování zprávy aktivity
  • Pracovní položka nástroje Orchestrator: Spuštění funkce orchestrátoru nebo entity pro zpracování jedné nebo více zpráv instance

Pracovní procesy můžou zpracovávat více pracovních položek současně, a to v závislosti na nakonfigurovaných limitech souběžnosti jednotlivých pracovních procesů.

Jakmile pracovní proces dokončí pracovní položku, potvrdí efekty zpět do centra úloh. Tyto efekty se liší podle typu funkce, která byla provedena:

  • 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 orchestrace a historii 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.

Pro orchestrace představuje každá pracovní položka jednu epizodu provedení orchestrace. Epizoda začíná, když orchestrátor bude zpracovávat nové zprávy. Taková zpráva může znamenat, že orchestrace by měla začít; nebo může znamenat, že se dokončila 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žní zpracovat výsledek a pokračovat v další epizodě. Tato epizoda končí, když orchestrátor buď dokončí, nebo dosáhne bodu, kde musí čekat na nové zprávy.

Příklad provádění

Zvažte orchestraci ventilátorů, která spouští dvě aktivity paralelně, a čeká na dokončení obou z nich:

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

Po zahájení této orchestrace klientem ji zpracuje aplikace funkcí 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 spuštění nové orchestrace s ID instance 123. Po dokončení tohoto požadavku obsahuje centrum úloh zástupný symbol pro stav orchestrace a zprávu instance:

    workitems-illustration-step-1

    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á začne s prováděním kódu orchestrace. Tento kód naplánuje dvě aktivity a pak se zastaví při čekání na výsledky. Jakmile pracovní proces potvrdí tuto pracovní položku, centrum úloh obsahuje

    workitems-illustration-step-2

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

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

    workitems-illustration-step-3

  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 pokračovat v provádění. V opačném případě pracovní proces znovu přehraje historii, aby obnovil aktuální stav orchestrace. Pak pokračuje v orchestraci a dodává výsledek aktivity. Po přijetí tohoto výsledku orchestrace stále čeká na výsledek jiné aktivity, takže se znovu zastaví provádění. Jakmile pracovní proces potvrdí tuto pracovní položku, centrum úloh obsahuje

    workitems-illustration-step-4

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

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

    workitems-illustration-step-5

  6. Pracovní proces provede další pracovní položku orchestrátoruTaskCompleted, která zprávu zpracuje. Po přijetí tohoto druhého výsledku se orchestrace dokončí. Jakmile pracovní proces potvrdí tuto pracovní položku, centrum úloh obsahuje

    workitems-illustration-step-6

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

Konečná historie provedení této orchestrace pak obsahuje 12 událostí OrchestratorStarted, ExecutionStarted, , TaskScheduled, TaskCompletedOrchestratorStartedOrchestratorCompletedOrchestratorStartedOrchestratorCompletedTaskScheduled, , TaskCompleted. . ExecutionCompletedOrchestratorCompleted

Poznámka

Zobrazený plán není jediný: existuje mnoho mírně různých možných plánů. Pokud se například druhá aktivita dokončí dříve, můžou být obě TaskCompleted zprávy instance zpracovány jednou pracovní položkou. V takovém případě je historie provádění trochu kratší, protože existují pouze dvě epizody a obsahuje následující 10 událostí: OrchestratorStarted, , , OrchestratorCompletedExecutionStartedTaskCompletedTaskScheduledExecutionCompletedTaskScheduledTaskCompletedOrchestratorStartedOrchestratorCompleted.

Správa centra úloh

V dalším kroku 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é zkontrolovat obsah rozbočovačů úloh.

Vytvoření a odstranění

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

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ů pro 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ž nechcete tato data uchovávat, musíte centrum úloh, jeho obsah nebo účet úložiště odstranit ručně.

Tip

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

Více aplikací funkcí

Pokud více aplikací funkcí sdílí účet úložiště, musí být každá aplikace funkcí nakonfigurovaná s názvem samostatného 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 i 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.

Diagram znázorňující sdílené a vyhrazené účty úložiště

Poznámka

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

Kontrola obsahu

Obsah centra úloh můžete zkontrolovat několika běžnými způsoby:

  1. V rámci aplikace funkcí poskytuje klientský objekt metody 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 na 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 pro vizuální zobrazení.

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

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

Reprezentace v úložišti

Každý poskytovatel úložiště používá jinou interní organizaci k reprezentaci center úloh v úložišti. Pochopení této organizace, i když není povinné, 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 cílů nákladů. Stručně vysvětlujeme, jak jsou data uspořádaná v úložišti pro každého poskytovatele úložiště. Další informace o různých možnostech poskytovatele ú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:

  • Dvě tabulky Azure ukládají stavy instancí.
  • Jedna fronta Azure ukládá zprávy aktivit.
  • Jedna nebo více front Azure ukládá zprávy instance. Každá z těchto tzv. řídicích front představuje oddíl , který má přiřazenou podmnožinu všech zpráv instance na základě hodnoty hash ID instance.
  • Několik dalších kontejnerů objektů blob používaných pro zapůjčení objektů blob a/nebo velkých zpráv

Centrum úloh pojmenované xyzPartitionCount = 4 například obsahuje následující fronty a tabulky:

Diagram znázorňující organizaci úložiště úložiště zprostředkovatele služby Azure Storage pro 4 řídicí fronty

Dále popisujeme tyto komponenty a roli, kterou hrají podrobněji.

Další informace o tom, jak jsou centra úloh reprezentovaná poskytovatelem služby Azure Storage, najdete v dokumentaci k poskytovateli služby Azure Storage .

Zprostředkovatel úložiště Netherite

Netherite 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ílu.
  • Jedna tabulka Azure, která obsahuje publikované metriky týkající se oddílů.
  • Obor názvů Azure Event Hubs pro doručování zpráv mezi oddíly.

Například centrum úloh pojmenované s PartitionCount = 32 názvem mytaskhub je reprezentováno v úložišti následujícím způsobem:

Diagram znázorňující organizaci úložiště Netherite pro 32 oddílů

Poznámka

Veškerý stav centra úloh je uložený uvnitř 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é nakonfigurovat obor názvů Azure Event Hubs tak, aby se zprávy uchovály po výchozí době vypršení platnosti.

Netherite používá mechanismus zdroje událostí 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 aplikace funkcí musí být spuštěná při dotazování úložiště instancí.

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:

  • dt.History Tabulky dt.Instances ukládají stavy instancí.
  • Tabulka dt.NewEvents ukládá zprávy instance.
  • Tabulka dt.NewTasks ukládá zprávy o aktivitách.

Diagram znázorňující organizaci úložiště MSSQL

Pokud chcete povolit, aby více center úloh bylo možné nezávisle existovat ve stejné databázi, každá tabulka obsahuje TaskHub 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 identifikována 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élku 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 (Funkce 2.0)

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

host.json (Funkce 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 ukázkovém host.json souboru:

host.json (Funkce 1.0)

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

host.json (Funkce 2.0)

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

Název centra úloh 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 získat přístup k orchestracím nebo entitě, které žijí 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:

[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 jazyka C# je pro Durable Functions 2.x. Pro Durable Functions 1.x je nutné použít DurableOrchestrationContext místo IDurableOrchestrationContext. Další informace o rozdílech mezi verzemi najdete v článku Durable Functions verze.

Poznámka

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

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

Odolná verze rozšíření Výchozí název centra úloh
2.x Při nasazení v Azure se název centra úloh odvozuje z 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 to, co odlišuje jedno centrum úloh od jiného, když ve sdíleném účtu úložiště existuje 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ě bude více aplikací funkcí vzájemně soutěžit u zpráv, což může vést k nedefinovaným chování, včetně neočekávaně "zablokovaných" orchestrací ve Pending stavu nebo Running stavu.

Další kroky