Dela via

Metodtips och diagnostikverktyg för Durable Functions

  • Artikel

Den här artikeln beskriver några metodtips när du använder Durable Functions. Den beskriver också olika verktyg som hjälper dig att diagnostisera problem under utveckling, testning och produktionsanvändning.

Bästa praxis

Använd den senaste versionen av Durable Functions-tillägget och SDK:et

Det finns två komponenter som en funktionsapp använder för att köra Durable Functions. Den ena är Durable Functions SDK som gör att du kan skriva orkestrerings-, aktivitets- och entitetsfunktioner med hjälp av ditt målprogrammeringsspråk. Det andra är Durable-tillägget, som är körningskomponenten som faktiskt kör koden. Med undantag för .NET-in-process-appar är SDK:et och tillägget versionshanterade oberoende av varandra.

Om du håller dig uppdaterad med det senaste tillägget och SDK:et säkerställer du dina programfördelar med de senaste prestandaförbättringarna, funktionerna och felkorrigeringarna. Uppgradering till de senaste versionerna säkerställer också att Microsoft kan samla in den senaste diagnostiktelemetrin för att påskynda undersökningsprocessen när du öppnar ett supportärende med Azure.

Följ begränsningarna för Durable Functions-kod

Omspelningsbeteendet för orchestrator-kod skapar begränsningar för den typ av kod som du kan skriva i en orchestrator-funktion. Ett exempel på en begränsning är att orkestreringsfunktionen måste använda deterministiska API:er så att den ger samma resultat varje gång den spelas upp igen.

Kommentar

Durable Functions Roslyn Analyzer är en live-kodanalys som hjälper C#-användare att följa durable functions-specifika kodbegränsningar. Se Durable Functions Roslyn Analyzer för instruktioner om hur du aktiverar det i Visual Studio och Visual Studio Code.

Bekanta dig med programmeringsspråkets Prestandainställningar för Azure Functions

Med standardinställningarna kan den språkkörning du väljer införa strikta samtidighetsbegränsningar för dina funktioner. Till exempel: endast tillåta att en funktion körs åt gången på en viss virtuell dator. Dessa begränsningar kan vanligtvis lättas upp genom att finjustera språkens samtidighets- och prestandainställningar. Om du vill optimera prestandan för ditt Durable Functions-program måste du bekanta dig med de här inställningarna.

Nedan visas en icke-fullständig lista över några av de språk som ofta drar nytta av att finjustera sina prestanda- och samtidighetsinställningar och deras riktlinjer för att göra det.

Garantera unika aktivitetshubbens namn per app

Flera Durable Function-appar kan dela samma lagringskonto. Som standard används namnet på appen som uppgiftshubbens namn, vilket säkerställer att oavsiktlig delning av aktivitetshubbar inte sker. Om du uttryckligen behöver konfigurera aktivitetshubbens namn för dina appar i host.json måste du se till att namnen är unika. Annars konkurrerar flera appar om meddelanden, vilket kan leda till odefinierat beteende, inklusive orkestreringar som oväntat "fastnar" i tillståndet Väntar eller Körs.

Det enda undantaget är om du distribuerar kopior av samma app i flera regioner. I det här fallet kan du använda samma aktivitetshubb för kopiorna.

Följ vägledningen när du distribuerar kodändringar till orkestratorer som körs

Det är oundvikligt att funktioner läggs till, tas bort och ändras under programmets livslängd. Exempel på vanliga icke-bakåtkompatibla ändringar är att ändra aktivitets- eller entitetsfunktionssignaturer och ändra orchestratorlogik. Dessa ändringar är ett problem när de påverkar orkestreringar som fortfarande körs. Om de distribueras felaktigt kan kodändringar leda till orkestreringar som misslyckas med ett icke-deterministiskt fel, fastnar på obestämd tid, prestandaförsämring osv. Se rekommenderade åtgärdsstrategier när du gör kodändringar som kan påverka körningen av orkestreringar.

Håll funktionens indata och utdata så små som möjligt

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 till Durable Functions-API:er serialiseras i orkestreringshistoriken. Det innebär att stora indata och utdata med tiden i hög grad kan bidra till att en orkestreringshistorik växer obundet, vilket riskerar att orsaka minnesundatag under reprisen.

För att minska effekten av stora indata och utdata till API:er kan du välja att delegera en del arbete till underorkestrerare. Detta hjälper till att belastningsbalansera historikminnet från en enda orkestrerare till flera, vilket gör att minnets fotavtryck för enskilda historier blir litet.

Med detta sagt är bästa praxis för att hantera stora data att behålla dem i extern lagring och att endast materialisera dessa data i Aktiviteter, när det behövs. När du använder den här metoden, i stället för att kommunicera själva data som indata och/eller utdata från Durable Functions-API:er, kan du skicka in en lätt identifierare som gör att du kan hämta dessa data från extern lagring när det behövs i dina aktiviteter.

Håll entitetsdata små

Precis som för indata och utdata till Durable Functions-API:er kan du stöta på minnesproblem om en entitets explicita tillstånd är för stort. I synnerhet måste ett entitetstillstånd serialiseras och av-serialiseras från lagring på alla begäranden, så stora tillstånd lägger till serialiseringssvarstid för varje anrop. Om en entitet behöver spåra stora data rekommenderar vi därför att du avlastar data till extern lagring och spårar en viss enkel identifierare i entiteten som gör att du kan materialisera data från lagringen när det behövs.

Finjustera inställningarna för Durable Functions-samtidighet

En enskild arbetsinstans kan köra flera arbetsobjekt samtidigt för att öka effektiviteten. Bearbetning av för många arbetsobjekt riskerar dock samtidigt att överbelasta resurser som CPU-kapacitet, nätverksanslutningar osv. I många fall bör detta inte vara ett problem eftersom skalning och begränsning av arbetsobjekt hanteras automatiskt åt dig. Om du har prestandaproblem (till exempel att orkestreringsledare tar för lång tid att slutföra, har fastnat i väntande osv.) eller utför prestandatestning kan du konfigurera samtidighetsgränser i host.json-filen.

Kommentar

Detta är inte en ersättning för att finjustera prestanda- och samtidighetsinställningarna för din språkkörning i Azure Functions. Inställningarna för durable functions-samtidighet avgör bara hur mycket arbete som kan tilldelas till en viss virtuell dator i taget, men det avgör inte graden av parallellitet vid bearbetning som fungerar i den virtuella datorn. Det senare kräver finjustering av prestandainställningarna för språkkörning.

Använda unika namn för dina externa händelser

Precis som med aktivitetsfunktioner har externa händelser en leveransgaranti minst en gång . Det innebär att programmet under vissa sällsynta förhållanden (som kan inträffa under omstarter, skalning, krascher osv.) kan ta emot dubbletter av samma externa händelse. Därför rekommenderar vi att externa händelser innehåller ett ID som gör att de kan avdupliceras manuellt i orchestrators.

Kommentar

MSSQL-lagringsprovidern använder externa händelser och uppdaterar orkestreringstillståndet transaktionsmässigt, så i den serverdelen bör det inte finnas någon risk för duplicerade händelser, till skillnad från standardlagringsprovidern för Azure Storage. Som sagt, det rekommenderas fortfarande att externa händelser har unika namn så att koden är portabel över serverdelar.

Investera i stresstestning

Precis som med alla prestandarelaterade beror de idealiska samtidighetsinställningarna och arkitekniken för din app i slutändan på programmets arbetsbelastning. Därför rekommenderar vi att användarna investerar i ett prestandatest som simulerar deras förväntade arbetsbelastning och använder den för att köra prestanda- och tillförlitlighetsexperiment för appen.

Undvik känsliga data i indata, utdata och undantag

Indata och utdata (inklusive undantag) till och från Durable Functions-API:er sparas i valfri lagringsprovider. Om dessa indata, utdata eller undantag innehåller känsliga data (till exempel hemligheter, anslutningssträng, personligt identifierbar information osv.) skulle alla med läsåtkomst till lagringsleverantörens resurser kunna hämta dem. För att hantera känsliga data på ett säkert sätt rekommenderar vi att användarna hämtar dessa data i aktivitetsfunktioner från antingen Azure Key Vault eller miljövariabler, och att aldrig kommunicera dessa data direkt till orkestratorer eller entiteter. Det bör bidra till att förhindra att känsliga data läcker ut i dina lagringsresurser.

Kommentar

Den här vägledningen gäller även för orchestrator-API:et CallHttp , som även bevarar nyttolasten för begäran och svar i lagringen. Om dina HTTP-målslutpunkter kräver autentisering, vilket kan vara känsligt, rekommenderar vi att användarna implementerar SJÄLVA HTTP-anropet i en aktivitet eller att använda det inbyggda stöd för hanterad identitet som erbjuds av CallHttp, som inte bevarar några autentiseringsuppgifter för lagring.

Dricks

På samma sätt kan du undvika att logga data som innehåller hemligheter som alla med läsåtkomst till dina loggar (till exempel i Application Insights) för att få dessa hemligheter.

Diagnostikverktyg

Det finns flera verktyg som hjälper dig att diagnostisera problem.

Durable Functions- och Durable Task Framework-loggar

Durable Functions-tillägg

Durable-tillägget genererar spårningshändelser som gör att du kan spåra körningen från slutpunkt till slutpunkt för en orkestrering. Dessa spårningshändelser kan hittas och frågas med hjälp av verktyget Application Insights Analytics i Azure Portal. Utförligheten för att spåra data som genereras kan konfigureras i avsnittet (Functions 1.x) eller logging (Functions 2.0) i logger host.json-filen. Se konfigurationsinformation.

Durable Task Framework

Från och med v2.3.0 i Durable-tillägget är loggar som genereras av det underliggande Durable Task Framework (DTFx) också tillgängliga för insamling. Se information om hur du aktiverar dessa loggar.

Azure Portal

Diagnostisera och lösa problem

Azure Function App Diagnostics är en användbar resurs på Azure Portal för övervakning och diagnostisering av potentiella problem i ditt program. Den innehåller också förslag som hjälper dig att lösa problem baserat på diagnosen. Mer information finns i Diagnostik för Azure-funktionsapp.

Durable Functions Orchestration-spårningar

Azure Portal innehåller orkestreringsspårningsinformation som hjälper dig att förstå statusen för varje orkestreringsinstans och spåra körningen från slutpunkt till slutpunkt. När du tittar på listan över funktioner i din Azure Functions-app visas en monitorkolumn som innehåller länkar till spårningarna. Du måste ha Application Insights aktiverat för din app för att få den här informationen.

Durable Functions Monitor-tillägg

Det här är ett Visual Studio Code-tillägg som tillhandahåller ett användargränssnitt för övervakning, hantering och felsökning av orkestreringsinstanser.

Roslyn Analyzer

Durable Functions Roslyn Analyzer är en live-kodanalys som hjälper C#-användare att följa durable functions-specifika kodbegränsningar. Se Durable Functions Roslyn Analyzer för instruktioner om hur du aktiverar det i Visual Studio och Visual Studio Code.

Support

För frågor och support kan du öppna ett problem i någon av GitHub-lagringsplatserna nedan. När du rapporterar ett fel i Azure, inklusive information som berörda instans-ID:er, tidsintervall i UTC som visar problemet, kommer programnamnet (om möjligt) och distributionsregionen att påskynda utredningarna avsevärt.