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.

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

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í:

[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 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:

    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á 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

    workitems-illustration-step-2

    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

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

    workitems-illustration-step-4

    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

    workitems-illustration-step-5

  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

    workitems-illustration-step-6

    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 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 místní 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 aplikaci 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, jsou stavy instancí uložené 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 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ů. Pro každého poskytovatele úložiště proto stručně 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 s PartitionCount = 4 názvem xyz obsahuje následující fronty a tabulky:

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

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

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

Poskytovatel úložiště Netherite

Netherite rozdělí všechny stavy centra úloh na zadaný počet 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 je v úložišti reprezentováno takto:

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

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 tak, aby se zprávy uchovály po výchozí době 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 se dt.NewEvents ukládají zprávy instance.
  • V tabulce se dt.NewTasks ukládají zprávy o aktivitách.

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

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 identifikována názvem, který musí splňovat tato pravidla:

  • 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 (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 ú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 center ú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é 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:

[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 musíte místo IDurableOrchestrationContextpoužít DurableOrchestrationContext . Další informace o rozdílech mezi verzemi najdete v článku Durable Functions verze.

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