Dela via

Rekommendationer för hantering av tillfälliga fel

Den här guiden beskriver rekommendationer för hantering av tillfälliga fel i molnprogrammen. Alla program som kommunicerar med fjärrtjänster och fjärresurser måste vara känsliga för tillfälliga fel. Detta gäller särskilt för program som körs i molnet, där den här typen av störningar troligen kommer att uppstå oftare på grund av miljöns natur och anslutning via Internet. Tillfälliga fel inkluderar tillfälliga förlust av nätverksanslutning för komponenter och tjänster, tillfällig otillgänglighet för en tjänst samt timeouter som inträffar när en tjänst är upptagen. Felen är ofta själv korrigerande, så om åtgärden upprepas efter en lämplig fördröjning är det troligt att den lyckas.

Den här artikeln innehåller allmänna riktlinjer för tillfällig felhantering. Information om hur du implementerar återförsök i programkoden för att hantera tillfälliga fel finns i återförsöksmönstret och när du använder Azure-tjänster kan du läsa vägledningen om återförsök för Azure-tjänster.

Tillfälliga fel

Tillfälliga fel kan inträffa i alla miljöer, på alla plattformar eller operativsystem, och i alla typer av program. För lösningar som körs på lokal infrastruktur underhålls vanligtvis programmets prestanda och tillgänglighet och dess komponenter via dyr och ofta underanvänd maskinvaruredundans, och komponenter och resurser finns nära varandra. Den här metoden gör fel mindre sannolika, men tillfälliga fel kan fortfarande inträffa, liksom avbrott som orsakas av oförutsedda händelser som extern strömförsörjning eller nätverksproblem eller haveriscenarier.

Molnvärdtjänster, inklusive privata molnsystem, kan erbjuda högre övergripande tillgänglighet med hjälp av delade resurser, redundans, automatisk failover och dynamisk resursallokering över många standard beräkningsnoder. På grund av molnmiljöernas natur är det dock mer sannolikt att tillfälliga fel inträffar. Det finns flera orsaker till detta:

  • Många resurser i en molnmiljö delas och åtkomsten till dessa resurser begränsas för att skydda resurserna. Vissa tjänster nekar anslutningar när belastningen stiger till en viss nivå, eller när en maximal dataflödeshastighet nås, för att tillåta bearbetning av befintliga begäranden och för att upprätthålla tjänstens prestanda för alla användare. Begränsning hjälper till att upprätthålla tjänstens kvalitet för grannar och andra klienter som använder den delade resursen.

  • Molnmiljöer använder ett stort antal standardmaskinvaruenheter. De ger prestanda genom att dynamiskt distribuera belastning över flera beräkningsenheter och infrastrukturkomponenter. De ger tillförlitlighet genom att automatiskt återanvända eller ersätta misslyckade enheter. På grund av den här dynamiska karaktären kan tillfälliga fel och tillfälliga anslutningsfel ibland inträffa.

  • Det finns ofta fler maskinvarukomponenter, inklusive nätverksinfrastruktur som routrar och lastbalanserare, mellan programmet och de resurser och tjänster som används. Den här ytterligare infrastrukturen kan ibland medföra ytterligare anslutningsfördröjningar och tillfälliga anslutningsfel.

  • Nätverksvillkoren mellan klienten och servern kan vara varierande, särskilt när kommunikationen passerar internet. Även på lokala platser kan tung trafikbelastning sakta ned kommunikationen och orsaka tillfälliga anslutningsfel.

Tillfälliga fel kan ha en stor effekt på programmets uppfattade tillgänglighet, även om det har testats noggrant under alla tänkbara omständigheter. För att säkerställa att molnbaserade program fungerar tillförlitligt måste du se till att de kan svara på följande utmaningar:

  • Programmet måste kunna identifiera fel när de inträffar och avgöra om felen är tillfälliga eller om de är långvariga eller oåterkalleliga fel. Det är troligt att olika resurser returnerar olika svar när ett fel inträffar och svaren kan också variera beroende på sammanhanget i åtgärden. Till exempel kan svaret på ett fel när programmet läser från lagring skilja sig från svaret på ett fel när det skrivs till lagring. Många resurser och tjänster har väldokumenterade avtal om tillfälliga fel. Men när sådan information inte är tillgänglig kan det vara svårt att identifiera felets art och om det är troligt att det är tillfälligt.

  • Programmet måste kunna göra ett nytt försök om det bedömer att felet förmodligen är tillfälligt. Den måste också hålla reda på hur många gånger åtgärden görs på nytt.

  • Programmet måste använda en lämplig strategi för återförsök. I strategin anges hur många gånger programmet ska försöka igen, fördröjningen mellan varje försök och åtgärderna som ska vidtas efter ett misslyckat försök. Det är ofta svårt att avgöra hur många försök som ska göras och hur fördröjningen mellan försöken är ofta svår att fastställa. Strategin varierar beroende på resurstyp och på resursens och programmets aktuella driftförhållanden.

Med hjälp av följande riktlinjer kan du utforma lämpliga hanteringsmekanismer för tillfälliga fel för dina program.

Implementera omförsök

Bestäm om det finns en inbyggd återförsöksmekanism

  • Många tjänster tillhandahåller ett SDK eller klientbibliotek som innehåller en tillfällig mekanism för felhantering. Den återförsöksprincip som den använder är oftast skräddarsydd efter måltjänstens typ och krav. REST-gränssnitten för tjänster kan också returnera information som kan hjälpa dig att avgöra om ett nytt försök är lämpligt och hur länge du ska vänta innan nästa försök görs igen.

  • Du bör använda den inbyggda återförsöksmekanismen när en är tillgänglig om du inte har specifika och välförstådda krav som gör ett annat återförsöksbeteende mer lämpligt.

Bestäm om åtgärden är lämplig för återförsök

  • Utför återförsök endast om felen är tillfälliga (visas vanligtvis med felets typ) och det finns åtminstone en sannolikhet för att åtgärden ska lyckas vid ett nytt försök. Det är ingen idé att försöka utföra åtgärder igen som försöker utföra en ogiltig åtgärd, till exempel en databasuppdatering av ett objekt som inte finns eller en begäran till en tjänst eller resurs som har drabbats av ett allvarligt fel.

  • I allmänhet implementerar du bara återförsök när du kan fastställa den fulla effekten av att göra det och när villkoren är väl förstådda och kan valideras. Annars bör den anropande koden implementera återförsök. Tänk på att felen som returneras från resurser och tjänster som du inte har kontroll över kan utvecklas med tiden. Du kanske måste åtgärda identifieringslogiken för tillfälliga fel.

  • När du skapar tjänster eller komponenter bör du överväga att implementera felkoder och meddelanden som hjälper klienter att avgöra om de ska försöka utföra misslyckade åtgärder igen. Ange i synnerhet om klienten ska försöka utföra åtgärden igen (kanske genom att returnera ett isTransient-värde ) och föreslå en lämplig fördröjning före nästa återförsök. Om du skapar en webbtjänst kan du överväga att returnera anpassade fel som definieras i servicekontrakten. Även om generiska klienter kanske inte kan läsa dessa fel är de användbara när anpassade klienter skapas.

Fastställ ett lämpligt antal och intervall för återförsök

  • Optimera antalet återförsök och intervallet för typen av användningsfall. Om du inte återförsöker tillräckligt många gånger kan inte programmet slutföra åtgärden och den kommer troligen att misslyckas. Om du försöker igen för många gånger, eller med för kort intervall mellan försök, kan programmet innehålla resurser som trådar, anslutningar och minne under långa perioder, vilket påverkar programmets hälsa negativt.

  • Anpassa värden för tidsintervallet och antalet försök till typen av åtgärd. Om åtgärden till exempel är en del av en användarinteraktion ska intervallet vara kort och endast ett fåtal försök ska göras. Med den här metoden kan du undvika att få användarna att vänta på ett svar som innehåller öppna anslutningar och kan minska tillgängligheten för andra användare. Om åtgärden ingår i ett långvarigt eller kritiskt arbetsflöde, där det är dyrt eller tidskrävande att avbryta och starta om processen, är det lämpligt att vänta längre mellan försöken och försöka igen fler gånger.

  • Tänk på att det är mycket svårt att fastställa lämpliga intervaller mellan återförsöken när en framgångsrik strategi utformas. Vanliga strategier använder följande typer av intervall för återförsök:

    • Exponentiell tillbakagång. Programmet väntar en kort tid innan det första återförsöket och ökar sedan tiden exponentiellt mellan varje efterföljande återförsök. Det kan till exempel försöka utföra åtgärden igen efter 3 sekunder, 12 sekunder, 30 sekunder och så vidare. För att ytterligare förbättra den här strategin kan du lägga till jitter i den exponentiella backoffen. Jitter introducerar en slumpmässig fördröjning för varje återförsök, vilket hjälper till att förhindra att flera klienter försöker igen samtidigt och orsakar en topp i belastningen

    • Inkrementella intervaller. Programmet väntar en kort tid innan det första återförsöket och ökar sedan inkrementellt tiden mellan varje efterföljande återförsök. Den kan till exempel försöka utföra åtgärden igen efter 3 sekunder, 7 sekunder, 13 sekunder och så vidare.

    • Regelbundna intervall. Programmet väntar under samma tidsperiod mellan varje försök. Den kan till exempel försöka utföra åtgärden igen var 3:e sekund.

    • Omedelbart nytt försök. Ibland är ett tillfälligt fel kort och kan orsakas av en händelse som en kollision av nätverkspaket eller en topp i en hårdvarukomponent. I det här fallet är det lämpligt att försöka utföra åtgärden igen omedelbart eftersom det kan lyckas om felet åtgärdas under den tid det tar för applikationen att förbereda och skicka nästa begäran. Du ska dock aldrig göra fler än ett omedelbart försök till återförsök. Du bör växla till alternativa strategier, till exempel exponentiell säkerhetskopiering eller återställningsåtgärder, om det omedelbara återförsöket misslyckas.

    • Slumpmässighet. Någon av de återförsöksstrategier som anges tidigare kan innehålla en slumpmässighet för att förhindra att flera instanser av klienten skickar efterföljande återförsök samtidigt. En instans kan till exempel försöka utföra åtgärden igen efter 3 sekunder, 11 sekunder, 28 sekunder och så vidare, medan en annan instans kan försöka utföra åtgärden igen efter 4 sekunder, 12 sekunder, 26 sekunder och så vidare. Randomisering är en användbar teknik som kan kombineras med andra strategier.

  • Som en allmän riktlinje använder du en exponentiell backoff med jitterstrategi för bakgrundsåtgärder och använder omedelbara eller regelbundna intervall för återförsök i interaktiva åtgärder. I båda fallen bör du välja fördröjningen och antalet återförsök så att den högsta tillåtna latensen för alla försök igen ligger inom det obligatoriska kravet på komplett latens.

  • Ta hänsyn till kombinationen av alla faktorer som bidrar till den totala maximala tidsgränsen för en ny åtgärd. Dessa faktorer inkluderar den tid det tar för en misslyckad anslutning att generera ett svar (vanligtvis inställt med ett timeout-värde i klienten), fördröjningen mellan återförsök och det maximala antalet återförsök. Totalsumman av alla dessa tider kan resultera i långa generella användningstider, särskilt när du använder en strategi med exponentiell fördröjning där intervallet mellan återförsöken växer snabbt efter varje fel. Om en process måste uppfylla ett visst serviceavtal (SLA, Service Level Agreement) måste den övergripande åtgärdstiden, inklusive alla tidsgränser och förseningar, vara inom de gränser som definieras i SLA-avtalet.

  • Implementera inte för många, extremt aggressiva återförsöksstrategier. Det här är strategier som har för korta intervaller eller för ofta förekommande återförsök. De kan ha en negativ effekt på målresursen eller måltjänsten. Dessa metoder kan göra att resursen eller tjänsten inte kan återställas från överbelastat tillstånd, och fortsätter att blockera eller avvisa förfrågningar. Det här scenariot resulterar i en ond cirkel där fler och fler förfrågningar skickas till resursen eller tjänsten. Därför minskas möjligheten att återställa ytterligare.

  • Ta hänsyn till tidsgränsen för åtgärderna när du väljer återförsöksintervall för att undvika att starta ett efterföljande försök omedelbart (till exempel om tidsgränsen liknar återförsöksintervallet). Fundera också på om du behöver behålla den totala möjliga perioden (tidsgränsen plus återförsöksintervallen) under en viss total tid. Om en åtgärd har en ovanligt kort eller lång tidsgräns kan tidsgränsen påverka hur lång tid det tar att vänta och hur ofta åtgärden ska utföras igen.

  • Använd typen av undantag och alla data som det innehåller, eller felkoderna och meddelandena som returneras från tjänsten, för att optimera antalet återförsök och intervallet mellan dem. Vissa undantag eller felkoder (t.ex. HTTP-kod 503, Tjänsten är inte tillgänglig, med rubriken Försök-efter i svaret) kan exempelvis indikera hur länge felet kan vara pågå, eller på att tjänsten misslyckades och kommer inte att svara på efterföljande försök.

  • Överväg att använda en dead-letter-kö för att se till att all information från det inkommande anropet inte går förlorad när alla försök har uttömts.

Undvik antimönster

  • I de flesta fall bör du undvika implementeringar som innehåller dubblerade skikt av kod för återförsök. Undvik design som omfattar sammanhängande mekanismer för återförsök eller som implementerar återförsök i varje steg i en åtgärd som omfattar en hierarki med begäranden, såvida du inte har specifika krav som kräver att du gör det. I dessa exceptionella förhållanden, använd principer som förhindrar alltför många perioder av återförsök och förseningar, och försäkra dig om att du förstår konsekvenserna. Låt säga att en komponent gör en begäran till en annan, som sedan får åtkomst till måltjänsten. Om du implementerar tre återförsök för båda anropen görs totalt nio återförsök mot tjänsten. Många tjänster och resurser implementerar en inbyggd återförsöksmekanism. Du bör undersöka hur du kan inaktivera eller ändra de här mekanismerna om du behöver implementera återförsök på en högre nivå.

  • Implementera aldrig någon oändlig återförsöksmekanism. Om du gör det kan den förhindra att resursen eller tjänsten återställs från överbelastade situationer, och det kan leda till att begränsningar och nekade anslutningar fortsätter under en längre tid. Använd ett begränsat antal återförsök eller implementera ett mönster som Kretsbrytare så att tjänsten kan återställas.

  • Försök aldrig utföra ett omedelbart återförsök mer än en gång.

  • Undvik att använda ett regelbundet återförsöksintervall när du får åtkomst till tjänster och resurser i Azure, särskilt när du har ett stort antal återförsök. Den bästa metoden i det här scenariot är en exponentiell back-off-strategi med en kretsbrytande funktion.

  • Förhindra att flera instanser av samma klient, eller flera instanser av olika klienter, skickar återförsök samtidigt. Om det här scenariot sannolikt inträffar introducerar du randomisering i återförsöksintervallen.

Testa återförsöksstrategier och implementering

  • Testa återförsöksstrategin under så många omständigheter som möjligt, särskilt när både programmet och målresurserna eller måltjänsterna som används är under extrem belastning. Om du vill kontrollera beteendet under testningen kan du:

    • Inkludera tillfälliga fel i din kaosteknik och metoder för felinmatning genom att avsiktligt introducera dem i dina icke-produktions- och produktionsmiljöer. Du kan till exempel skicka ogiltiga förfrågningar eller lägga till kod som identifierar testförfrågningar och svarar på olika typer av fel.

    • Skapa en fiktiv resurs eller tjänst som returnerar en rad fel som den verkliga tjänsten kan komma att returnera. Täck alla typer av fel som återförsöksstrategin är utformad för att identifiera.

    • För anpassade tjänster som du skapar och distribuerar måste du tvinga fram tillfälliga fel genom att tillfälligt inaktivera eller överbelasta tjänsten. (Försök inte överbelasta några delade resurser eller delade tjänster i Azure.)

    • Använd bibliotek eller lösningar som fångar upp och ändrar nätverkstrafik för att replikera ogynnsamma scenarier från dina automatiserade tester. Testerna kan till exempel lägga till extra tur och retur-tider, släppa paket, ändra rubriker eller till och med ändra själva begärandetexten. Detta möjliggör deterministisk testning av en delmängd av felvillkoren, för tillfälliga fel och andra typer av fel.

    • Om du testar ett klientwebbprograms återhämtning vid tillfälliga fel, använd webbläsarens utvecklarverktyg eller testramverkets möjlighet att efterlikna eller blockera nätverksbegäranden.

    • Utför hög belastningsfaktor och samtidiga tester för att säkerställa att återförsöksmekanismen och strategin fungerar korrekt under dessa förhållanden. Med hjälp av dessa tester kan du även se till att återförsöket inte påverkar klientens funktion negativt eller leder till kontaminering mellan förfrågningarna.

Hantera konfigurationer av återförsöksprinciper

  • En återförsöksprincip är en kombination av alla element i återförsöksstrategin. Den definierar identifieringsmekanismen som avgör om ett fel sannolikt kommer att vara tillfälligt, vilken typ av intervall som ska användas (till exempel vanlig, exponentiell back-off och slumpmässighet), faktiska intervallvärden och antalet gånger som återförsök ska göras.

  • Implementera återförsök på många platser, även i det enklaste programmet, och i varje lager av mer komplexa program. I stället för att hårdkoda elementen i varje princip på flera platser bör du överväga att använda en central punkt för att lagra alla principer. Du kan till exempel lagra värden som intervall och återförsök i programkonfigurationsfiler, läsa dem vid körning och programmatiskt skapa återförsöksprinciperna. Det gör det enklare att hantera inställningarna och ändra och finjustera värdena för att svara på ändrade krav och scenarier. Utforma dock systemet för att lagra värdena i stället för att läsa om en konfigurationsfil varje gång och använd lämpliga standardvärden om värdena inte kan hämtas från konfigurationen.

  • Lagra de värden som används för att skapa återförsöksprinciperna vid körning i programmets konfigurationssystem så att du kan ändra dem utan att behöva starta om programmet.

  • Dra nytta av inbyggda eller standardmässiga återförsöksstrategier som är tillgängliga i de klient-API:er som du använder, men bara när de är lämpliga för ditt scenario. De här strategierna är vanligtvis generiska. I vissa scenarier kanske de är allt du behöver, men i andra scenarier erbjuder de inte alla alternativ för dina specifika behov. Du måste utföra tester för att ta reda på hur inställningarna påverkar ditt program för att avgöra vilka värden som är mest lämpliga.

Logga och spåra tillfälliga och icke-övergående fel

  • Som en del av återförsöksstrategin inkluderar du undantagshantering och annan instrumentation som loggar återförsök. Ett enstaka tillfälligt fel och återförsök förväntas och tyder inte på några problem. Ett regelbundet och ökande antal återförsök visar dock ofta på problem som kan orsaka fel eller försämra programmets prestanda och tillgänglighet.

  • Logga tillfälliga fel som varningsposter i stället för som felposter så att övervakningssystem inte identifierar dem som programfel som kan utlösa felaktiga aviseringar.

  • Överväg att lagra ett värde i loggposterna som anger om återförsöken orsakas av begränsning i tjänsten eller av andra typer av fel, t.ex. anslutningsfel, så att du kan skilja dem åt vid analys av data. En ökning av antalet begränsningsfel är ofta en indikator på ett designfel i programmet eller behovet av att byta till en premiumtjänst som erbjuder dedikerad maskinvara.

  • Överväg att mäta och logga de övergripande förflutna tiderna för åtgärder som innehåller en återförsöksmekanism. Det här måttet är en bra indikator på den övergripande effekten av tillfälliga fel på användarens svarstider, processfördröjning och effektiviteten i programanvändningsfall. Logga också antalet återförsök som inträffar så att du kan förstå de faktorer som bidrar till svarstiden.

  • Överväg att implementera ett telemetri- och övervakningssystem som kan ge varningar vid ökning av antalet och frekvensen av fel, det genomsnittliga antalet återförsök eller den övergripande tid innan åtgärderna lyckas.

Hantera åtgärder som ständigt misslyckas

  • Fundera på hur du ska hantera åtgärder som misslyckas vid varje försök. Situationer som den här är ofrånkomliga.

    • Även om en återförsöksstrategi definierar det maximala antalet gånger som en åtgärd ska utföras igen, hindrar den inte programmet från att upprepa åtgärden igen med samma antal återförsök. Om en orderbearbetningstjänst till exempel misslyckas med ett allvarligt fel som gör att den inte fungerar permanent kan återförsöksstrategin identifiera en tidsgräns för anslutningen och betrakta den som ett tillfälligt fel. Koden försöker utföra åtgärden igen ett angivet antal gånger och ger sedan upp. Men när en annan kund lägger en beställning görs åtgärden igen, även om den misslyckas varje gång.

    • För att förhindra kontinuerliga återförsök för åtgärder som kontinuerligt misslyckas bör du överväga att implementera kretsbrytarmönstret. När du använder det här mönstret, om antalet fel inom ett angivet tidsfönster överskrider ett tröskelvärde, återgår begäranden till anroparen omedelbart som fel och det görs inga försök att komma åt den misslyckade resursen eller tjänsten.

    • Tjänsten kan regelbundet testas av programmet, och på tillfällig bas och med långa intervaller mellan förfrågningar, för att identifiera när den blir tillgänglig. Ett lämpligt intervall beror på faktorer som hur kritisk åtgärden är och typen av tjänst. Det kan ta mellan några minuter och flera timmar. När testet har lyckats kan programmet återuppta normala åtgärder och skicka förfrågningar till den nyligen återställda tjänsten.

    • Under tiden kanske du kan återgå till en annan instans av tjänsten (kanske i ett annat datacenter eller program), använda en liknande tjänst som erbjuder kompatibla (kanske enklare) funktioner eller utföra några alternativa åtgärder baserat på förhoppningen att tjänsten snart kommer att vara tillgänglig. Det kan exempelvis vara lämpligt att lagra förfrågningar om tjänsten i en kö eller ett datalager och försöka genomföra dem igen senare. Eller så kanske du kan omdirigera användaren till en alternativ instans av programmet, försämra programmets prestanda men ändå erbjuda godtagbara funktioner eller bara returnera ett meddelande till användaren för att ange att programmet inte är tillgängligt för närvarande.

Optimera återförsöksimplementering

  • När du bestämmer värden för antalet återförsök och intervaller för återförsök för en princip bör du tänka på om åtgärden för tjänsten eller resursen är en del av en lång körning eller en åtgärd med flera steg. Det kan vara svårt eller dyrt att kompensera alla andra operativa steg som redan har slutförts när en misslyckas. I det här fallet kan ett mycket långt intervall och ett stort antal återförsök vara godtagbara så länge strategin inte blockerar andra åtgärder genom att hålla eller låsa knappa resurser.

  • Fundera på om ett nytt försök med samma åtgärd kan orsaka inkonsekvenser i data. Om vissa delar i en flerstegsprocess upprepas och åtgärderna inte är idempotenta kan inkonsekvenser uppstå. Om till exempel en åtgärd som ökar ett värde upprepas ger den ett ogiltigt resultat. Att upprepa en åtgärd som skickar ett meddelande till en kö kan orsaka inkonsekvens i meddelandekonsumenten om konsumenten inte kan identifiera duplicerade meddelanden. Du kan förhindra dessa scenarier genom att utforma varje steg som en idempotent åtgärd. Mer information finns i Idempotensmönster.

  • Fundera över vilka åtgärder som ska återförsökas. Det kan till exempel vara enklare att implementera återförsökskod på en nivå som omfattar flera åtgärder och försöka utföra alla igen om en misslyckas. Det kan emellertid leda till problem med idempotens eller onödiga återställningsåtgärder.

  • Om du väljer ett omfång för återförsök som omfattar flera åtgärder ska du ta hänsyn till den totala svarstiden för alla när du fastställer återförsöksintervall, när du övervakar de förflutna tiderna för åtgärden och innan du skapar aviseringar om fel.

  • Fundera på hur din strategi för återförsök kan påverka grannar och andra klienter i ett delat program och när du använder delade resurser och tjänster. Aggressiva återförsöksprinciper kan orsaka ett ökande antal tillfälliga fel för dessa andra användare och för program som delar resurser och tjänster. På samma sätt kan ditt program påverkas av de återförsöksprinciper som implementeras av andra användare av resurserna och tjänsterna. För affärskritiska program kanske du vill använda premiumtjänster som inte delas. På så sätt får du mer kontroll över belastningen och den efterföljande begränsningen av dessa resurser och tjänster, vilket kan bidra till att motivera den extra kostnaden.

Anmärkning

Se Problem och överväganden i artikeln Återförsöksmönster för ytterligare vägledning om avvägningar och risker.

Azure-stöd

De flesta Azure-tjänster och klient-SDK:er tillhandahåller en mekanism för återförsök. Dessa mekanismer skiljer sig dock åt eftersom varje tjänst har olika egenskaper och krav, och varje återförsöksmekanism justeras till den specifika tjänsten. I det här avsnittet sammanfattas funktionerna för återförsöksmekanismer för vissa vanliga Azure-tjänster.

Tjänster Återförsöksfunktioner Konfiguration av princip Omfång Telemetrifunktioner
Microsoft Entra-ID Inbyggt i Microsoft Authentication Library (MSAL) Inbäddad i MSAL-biblioteket Inre None
Azure Cosmos DB Nativt i tjänsten Kan inte konfigureras Global TraceSource
Azure Data Lake Storage Inbyggt i klienten Kan inte konfigureras Enskilda åtgärder None
Azure Event Hubs Inbyggt i klienten Programmatic Klient None
Azure IoT Hub Inbyggt i klient-SDK Programmatic Klient None
Azure Cognitive Search Inbyggt i klienten Programmatic Klient ETW eller anpassad
Azure Service Bus Inbyggt i klienten Programmatic NamespaceManager, MessagingFactory och klient ETW
Azure Service Fabric Inbyggt i klienten Programmatic Klient None
Azure SQL Database med ADO.NET Polly Deklarativ och programmatisk Enkla instruktioner eller kodblock Skräddarsydd
SQL Database med Entity Framework Inbyggt i klienten Programmatic Global per AppDomain None
SQL Database med Entity Framework Core Inbyggt i klienten Programmatic Global per AppDomain None
Azure Storage Inbyggt i klienten Programmatic Kundoperationer och individuella operationer TraceSource

Anmärkning

För de flesta inbyggda Mekanismer för återförsök i Azure finns det för närvarande inget sätt att tillämpa en annan återförsöksprincip för olika typer av fel eller undantag. Du bör konfigurera en princip som ger optimal genomsnittlig prestanda och tillgänglighet. Ett sätt att finjustera principen är att analysera loggfiler för att fastställa vilken typ av tillfälliga fel som inträffar.

Example

Se Reliable web app pattern for .NET (Tillförlitligt webbappsmönster för .NET ) för ett exempel som använder många av de mönster som beskrivs i den här artikeln. Det finns också en referensimplementering på GitHub.

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Checklista för tillförlitlighet

  • Last updated on