Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Important
Stödet för den pågående processmodellen kommer att upphöra den 10 november 2026. Vi rekommenderar starkt att du migrerar dina appar till den isolerade arbetsmodellen för fullt stöd.
Durable Functions-körningen bevarar automatiskt funktionsparametrar, returvärden och annat tillstånd till task hub för att tillhandahålla pålitlig exekvering. Mängden och frekvensen för data som sparas till varaktig lagring kan dock påverka programprestanda och kostnader för lagringstransaktioner. Beroende på vilken typ av data som ditt program lagrar kan även datakvarhållnings- och sekretesspolicyer behöva beaktas.
Den här artikeln förklarar vilka data som sparas, hur du hanterar stora nyttolaster och känsliga data och hur du anpassar serialisering för varje språk som stöds.
I den här artikeln:
- Innehåll i aktivitetshubben – vilka data som lagras och hur
- Håll indata och utdata små – Strategier för att hantera nyttolaststorlek
- Arbeta med känsliga data – Skydda hemligheter och personligt identifierbar information
- Skydda din uppgiftshubblagring – Skydda lagringsserverdelen från obehörig åtkomst
- Anpassa serialisering och deserialisering – Språkspecifika serialiseringsalternativ
Innehåll i aktivitetshubben
Uppgiftshubbar lagrar det aktuella tillståndet för instanser och eventuella väntande meddelanden:
- Instanstillstånd lagrar den aktuella statusen och historiken för en instans. För orkestreringsinstanser omfattar det här tillståndet körtillstånd, orkestreringshistorik, indata, utdata och anpassad status. För entitetsinstanser innehåller den entitetstillståndet.
- Meddelanden lagrar funktionsindata eller utdata, händelsenyttolaster och metadata som används för interna ändamål, till exempel routning och korrelation från slutpunkt till slutpunkt.
Meddelanden tas bort när de har bearbetats, men instanstillstånden kvarstår om de inte uttryckligen tas bort av programmet eller en operatör. I synnerhet finns en orkestreringshistorik kvar i lagringen även efter att orkestreringen har slutförts.
Ett exempel på hur tillstånd och meddelanden representerar förloppet för en orkestrering finns i körningsexemplet för aktivitetshubben.
Var och hur tillstånd och meddelanden representeras i lagringen beror på lagringsprovidern. Använd Durable Task Scheduler eftersom den tillhandahåller en hanterad backend-lösning för task hubs och hanterar den underliggande tillståndslagringen åt dig. Men Azure Storage är fortfarande ett stabilt alternativ för befintliga arbetsbelastningar och för appar som vill hantera sina egna lagringsresurser.
| Lagringsleverantör | Hur tillstånd lagras | Rekommenderad användning |
|---|---|---|
| Schemaläggare för varaktiga uppgifter | Orkestrering och entitetstillstånd lagras i det hanterade schemaläggarens backend-system bakom en task hub-resurs. | Föredraget alternativ för nya Durable Functions-appar och hanterade distributioner. |
| Azure Storage | Tillstånd och meddelanden representeras i köer, tabeller och blobs i ett Azure Storage-konto. | Bra passform för befintliga appar eller installationer som redan är beroende av Azure Storage. |
Typer av data som serialiseras och bevaras
I följande lista visas de olika typer av data som ska serialiseras och sparas när du använder funktioner i Durable Functions:
- Alla indata och utdata från orkestrerings-, aktivitets- och entitetsfunktioner, inklusive eventuella ID:n och ohanterade undantag
- Orkestrerings-, aktivitets- och entitetsfunktionsnamn
- Namn och nyttolaster för externa händelser
- Anpassade nyttolaster för orkestreringsstatus
- Meddelanden om orkestreringsavslut
- Varaktiga tidsinställda nyttolaster
- Varaktiga URL:er för HTTP-begäranden och svar, huvuden och nyttolaster
- Entitetsanrop och signaldatapaket
- Dataöverföring för entitetstillstånd
Vägledning om hur du hanterar nyttolaststorlek och skyddar känsliga objekt i den här listan finns i följande avsnitt.
Håll Durable Functions indata och utdata små
Du kan stöta på minnesproblem om du tillhandahåller stora indata och utdata till och från Durable Functions-API:er. Indata och utdata serialiseras i orkestreringshistoriken, vilket innebär att stora nyttolaster med tiden i hög grad kan bidra till obundna historiktillväxt. Den här tillväxten riskerar att orsaka minnesundantag vid återspelning.
För att minska effekten av stora indata och utdata kan du:
- Delegera arbete till underorkestrerare för att belastningsbalansera minnesbördan för historiken över flera orkestratorer, vilket håller minnets fotavtryck för enskilda historier litet.
- Lagra stora data i extern lagring (till exempel Azure Blob Storage) och skicka lätta identifierare som gör att du kan hämta dessa data i aktivitetsfunktioner när det behövs.
För Durable Task Scheduler, använd stöd för stor nyttolast för att avlasta större nyttolaster till Azure Blob Storage. För nya appar rekommenderas detta mönster när en orkestrering måste överföra stora payloads mellan hållbara operationer. Om du använder Azure Storage-leverantören kan du fortfarande tillämpa claim-check-mönstret som visas i följande avsnitt och skicka lättviktsreferenser mellan operationerna.
Tip
Det bästa sättet att hantera stora data är att lagra dem i extern lagring och materialisera dessa data endast i aktiviteter när det behövs.
Skicka referenser till stora datanyttolaster
Välj det mönster som passar din förvaringsleverantör.
Schemaläggare för varaktiga uppgifter
Om du använder Durable Task Scheduler, aktivera stöd för stora nyttolaster så att runtimen skriver större nyttolaster till Azure Blob Storage och skickar en liten referens genom schemaläggaren. En typisk konfiguration visas i schemaläggarens dokumentation:
{
"version": "2.0",
"extensions": {
"durableTask": {
"storageProvider": {
"type": "azureManaged",
"connectionStringName": "DTS_CONNECTION_STRING",
"payloadStorageEnabled": true,
"payloadStorageThresholdBytes": 262144
},
"hubName": "%TASKHUB_NAME%"
}
}
}
Azure Storage
Med Azure Storage-leverantören kan du använda Claim Check-mönstret för att hålla orkestreringshistoriken liten samtidigt som du bearbetar stora payloads. Orkestreraren skickar en lätt referens som innehåller blobcontainern och blobnamnet, och aktiviteten läser eller skriver nyttolasten från Azure Blob Storage vid behov.
Följande exempel antar att du redan har en blob i ditt lagringskonto. Börja orkestreringen med en referens som {"container":"large-payloads","blobName":"input/job-123.json"}. Aktiviteten skapar utdatabehållaren processed-payloads om det behövs. Samplingsbearbetningssteget kopierar indatabytena oförändrade; Byt ut den mot din applikationslogik.
Important
Inkludera aldrig lagringsuppgifter eller en shared access-signatur (SAS) i referensen. Systemet sparar referensen i orkestreringshistoriken. Dessa exempel använder en app-inställning som är namngiven PAYLOAD_STORAGE_CONNECTION_STRING för att hålla lagringskoden kortfattad. För produktionsarbetsbelastningar, använd Microsoft Entra ID för att auktorisera åtkomst till blobdata.
Detta exempel kräver Azure. Storage.Blobs NuGet-paket.
using System;
using System.Threading.Tasks;
using Azure.Storage.Blobs;
using Microsoft.Azure.Functions.Worker;
using Microsoft.DurableTask;
public record BlobReference(string Container, string BlobName);
public static class LargePayloadFunctions
{
[Function("ProcessLargePayload")]
public static async Task<BlobReference> RunOrchestrator(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
BlobReference inputReference = context.GetInput<BlobReference>()
?? throw new InvalidOperationException("A blob reference is required.");
return await context.CallActivityAsync<BlobReference>(
nameof(ProcessLargePayloadActivity), inputReference);
}
[Function(nameof(ProcessLargePayloadActivity))]
public static async Task<BlobReference> ProcessLargePayloadActivity(
[ActivityTrigger] BlobReference inputReference)
{
string connectionString =
Environment.GetEnvironmentVariable("PAYLOAD_STORAGE_CONNECTION_STRING")
?? throw new InvalidOperationException("Payload storage is not configured.");
BlobServiceClient service = new BlobServiceClient(connectionString);
BlobClient inputBlob = service
.GetBlobContainerClient(inputReference.Container)
.GetBlobClient(inputReference.BlobName);
BinaryData inputData = (await inputBlob.DownloadContentAsync()).Value.Content;
BlobContainerClient outputContainer =
service.GetBlobContainerClient("processed-payloads");
await outputContainer.CreateIfNotExistsAsync();
string outputName = $"processed/{Guid.NewGuid():N}.json";
await outputContainer.GetBlobClient(outputName)
.UploadAsync(inputData, overwrite: true);
return new BlobReference(outputContainer.Name, outputName);
}
}
Om parallella aktiviteter ger flera stora resultat, returnera en lista med referenser och skicka den listan till en slutlig aggregeringsaktivitet. Aggregeringsaktiviteten ska läsa in och kombinera innehållet och sedan skriva en slutlig utdatablob. Ladda inte in eller sammanfoga de stora resultaten i orkestratören.
Arbeta med känsliga data
Indata och utdata (inklusive undantag) till och från Durable Functions API:er sparas på lämpligt sätt i din lagringsprovider. Om dessa indata, utdata eller undantag innehåller känsliga data (till exempel hemligheter, anslutningssträngar eller personligt identifierbar information) kan alla som har läsåtkomst till lagringsleverantörens resurser få dem.
Om du vill hantera känsliga data på ett säkert sätt hämtar du dessa data i aktivitetsfunktioner från antingen Azure Key Vault- eller miljövariabler och kommunicerar aldrig dessa data direkt till eller från orkestrerare eller entiteter. Den här metoden hjälper till att förhindra att känsliga data läcker ut i dina lagringsresurser.
På samma sätt måste skrivåtkomst till lagringsresurser kontrolleras noggrant, eftersom manipulerade data i lagringen kan ändra orkestreringsbeteendet. Mer information om hur du skyddar lagring av uppgiftshubbar finns i Skydda din uppgiftshubblagring.
Tip
Den här vägledningen gäller även för orchestrator-API:et CallHttp , som bevarar sina nyttolaster för begäran och svar i lagringen. Om dina HTTP-målslutpunkter kräver autentisering implementerar du HTTP-anropet i en aktivitet eller använder det inbyggda stöd för hanterad identitet som erbjuds av CallHttp, som inte bevarar autentiseringsuppgifter för lagring.
Note
Undvik att logga data som innehåller hemligheter som alla med läsåtkomst till dina loggar (till exempel i Application Insights) kan hämta dessa hemligheter.
Kryptering i viloläge
När du använder Azure Storage-providern krypteras alla data automatiskt i vila. Alla som har åtkomst till lagringskontot kan dock läsa data i okrypterad form. Om du behöver ett starkare skydd för känsliga data bör du först kryptera data med dina egna krypteringsnycklar så att data sparas i förkrypterat format.
Alternativt har .NET-användare möjlighet att implementera anpassade serialiseringsproviders som tillhandahåller automatisk kryptering. Ett exempel på anpassad serialisering med kryptering finns i det här GitHub-exemplet.
Note
Om du bestämmer dig för att implementera kryptering på programnivå bör du vara medveten om att orkestreringar och entiteter kan finnas på obestämd tid. Det här är viktigt när det är dags att rotera krypteringsnycklarna eftersom en orkestrering eller en entitet kan köras längre än din nyckelroteringspolicy. Om en nyckelrotation sker kanske nyckeln som används för att kryptera dina data inte längre är tillgänglig för att dekryptera dem nästa gång orkestreringen eller entiteten körs. Anpassad kryptering rekommenderas därför endast när orkestreringar och entiteter förväntas köras under relativt korta tidsperioder.
Skydda aktivitetshubbens lagring
Lagringsserverdelen som är värd för aktivitetshubben är en kritisk förtroendegräns. Durable Task Framework litar på data som den läser från lagring under orkestreringsreppris och meddelandebearbetning. Alla som har skrivåtkomst till uppgiftshubbens lagring kan manipulera orkestreringstillstånd, väntande meddelanden eller lagrade nyttolaster. Detta kan ändra programmets beteende, utlösa oavsiktliga åtgärder eller uppnå fjärrkörning av kod i kontexten för din funktionsapp.
Important
Lämna inte ut autentiseringsuppgifterna för aktivitetshubbens lagring och ge inte skrivåtkomst till ej betrodda parter. Skrivåtkomst till aktivitetshubbens lagring kan användas för att ändra programmets beteende, inklusive att utlösa körning av godtycklig kod.
Delat ansvar
Att skydda lagringsserverdelen är ditt ansvar, på samma sätt som att skydda alla databaser som lagrar programtillstånd eller kod. Durable Task Framework utför inte integritetsverifiering på lagrade data, så det förlitar sig på lagringslagrets åtkomstkontroller för att förhindra obehöriga ändringar.
| Backend | Säkerhetsansvar | Guidance |
|---|---|---|
| Schemaläggare för varaktiga uppgifter | Microsoft hanterar den underliggande lagringsbackend. Du hanterar identiteter, åtkomst till uppgiftshubben och app-nivåsäkerhet. | Föredragen standard för nya Durable Functions-appar. |
| Azure Storage och andra BYO-leverantörer | Du hanterar lagringskontot eller databasen och dess säkerhetskontroller. | Bra passform för befintliga arbetsbelastningar eller installationer som redan är beroende av Azure Storage. |
Note
Dela inte en enda aktivitetshubb mellan ej betrodda klienter. En aktivitetshubb tillämpar inte åtkomstgränser mellan sina användare, så alla klienter som kan läsa eller skriva till aktivitetshubben kan påverka alla orkestreringar och entiteter i den. På samma sätt ska du inte betrakta separata aktivitetshubbar inom samma backend som en säkerhetsgräns. Durable Task Scheduler stöder RBAC-omfång för enskilda aktivitetshubbar, men nätverkskontroller som IP-tillåtna listor och privata slutpunkter gäller endast på schemaläggningsnivå, så aktivitetshubbar i en schemaläggare är inte en säkerhetsisoleringsgräns. Detsamma gäller för BYO-lagringsleverantörer – alla klientorganisationer med åtkomst till lagringskontot eller databasen kan nå alla aktivitetshubbar i den backend-miljön. När du behöver säkerhetsisolering mellan klientorganisationer etablerar du separat infrastruktur för varje klientorganisation: separata lagringskonton eller databaser för BYO-leverantörer eller separata durable task scheduler-instanser.
Checklista för lagringshärdning
Använd följande metodtips för att skydda din uppgiftshubbslagring:
Använd identitetsbaserade kopplingar för den backend du väljer.
- Med Durable Task Scheduler kan du använda hanterade identiteter och RBAC för schemaläggaren och uppgiftshubbarna.
- Med Azure Storage och andra BYO-leverantörer föredrar man hanterad identitet framför anslutningssträngar där det är möjligt.
Använd RBAC-roller med minsta behörighet. Bevilja endast de minsta behörigheter som krävs. Undvik att ge bred lagringsåtkomst till användare eller tjänster som inte behöver det.
Begränsa nätverksåtkomsten till ditt lagringskonto eller din schedulerdistribution med hjälp av privata slutpunkter eller tjänstslutpunkter. Denna begränsning hjälper till att förhindra obehörig nätverksåtkomst till uppgiftshubbens data.
Övervaka lagringsåtkomst genom att aktivera Azure Monitor resursloggar för ditt lagringskonto, särskilt loggkategorin
StorageWrite. Dirigera loggarna till ett mål utanför det övervakade lagringskontot, till exempel Log Analytics, så att de inte kan manipuleras. Se Loggar för lagring.Rotera autentiseringsuppgifter regelbundet om du använder anslutningssträngar. Behandla lagringskontonycklar med samma omsorg som andra autentiseringsuppgifter med hög behörighet.
Överväg en hanterad lagringsserverdel. Durable Task Scheduler hanterar lagringssäkerhet automatiskt, inklusive autentisering, RBAC och nätverksisolering, medan Azure Storage erbjuder explicit lagringskontroll.
Anpassa serialisering och deserialisering
Anpassningsalternativen för serialisering varierar beroende på språk. Välj språkfliken för att se tillgängliga alternativ.
.NET isolerad och System.Text.Json
Durable Functions som körs i den isolerade .NET-arbetsprocessen använder samma objektserialisering som har konfigurerats globalt för din Azure Functions-app (se WorkerOptions). Denna serializer är System.Text.Json som standard istället för Newtonsoft.Json. Alla ändringar i WorkerOptions.Serializer gäller transitivt även för Durable Functions.
Mer information om det inbyggda stödet för JSON-serialisering i .NET finns i JSON-serialisering och deserialisering i .NET översiktsdokumentation.