Feladatközpontok Durable Functions (Azure Functions)

A Durable Functions feladatközpontja az alkalmazás aktuális állapotát ábrázolja a tárolóban, beleértve az összes függőben lévő munkát is. Miközben egy függvényalkalmazás fut, a vezénylés, a tevékenység és az entitásfüggvények állapota folyamatosan tárolódik a feladatközpontban. Ez biztosítja, hogy az alkalmazás ott folytathatja a feldolgozást, ahol abbahagyta, ha az ideiglenes leállást vagy megszakítást követően újra kell indítani. Emellett lehetővé teszi a függvényalkalmazás számára a számítási feldolgozók dinamikus skálázását.

Elméletileg a feladatközpont a következő információkat tárolja:

• A példány az összes vezénylési és entitáspéldányt tartalmazza.
• A feldolgozandó üzenetek, beleértve a
  • minden olyan tevékenységüzenet , amely a futtatásra váró tevékenységeket jelöli.
  • minden példányüzenet , amely a példányokra való kézbesítésre vár.

A tevékenység- és példányüzenetek közötti különbség az, hogy a tevékenységüzenetek állapot nélküliek, így bárhol feldolgozhatók, míg a példányüzeneteket egy adott állapotalapú példánynak (vezénylésnek vagy entitásnak) kell kézbesíteni, amelyet a példányazonosító azonosít.

Belsőleg minden tárolószolgáltató más szervezetet használhat a példányállapotok és az üzenetek megjelenítésére. Az üzeneteket például az Azure Storage-szolgáltató tárolja az Azure Storage-üzenetsorokban, de az MSSQL-szolgáltató relációs táblákban. Ezek a különbségek nem számítanak az alkalmazás kialakítása szempontjából, de néhányuk befolyásolhatja a teljesítmény jellemzőit. Ezeket az alábbi Reprezentáció a tárolóban című szakaszban tárgyaljuk.

Munkaelemek

A tevékenységüzenetek és a példányüzenetek a feladatközpontban azt a munkát jelölik, amelyet a függvényalkalmazásnak fel kell dolgoznia. Miközben a függvényalkalmazás fut, folyamatosan lekéri a munkaelemeket a feladatközpontból. Minden munkaelem egy vagy több üzenetet dolgoz fel. Kétféle munkaelemet különböztetünk meg:

• Tevékenység munkaelemei: Tevékenységfüggvény futtatása tevékenységüzenet feldolgozásához.
• Vezénylő munkaelem: Vezénylő vagy entitásfüggvény futtatása egy vagy több példányüzenet feldolgozásához.

A feldolgozók egyszerre több munkaelemet is feldolgozhatnak, a feldolgozónkénti egyidejűségi korlátoknak megfelelően.

Miután egy feldolgozó befejezett egy munkaelemet, véglegesíti az effektusokat a feladatközpontban. Ezek a hatások a végrehajtott függvény típusától függően változnak:

• A befejezett tevékenységfüggvények létrehoznak egy példányüzenetet, amely tartalmazza az eredményt a szülő vezénylőpéldánynak címezve.
• A befejezett vezénylőfüggvény frissíti a vezénylés állapotát és előzményeit, és új üzeneteket hozhat létre.
• A befejezett entitásfüggvény frissíti az entitás állapotát, és új példányüzeneteket is létrehozhat.

Vezénylés esetén minden munkaelem a vezénylés végrehajtásának egy epizódját jelöli. Egy epizód akkor kezdődik, amikor a vezénylőnek új üzeneteket kell feldolgoznia. Egy ilyen üzenet azt jelezheti, hogy a vezénylésnek meg kell kezdődnie; vagy azt jelezheti, hogy egy tevékenység, entitáshívás, időzítő vagy alműhely befejeződött; vagy külső eseményt jelölhet. Az üzenet elindít egy munkaelemet, amely lehetővé teszi, hogy a vezénylő feldolgozza az eredményt, és folytassa a következő epizóddal. Ez az epizód akkor ér véget, amikor a vezénylő befejezi, vagy eléri azt a pontot, ahol meg kell várnia az új üzeneteket.

Végrehajtási példa

Fontolja meg a fan-out-fan-in vezénylést, amely két tevékenységet indít párhuzamosan, és mindkettő befejezésére vár:

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

Miután ezt a vezénylést egy ügyfél kezdeményezte, a függvényalkalmazás munkaelemek sorozataként dolgozza fel. Minden befejezett munkaelem frissíti a tevékenységközpont állapotát a véglegesítéskor. A lépések a következők:

1. Az ügyfél egy új vezénylés indítását kéri a példányazonosítóval (123). Miután az ügyfél teljesítette ezt a kérést, a feladatközpont tartalmaz egy helyőrzőt a vezénylési állapothoz és egy példányüzenetet:

   

   A címke ExecutionStarted a számos előzményesemény-típus egyike, amely azonosítja a vezénylés előzményeiben részt vevő különböző típusú üzeneteket és eseményeket.

2. A feldolgozó végrehajt egy vezénylő munkaelemet az ExecutionStarted üzenet feldolgozásához. Meghívja az orchestrator függvényt, amely megkezdi a vezénylési kód végrehajtását. Ez a kód két tevékenységet ütemez, majd leállítja a végrehajtást, amikor az eredményre vár. Miután a feldolgozó véglegesíti ezt a munkaelemet, a tevékenységközpont tartalmazza

   

   A futtatókörnyezet állapota most, Runningkét új TaskScheduled üzenet lett hozzáadva, és az előzmények mostantól tartalmazzák az öt eseményt OrchestratorStarted, , ExecutionStarted, TaskScheduled, TaskScheduled. OrchestratorCompleted Ezek az események a vezénylés végrehajtásának első epizódját képviselik.

3. A feldolgozó végrehajt egy tevékenység munkaelemet az TaskScheduled üzenetek feldolgozásához. Meghívja a tevékenységfüggvényt a "2" bemenettel. Amikor a tevékenységfüggvény befejeződik, létrehoz egy TaskCompleted üzenetet, amely tartalmazza az eredményt. Miután a feldolgozó véglegesíti ezt a munkaelemet, a tevékenységközpont tartalmazza

   

4. A feldolgozó végrehajt egy vezénylő munkaelemet az TaskCompleted üzenet feldolgozásához. Ha a vezénylés továbbra is gyorsítótárazva van a memóriában, folytathatja a végrehajtást. Ellenkező esetben a feldolgozó először visszajátssza az előzményeket a vezénylés aktuális állapotának helyreállításához. Ezután folytatja a vezénylést, és biztosítja a tevékenység eredményét. Miután megkapta ezt az eredményt, a vezénylés továbbra is a másik tevékenység eredményét várja, így ismét leállítja a végrehajtást. Miután a feldolgozó véglegesíti ezt a munkaelemet, a tevékenységközpont tartalmazza

   

   A vezénylés előzményei most már három további eseményt OrchestratorStartedtartalmaznak , , TaskCompleted. OrchestratorCompleted Ezek az események a vezénylés végrehajtásának második epizódját képviselik.

5. A feldolgozó végrehajt egy tevékenység-munkaelemet a fennmaradó TaskScheduled üzenet feldolgozásához. Meghívja a tevékenységfüggvényt az "1" bemenettel. Miután a feldolgozó véglegesíti ezt a munkaelemet, a tevékenységközpont tartalmazza

   

6. A feldolgozó egy másik vezénylő munkaelemet hajt végre az TaskCompleted üzenet feldolgozásához. A második eredmény fogadása után a vezénylés befejeződik. Miután a feldolgozó véglegesíti ezt a munkaelemet, a tevékenységközpont tartalmazza

   

   A futtatókörnyezet állapota most, Completedés a vezénylési előzmények négy további eseményt OrchestratorStartedtartalmaznak , TaskCompleted, , ExecutionCompleted. OrchestratorCompleted Ezek az események a vezénylés végrehajtásának harmadik és utolsó epizódját jelentik.

A vezénylés végrehajtásának utolsó előzményei ezután a 12 eseményt OrchestratorStartedtartalmazzák , , ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompletedOrchestratorCompletedTaskCompletedOrchestratorStartedOrchestratorCompletedTaskCompletedOrchestratorStartedExecutionCompleted.

Megjegyzés

Nem a megjelenített ütemezés az egyetlen: sok a lehetséges ütemezés. Ha például a második tevékenység korábban befejeződött, mindkét TaskCompleted példányüzenetet egyetlen munkaelem dolgozza fel. Ebben az esetben a végrehajtási előzmények egy kicsit rövidebbek, mert csak két epizód van, és a következő 10 eseményt tartalmazza: OrchestratorStarted, ExecutionStarted, TaskScheduled, TaskScheduled, OrchestratorCompleted, OrchestratorStarted, TaskCompleted, OrchestratorCompletedTaskCompletedExecutionCompleted.

Feladatközpont kezelése

Ezután nézzük meg közelebbről a feladatközpontok létrehozását vagy törlését, a feladatközpontok helyes használatát több függvényalkalmazás futtatásakor, valamint a feladatközpontok tartalmának vizsgálatát.

Létrehozás és törlés

Az összes szükséges erőforrást tartalmazó üres feladatközpont automatikusan létrejön a tárolóban, amikor első alkalommal elindít egy függvényalkalmazást.

Ha az alapértelmezett Azure Storage-szolgáltatót használja, nincs szükség további konfigurációra. Ellenkező esetben kövesse a tárolószolgáltatók konfigurálására vonatkozó utasításokat annak biztosítása érdekében, hogy a társzolgáltató megfelelően kiépítheti és hozzáférhessen a feladatközponthoz szükséges tárolási erőforrásokhoz.

Megjegyzés

A feladatközpont nem törlődik automatikusan a függvényalkalmazás leállítása vagy törlésekor. Ha már nem szeretné megőrizni ezeket az adatokat, manuálisan kell törölnie a feladatközpontot, annak tartalmát vagy a tárfiókot.

Tipp

Fejlesztési forgatókönyv esetén előfordulhat, hogy gyakran kell tiszta állapotból újraindulnia. Ehhez egyszerűen módosíthatja a konfigurált feladatközpont nevét. Ez egy új, üres feladatközpont létrehozását kényszeríti az alkalmazás újraindításakor. Vegye figyelembe, hogy ebben az esetben a régi adatok nem törlődnek.

Több függvényalkalmazás

Ha több függvényalkalmazás is osztozik egy tárfiókon, minden függvényalkalmazást külön feladatközpontnévvelkell konfigurálni. Ez a követelmény az előkészítési pontokra is vonatkozik: minden egyes előkészítési pontot egyedi feladatközpont-névvel kell konfigurálni. Egyetlen tárfiók több feladatközpontot is tartalmazhat. Ez a korlátozás általában más tárolószolgáltatókra is vonatkozik.

Az alábbi ábra függvényalkalmazásonként egy feladatközpontot mutat be megosztott és dedikált Azure Storage-fiókokban.

Megjegyzés

A feladatközpont-megosztási szabály alól kivételt képez, ha az alkalmazást regionális vészhelyreállításra konfigurálja. További információért tekintse meg a vészhelyreállításról és a geoterjesztésről szóló cikket.

Tartalomvizsgálat

A feladatközpontok tartalmának vizsgálatára számos gyakori módszer létezik:

1. A függvényalkalmazásban az ügyfélobjektum metódusokat biztosít a példánytároló lekérdezéséhez. Ha többet szeretne megtudni arról, hogy milyen típusú lekérdezések támogatottak, olvassa el az Példánykezelés című cikket.
2. Ehhez hasonlóan a HTTP API REST-kéréseket is kínál a vezénylések és entitások állapotának lekérdezéséhez. További részletekért tekintse meg a HTTP API-referenciát .
3. A Durable Functions Monitor eszköz képes megvizsgálni a feladatközpontokat, és különböző lehetőségeket kínál a vizuális megjelenítéshez.

Egyes tárolószolgáltatók esetében a feladatközpontot közvetlenül az alapul szolgáló tárolóba is megvizsgálhatja:

• Ha az Azure Storage-szolgáltatót használja, a példányállapotok a példánytáblában és az előzménytáblában vannak tárolva, amelyek például az Azure Storage Explorer használatával vizsgálhatók meg.
• Ha az MSSQL-tárolószolgáltatót használja, AZ SQL-lekérdezések és -eszközök segítségével megvizsgálhatja a feladatközpont tartalmát az adatbázisban.

Reprezentáció a tárolóban

Minden tárolószolgáltató egy másik belső szervezetet használ a tárolóban lévő feladatközpontok ábrázolására. A szervezet megértése, bár nem szükséges, hasznos lehet a függvényalkalmazások hibaelhárítása során, illetve a teljesítmény, a méretezhetőség vagy a költségcélok biztosításának megkísérlésekor. Ezért röviden ismertetjük, hogy az egyes tárolószolgáltatók hogyan rendezik az adatokat a tárolóban. A különböző tárolószolgáltatói lehetőségekről és azok összehasonlításáról a Durable Functions tárolószolgáltatók című témakörben talál további információt.

Azure Storage-szolgáltató

Az Azure Storage-szolgáltató a tárolóban lévő feladatközpontot jelöli a következő összetevők használatával:

• Két Azure-tábla tárolja a példányállapotokat.
• Egy Azure Queue tárolja a tevékenységüzeneteket.
• Egy vagy több Azure Queues tárolja a példányüzeneteket. Az úgynevezett vezérlősorok mindegyike egy partíciót jelöl, amely az összes példányüzenet egy részhalmazához van hozzárendelve a példányazonosító kivonata alapján.
• Néhány további blobtároló, amelyeket a blobok és/vagy nagy méretű üzenetek bérletéhez használnak.

Egy nevű xyzPartitionCount = 4 feladatközpont például a következő üzenetsorokat és táblákat tartalmazza:

Ezután részletesebben ismertetjük ezeket az összetevőket és azok szerepét.

A feladatközpontok Azure Storage-szolgáltató általi ábrázolásáról az Azure Storage-szolgáltató dokumentációjában talál további információt.

Netherite storage provider

A Netherite az összes tevékenységközpont-állapotot meghatározott számú partícióra particionálja. A tárterületen a következő erőforrásokat használja a rendszer:

• Egy Azure Storage-blobtároló, amely az összes blobot tartalmazza, partíciók szerint csoportosítva.
• Egy Azure-tábla, amely közzétett metrikákat tartalmaz a partíciókról.
• Egy Azure Event Hubs névtér az üzenetek partíciók közötti kézbesítéséhez.

Egy nevű feladatközpont mytaskhubPartitionCount = 32 például a következő módon jelenik meg a tárolóban:

Megjegyzés

A rendszer az összes tevékenységközpont-állapotot a x-storage blobtárolóban tárolja. A DurableTaskPartitions tábla és az EventHubs-névtér redundáns adatokat tartalmaz: ha a tartalmuk elveszik, azok automatikusan helyreállíthatók. Ezért nem szükséges konfigurálni a Azure Event Hubs névteret az üzenetek alapértelmezett lejárati időn túli megőrzéséhez.

A Netherite egy naplón és ellenőrzőpontokon alapuló eseményforrás-mechanizmust használ a partíció aktuális állapotának ábrázolására. A rendszer blokkblobokat és lapblobokat is használ. Ezt a formátumot nem lehet közvetlenül a tárolóból beolvasni, ezért a függvényalkalmazásnak futnia kell a példánytároló lekérdezésekor.

A Netherite-tárolószolgáltató feladatközpontjaival kapcsolatos további információkért lásd: Task Hub information for the Netherite storage provider (Feladatközpont-információk a Netherite-tárolószolgáltatóhoz).

MSSQL-tárolószolgáltató

A tevékenységközpont összes adata egyetlen relációs adatbázisban van tárolva, több tábla használatával:

• A dt.Instances és dt.History a tábla tárolja a példányállapotokat.
• A dt.NewEvents tábla tárolja a példányüzeneteket.
• A dt.NewTasks tábla a tevékenységüzeneteket tárolja.

Ahhoz, hogy több tevékenységközpont egymástól függetlenül létezhessen ugyanabban az adatbázisban, minden tábla tartalmaz egy TaskHub oszlopot az elsődleges kulcs részeként. A másik két szolgáltatótól eltérően az MSSQL-szolgáltató nem rendelkezik partíciók fogalmával.

Az MSSQL-tárolószolgáltató feladatközpontjaival kapcsolatos további információkért lásd: A Microsoft SQL (MSSQL) tárolószolgáltató tevékenységközpont-információi.

Tevékenységközpontok nevei

A feladatközpontokat az alábbi szabályoknak megfelelő név azonosítja:

• Csak alfanumerikus karaktereket tartalmaz
• Betűvel kezdődik
• Legalább 3 karakter hosszú, legfeljebb 45 karakter hosszúságú

A feladatközpont neve a host.json fájlban deklarálva van, ahogy az alábbi példában látható:

host.json (Functions 2.0)

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

host.json (Functions 1.x)

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

A feladatközpontok alkalmazásbeállítások használatával is konfigurálhatók, ahogyan az alábbi host.json példafájlban látható:

host.json (Functions 1.0)

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

host.json (Functions 2.0)

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

A feladatközpont neve az alkalmazásbeállítás értékére MyTaskHub lesz beállítva. A következő local.settings.json bemutatja, hogyan definiálhatja a beállítást a MyTaskHub következőként samplehubname:

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

Megjegyzés

Üzembehelyezési pontok használata esetén ajánlott az alkalmazásbeállítások használatával konfigurálni a feladatközpont nevét. Ha meg szeretné győződni arról, hogy egy adott pont mindig egy adott feladatközpontot használ, használja a "slot-sticky" alkalmazásbeállításokat.

A host.json mellett a feladatközpontok nevei konfigurálhatók a vezénylési ügyfélkötés metaadataiban is. Ez akkor hasznos, ha egy külön függvényalkalmazásban élő vezénylésekhez vagy entitásokhoz kell hozzáférnie. Az alábbi kód bemutatja, hogyan írhat olyan függvényt, amely a vezénylési ügyfélkötést használja egy alkalmazásbeállításként konfigurált feladatközponttal való együttműködéshez:

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

Megjegyzés

Az előző példa a 2.x Durable Functions. Az 1.x Durable Functions helyett a parancsot kell használnia DurableOrchestrationContextIDurableOrchestrationContext. A verziók közötti különbségekről a verziók Durable Functions című cikkben talál további információt.

JavaScript

A feladatközpont tulajdonsága a function.json fájlban alkalmazásbeállítással van beállítva:

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

Megjegyzés

Ez a példa Durable Functions 2.x verziót célozza meg. Az 1.x verzióban a helyett használja a parancsot orchestrationClientdurableClient.

Python

A feladatközpont tulajdonsága a function.json fájlban alkalmazásbeállítással van beállítva:

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

Megjegyzés

Ez a példa Durable Functions 2.x verziót célozza meg. Az 1.x verzióban a helyett használja a parancsot orchestrationClientdurableClient.

PowerShell

A feladatközpont tulajdonsága a function.json fájlban alkalmazásbeállítással van beállítva:

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

Megjegyzés

Ez a példa Durable Functions 2.x verziót célozza meg. Az 1.x verzióban a helyett használja a parancsot orchestrationClientdurableClient.

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

Megjegyzés

A feladatközpontok nevének konfigurálása az ügyfélkötési metaadatokban csak akkor szükséges, ha egy függvényalkalmazással fér hozzá egy másik függvényalkalmazás vezényléseihez és entitásaihoz. Ha az ügyfélfüggvények ugyanabban a függvényalkalmazásban vannak definiálva, mint a vezénylések és az entitások, kerülje a feladatközpontok nevének megadását a kötési metaadatokban. Alapértelmezés szerint minden ügyfélkötés lekéri a feladatközpont metaadatait a host.json beállításokból.

A feladatközpontok nevének betűvel kell kezdődnie, és csak betűkből és számokból állhat. Ha nincs megadva, a rendszer egy alapértelmezett feladatközpont-nevet használ az alábbi táblázatban látható módon:

Tartós bővítmény verziója	Alapértelmezett tevékenységközpont neve
2.x	Az Azure-ban való üzembe helyezéskor a feladatközpont neve a függvényalkalmazás nevéből származik. Ha az Azure-on kívül fut, az alapértelmezett feladatközpont neve .TestHubName
1.x	A tevékenységközpont alapértelmezett neve az összes környezethez: DurableFunctionsHub.

A bővítményverziók közötti különbségekről a Durable Functions verziók című cikkben talál további információt.

Megjegyzés

A név különbözteti meg az egyik feladatközpontot a másiktól, ha egy megosztott tárfiókban több feladatközpont található. Ha több függvényalkalmazás osztozik egy megosztott tárfiókon, explicit módon konfigurálnia kell a különböző neveket az egyes feladatközpontokhoz a host.json fájlokban. Ellenkező esetben a több függvényalkalmazás versenyezni fog egymással az üzenetekért, ami meghatározatlan viselkedést eredményezhet, beleértve a vezényléseket is, amelyek váratlanul "elakadnak" az vagy Running állapotbanPending.

Következő lépések

Útmutató a vezénylési verziószámozás kezeléséhez