Lagringsproviders för Durable Functions

Durable Functions är en uppsättning Azure Functions-utlösare och bindningar som drivs internt av Durable Task Framework (DTFx). DTFx stöder olika serverdelslagringsproviders, inklusive Azure Storage-providern som används av Durable Functions. Från och med Durable Functions v2.5.0 kan användarna konfigurera sina funktionsappar så att de använder andra DTFx-lagringsleverantörer än Azure Storage-providern.

Kommentar

För många funktionsappar räcker det troligtvis med att Azure Storage-standardprovidern för Durable Functions räcker och är den enklaste att använda eftersom den inte kräver någon extra konfiguration. Det finns dock kostnads-, skalbarhets- och datahanteringsavvägningar som kan gynna användningen av en alternativ lagringsprovider.

Två alternativa lagringsproviders har utvecklats för användning med Durable Functions och Durable Task Framework, nämligen Netherite Storage-providern och Lagringsprovidern Microsoft SQL Server (MSSQL). Den här artikeln beskriver alla tre leverantörer som stöds, jämför dem med varandra och ger grundläggande information om hur du kommer igång med att använda dem.

Kommentar

Det går för närvarande inte att migrera data från en lagringsprovider till en annan. Om du vill använda en ny lagringsprovider bör du skapa en ny app som konfigurerats med den nya lagringsprovidern.

Azure Storage

Azure Storage är standardlagringsprovidern för Durable Functions. Den använder köer, tabeller och blobar för att bevara orkestrerings- och entitetstillstånd. Den använder också blobar och bloblån för att hantera partitioner. I många fall är lagringskontot som används för att lagra Durable Functions-körningstillstånd samma som standardlagringskontot som används av Azure Functions (AzureWebJobsStorage). Det är dock också möjligt att konfigurera Durable Functions med ett separat lagringskonto. Azure Storage-providern är inbyggd i Durable Functions-tillägget och har inga andra beroenden.

De viktigaste fördelarna med Azure Storage-providern är:

  • Ingen installation krävs – du kan använda lagringskontot som skapades åt dig av funktionsappens konfigurationsupplevelse.
  • Serverlös faktureringsmodell med lägsta kostnad – Azure Storage har en förbrukningsbaserad prismodell som helt baseras på användning (mer information).
  • Bästa stöd för verktyg – Azure Storage erbjuder plattformsoberoende lokal emulering och integreras med Visual Studio, Visual Studio Code och Azure Functions Core Tools.
  • Mest mogen – Azure Storage var den ursprungliga och mest stridstestade lagringsserverdelen för Durable Functions.
  • Stöd för att använda identitet i stället för hemligheter för att ansluta till lagringsprovidern.

Källkoden för DTFx-komponenterna i Azure Storage-lagringsprovidern finns på GitHub-lagringsplatsen Azure/durabletask .

Kommentar

Azure Storage-standardkonton för generell användning krävs när du använder Azure Storage-providern. Alla andra typer av lagringskonton stöds inte. Vi rekommenderar starkt att du använder äldre v1-lagringskonton för generell användning eftersom de nyare v2-lagringskontona kan vara betydligt dyrare för Durable Functions-arbetsbelastningar. Mer information om Azure Storage-kontotyper finns i översiktsdokumentationen för lagringskontot.

Netherite

Netherite Storage-serverdelen har utformats och utvecklats av Microsoft Research. Den använder Azure Event Hubs och FASTER-databastekniken ovanpå Azure Page Blobs. Netherite-designen möjliggör betydligt högre dataflödesbearbetning av orkestreringar och entiteter jämfört med andra leverantörer. I vissa benchmark-scenarier visade sig dataflödet öka med mer än en storleksordning jämfört med standardleverantören för Azure Storage.

De viktigaste fördelarna med Netherite-lagringsprovidern är:

  • Betydligt högre dataflöde till lägre kostnad jämfört med andra lagringsleverantörer.
  • Har stöd för pris-prestandaoptimering så att du kan skala upp prestanda efter behov.
  • Stöder upp till 32 datapartitioner med Event Hubs Basic- och Standard-SKU:er.
  • Mer kostnadseffektivt än andra leverantörer för arbetsbelastningar med högt dataflöde.

Du kan läsa mer om teknisk information om Netherite-lagringsprovidern, inklusive hur du kommer igång med att använda den, i Netherite-dokumentationen. Källkoden för Netherite-lagringsprovidern finns på GitHub-lagringsplatsen microsoft/durabletask-netherite . En mer djupgående utvärdering av Netherite-lagringsprovidern finns också i följande forskningsdokument: Serverlösa arbetsflöden med Durable Functions och Netherite.

Kommentar

Netherite-namnet kommer från Minecrafts värld.

Microsoft SQL Server (MSSQL)

Microsoft SQL Server-lagringsprovidern (MSSQL) bevarar alla tillstånd i en Microsoft SQL Server-databas. Den är kompatibel med både lokala och molnbaserade distributioner av SQL Server, inklusive Azure SQL Database.

De viktigaste fördelarna med MSSQL-lagringsprovidern är:

  • Stöder frånkopplade miljöer – ingen Azure-anslutning krävs när du använder en SQL Server-installation.
  • Bärbar över flera miljöer och moln, inklusive Azure-värdbaserade och lokala miljöer.
  • Stark datakonsekvens, aktivering av säkerhetskopiering/återställning och redundans utan dataförlust.
  • Internt stöd för anpassad datakryptering (en funktion i SQL Server).
  • Integrerar med befintliga databasprogram via inbyggda lagrade procedurer.

Du kan läsa mer om teknisk information om MSSQL-lagringsprovidern, inklusive hur du kommer igång med att använda den, i dokumentationen för Microsoft SQL-providern. Källkoden för MSSQL-lagringsprovidern finns på GitHub-lagringsplatsen microsoft/durabletask-mssql .

Konfigurera alternativa lagringsproviders

Att konfigurera alternativa lagringsproviders är vanligtvis en tvåstegsprocess:

  1. Lägg till lämpligt NuGet-paket i funktionsappen (det här kravet är tillfälligt för appar som använder tilläggspaket).
  2. Uppdatera host.json-filen för att ange vilken lagringsprovider du vill använda.

Om ingen lagringsprovider uttryckligen konfigureras i host.json aktiveras Azure Storage-providern som standard.

Konfigurera Azure Storage-providern

Azure Storage-providern är standardlagringsprovidern och kräver ingen explicit konfiguration, NuGet-paketreferenser eller tilläggspaketreferenser. Du hittar den fullständiga uppsättningen med host.json konfigurationsalternativ här under extensions/durableTask/storageProvider sökvägen.

anslutningar

Egenskapen connectionName i host.json är en referens till miljökonfigurationen som anger hur appen ska ansluta till Azure Storage. Den kan ange:

  • Namnet på en programinställning som innehåller en anslutningssträng. För att få en anslutningssträng följer du stegen som visas i Hantera åtkomstnycklar för lagringskonto.
  • Namnet på ett delat prefix för flera programinställningar, som tillsammans definierar en identitetsbaserad anslutning.

Om det konfigurerade värdet både är en exakt matchning för en enskild inställning och en prefixmatchning för andra inställningar används den exakta matchningen. Om inget värde anges i host.json är standardvärdet "AzureWebJobsStorage".

Identitetsbaserade anslutningar

Om du använder version 2.7.0 eller senare av tillägget och Azure Storage-providern kan du i stället för att använda en anslutningssträng med en hemlighet låta appen använda en Microsoft Entra-identitet. För att göra detta definierar du inställningar under ett vanligt prefix som mappar till connectionName egenskapen i utlösar- och bindningskonfigurationen.

Om du vill använda en identitetsbaserad anslutning för Durable Functions konfigurerar du följande appinställningar:

Property Miljövariabelmall beskrivning Exempelvärde
URI för blobtjänst <CONNECTION_NAME_PREFIX>__blobServiceUri Dataplanets URI för blobtjänsten för lagringskontot med hjälp av HTTPS-schemat. <https:// storage_account_name.blob.core.windows.net>
Kötjänst-URI <CONNECTION_NAME_PREFIX>__queueServiceUri Dataplanets URI för kötjänsten för lagringskontot med hjälp av HTTPS-schemat. <https:// storage_account_name.queue.core.windows.net>
Tabelltjänst-URI <CONNECTION_NAME_PREFIX>__tableServiceUri Dataplanets URI för en tabelltjänst för lagringskontot med hjälp av HTTPS-schemat. <https:// storage_account_name.table.core.windows.net>

Ytterligare egenskaper kan anges för att anpassa anslutningen. Se Vanliga egenskaper för identitetsbaserade anslutningar.

När identitetsbaserade anslutningar finns i Azure Functions-tjänsten använder de en hanterad identitet. Den systemtilldelade identiteten används som standard, även om en användartilldelad identitet kan anges med credential egenskaperna och clientID . Observera att det inte går att konfigurera en användartilldelad identitet med ett resurs-ID. När den körs i andra sammanhang, till exempel lokal utveckling, används utvecklaridentiteten i stället, även om den kan anpassas. Se Lokal utveckling med identitetsbaserade anslutningar.

Bevilja behörighet till identiteten

Den identitet som används måste ha behörighet att utföra de avsedda åtgärderna. För de flesta Azure-tjänster innebär det att du måste tilldela en roll i Azure RBAC med hjälp av antingen inbyggda eller anpassade roller som ger dessa behörigheter.

Viktigt!

Vissa behörigheter kan exponeras av måltjänsten som inte är nödvändiga för alla kontexter. Om möjligt följer du principen om minsta behörighet och beviljar identiteten endast nödvändiga privilegier. Om appen till exempel bara behöver kunna läsa från en datakälla använder du en roll som bara har behörighet att läsa. Det skulle vara olämpligt att tilldela en roll som också tillåter skrivning till tjänsten, eftersom detta skulle vara överdriven behörighet för en läsåtgärd. På samma sätt vill du se till att rolltilldelningen endast är begränsad till de resurser som behöver läsas.

Du måste skapa en rolltilldelning som ger åtkomst till Azure Storage vid körning. Hanteringsroller som Ägare räcker inte. Följande inbyggda roller rekommenderas när du använder Durable Functions-tillägget i normal drift:

Programmet kan kräva fler behörigheter baserat på den kod du skriver. Om du använder standardbeteendet eller uttryckligen anger connectionName "AzureWebJobsStorage" läser du Ansluta till värdlagring med en identitet för andra behörighetsöverväganden.

Konfigurera Netherite-lagringsprovidern

För att aktivera Netherite-lagringsprovidern krävs en konfigurationsändring i .host.json För C#-användare krävs även ytterligare ett installationssteg.

host.json konfiguration

Följande host.json exempel visar den minsta konfiguration som krävs för att aktivera Netherite-lagringsprovidern.

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "type": "Netherite",
        "storageConnectionName": "AzureWebJobsStorage",
        "eventHubsConnectionName": "EventHubsConnection"
      }
    }
  }
}

Mer detaljerade installationsinstruktioner finns i dokumentationen om att komma igång med Netherite.

Installera Netherite-tillägget (endast.NET)

Kommentar

Om appen använder tilläggspaket bör du ignorera det här avsnittet eftersom tilläggspaket tar bort behovet av manuell tilläggshantering.

Du måste installera den senaste versionen av Netherite-tillägget på NuGet. Det innebär vanligtvis att du inkluderar en referens till den i .csproj filen och skapar projektet.

Vilket tilläggspaket som ska installeras beror på vilken .NET-arbetare du använder:

Konfigurera MSSQL-lagringsprovidern

För att aktivera MSSQL-lagringsprovidern krävs en konfigurationsändring i .host.json För C#-användare krävs även ytterligare ett installationssteg.

host.json konfiguration

I följande exempel visas den minsta konfiguration som krävs för att aktivera MSSQL-lagringsprovidern.

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "type": "mssql",
        "connectionStringName": "SQLDB_Connection"
      }
    }
  }
}

Mer detaljerade installationsinstruktioner finns i dokumentationen för MSSQL-providerns komma igång.

Installera MSSQL-tillägget durable task (endast.NET)

Kommentar

Om appen använder tilläggspaket bör du ignorera det här avsnittet eftersom tilläggspaket tar bort behovet av manuell tilläggshantering.

Du måste installera den senaste versionen av MSSQL-lagringsprovidertillägget på NuGet. Det innebär vanligtvis att du inkluderar en referens till den i .csproj filen och skapar projektet.

Vilket tilläggspaket som ska installeras beror på vilken .NET-arbetare du använder:

Jämföra lagringsprovidrar

Det finns många betydande kompromisser mellan de olika lagringsleverantörer som stöds. Följande tabell kan användas för att hjälpa dig att förstå dessa kompromisser och avgöra vilken lagringsprovider som passar bäst för dina behov.

Lagringsprovider Azure Storage Netherite MSSQL
Officiell supportstatus ✅ Allmänt tillgänglig (GA) ✅ Allmänt tillgänglig (GA) ✅ Allmänt tillgänglig (GA)
Externa beroenden Azure Storage-konto (generell användning v1) Azure Event Hubs
Azure Storage-konto (generell användning)
SQL Server 2019 eller Azure SQL Database
Alternativ för lokal utveckling och emulering Azurite v3.12+ (plattformsoberoende) Stöder minnesintern emulering av aktivitetshubbar (mer information) SQL Server Developer Edition (stöder Windows-, Linux- och Docker-containrar)
Konfiguration av aktivitetshubben Explicit Explicit Implicit som standard (mer information)
Maximalt dataflöde Måttlig Mycket högt Måttlig
Maximal orkestrering/utskalning av entitet (noder) 16 32 Ej tillämpligt
Maximal aktivitetsutskalning (noder) Ej tillämpligt 32 Ej tillämpligt
Stöd för KEDA 2.0-skalning
(Mer information)
❌ Stöds inte ❌ Stöds inte ✅Stöds med MSSQL-skalning (mer information)
Stöd för tilläggspaket (rekommenderas för non-.NET appar) ✅ Stöds fullt ut ✅ Stöds fullt ut ✅ Stöds fullt ut
Kan du konfigurera prisprestanda? ❌ Nej ✅ Ja (Event Hubs-RU:er och CU:er) ✅ Ja (SQL vCPU:er)
Frånkopplad omgivningsstöd ❌ Azure-anslutning krävs ❌ Azure-anslutning krävs ✅ Stöds fullt ut
Identitetsbaserade anslutningar ✅ Stöds fullt ut ❌ Stöds inte ⚠️ Kräver körningsdriven skalning

Nästa steg