Rekommendationer för hantering av tillfälliga fel

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Reliability:

RE:07 Förbättra återhämtning och återställning av din arbetsbelastning genom att implementera självbevarelsedrift och självåterställningsåtgärder. Skapa funktioner i lösningen med hjälp av infrastrukturbaserade tillförlitlighetsmönster och programvarubaserade designmönster för att hantera komponentfel och tillfälliga fel. Skapa funktioner i systemet för att identifiera lösningskomponentfel och initiera automatiskt korrigerande åtgärder medan arbetsbelastningen fortsätter att fungera med fullständig eller nedsatt funktionalitet.

Relaterade guider:Självbevarandeav bakgrundsjobb |

Den här guiden beskriver rekommendationerna för hantering av tillfälliga fel i dina molnprogram. Alla program som kommunicerar med fjärrtjänster och -resurser 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 fel troligen påträffas oftare på grund av miljöns natur och anslutningen via Internet. Tillfälliga fel omfattar tillfällig förlust av nätverksanslutning till komponenter och tjänster, tillfällig otillgänglighet för en tjänst och tidsgränser som inträffar när en tjänst är upptagen. Dessa fel är ofta självkorrigering, så om åtgärden upprepas efter en lämplig fördröjning kommer den sannolikt att lyckas.

Den här artikeln innehåller allmänna riktlinjer för tillfällig felhantering. Information om hur du hanterar 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.

Viktiga designstrategier

Tillfälliga fel kan uppstå i alla miljöer, på alla plattformar eller operativsystem, samt 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 av katastrofscenarier.

Molnvärdtjänster, inklusive privata molnsystem, kan erbjuda högre övergripande tillgänglighet med hjälp av delade resurser, redundans, automatisk redundans och dynamisk resursallokering över många beräkningsnoder för råvaror. 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 bidrar till att upprätthålla tjänstkvaliteten för grannar och andra klienter som använder den delade resursen.

  • Molnmiljöer använder ett stort antal maskinvaruenheter för råvaror. De ger prestanda genom att dynamiskt distribuera belastningen över flera beräkningsenheter och infrastrukturkomponenter. De ger tillförlitlighet genom att automatiskt återvinna eller ersätta enheter som misslyckats. 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 längre svarstid för anslutningar 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 göra kommunikationen långsam och orsaka tillfälliga anslutningsfel.

Utmaningar

Tillfälliga fel kan ha en betydande inverkan på den upplevda tillgängligheten för ett program, även om det har testats noggrant under alla förutsebara 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 sannolikt är tillfälliga, långvariga eller är terminalfel. Olika resurser returnerar sannolikt olika svar när ett fel inträffar, och dessa svar kan också variera beroende på åtgärdens kontext. 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 kontrakt med 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 försöka utföra åtgärden igen om det fastställer att felet sannolikt ä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. Strategin anger hur många gånger programmet ska försöka igen, fördröjningen mellan varje försök och de åtgärder som ska utföras efter ett misslyckat försök. Det lämpliga antalet försök och fördröjningen mellan var och en är ofta svåra att fastställa. Strategin varierar beroende på resurstyp och aktuella driftsvillkor för resursen och programmet.

Allmänna riktlinjer

Följande riktlinjer kan hjälpa dig att utforma lämpliga tillfälliga felhanteringsmekanismer för dina program.

Kontrollera om det finns en inbyggd mekanism för återförsök

  • Många tjänster tillhandahåller ett SDK eller klientbibliotek som innehåller en mekanism för hantering av tillfälliga fel. Återförsöksprincipen anpassas vanligtvis utifrån måltjänstens typ och krav. Alternativt kan REST-gränssnitt för tjänster 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 återförsök.

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

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

  • Utför endast återförsöksåtgärder när felen är tillfälliga (vilket vanligtvis anges av felets art) och när det är minst troligt att åtgärden lyckas när den görs på nytt. 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 detta och när villkoren är väl förstådda och kan valideras. Annars kan anropande kod implementera återförsök. Kom ihåg att felen som returneras från resurser och tjänster utanför din kontroll kan utvecklas med tiden, och du kan behöva gå tillbaka till logiken för övergående felidentifiering.

  • 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 särskilt 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 bör du överväga att returnera anpassade fel som har definierats i dina tjänstkontrakt. Även om generiska klienter kanske inte kan läsa dessa fel är de användbara när anpassade klienter skapas.

Fastställa ett lämpligt antal återförsök och intervall

  • Optimera antalet återförsök och intervallet för typen av användningsfall. Om du inte försöker igen tillräckligt många gånger kan programmet inte slutföra åtgärden och kommer förmodligen 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ärdena för tidsintervallet och antalet återförsök till typen av åtgärd. Om åtgärden till exempel är en del av en användarinteraktion bör intervallet vara kort och endast ett fåtal återförsök ska försökas. 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 svårast att fastställa lämpliga intervall mellan återförsök för att utforma en lyckad strategi. Vanliga strategier använder följande typer av intervall för återförsök:

    • Exponentiell back-off. Programmet väntar en kort tid innan det första återförsöket och ökar sedan exponentiellt tiden mellan varje efterföljande återförsök. Den kan till exempel försöka utföra åtgärden igen efter 3 sekunder, 12 sekunder, 30 sekunder och så vidare.

    • Inkrementella intervall. 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 samma tid mellan varje återförsök. Den kan till exempel försöka utföra åtgärden igen var tredje sekund.

    • Omedelbart återförsök. Ibland är ett tillfälligt fel kort, vilket kan orsakas av en händelse som en kollision med nätverkspaket eller en topp i en maskinvarukomponent. 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 rensas under den tid det tar för programmet att montera och skicka nästa begäran. Det får dock aldrig göras fler än ett omedelbart återförsök. Du bör växla till alternativa strategier, till exempel exponentiell back-off eller återställningsåtgärder, om det omedelbara återförsöket misslyckas.

    • Randomisering. 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 back off-strategi för bakgrundsåtgärder och använder omedelbara eller regelbundna återförsöksstrategier för intervall för interaktiva åtgärder. I båda fallen bör du välja fördröjning och antal försök så att den maximala svarstiden för alla antal återförsök ligger inom det obligatoriska svarstidskravet för slutpunkt till slutpunkt.

  • Ta hänsyn till kombinationen av alla faktorer som bidrar till den totala maximala tidsgränsen för en återförsöksåtgärd. Dessa faktorer omfattar den tid det tar för en misslyckad anslutning att generera ett svar (vanligtvis anges av ett timeout-värde i klienten), fördröjningen mellan återförsök och det maximala antalet återförsök. Summan av alla dessa gånger kan resultera i långa totala driftstider, särskilt när du använder en exponentiell fördröjningsstrategi där intervallet mellan återförsök växer snabbt efter varje fel. Om en process måste uppfylla ett specifikt serviceavtal (SLA) måste den övergripande drifttiden, inklusive alla tidsgränser och förseningar, ligga inom de gränser som definieras i serviceavtalet.

  • Implementera inte alltför aggressiva återförsöksstrategier. Det här är strategier som har intervall som är för korta eller återförsök som är för frekventa. De kan ha en negativ effekt på målresursen eller -tjänsten. Dessa strategier kan förhindra att resursen eller tjänsten återställs från dess överbelastade tillstånd, och den fortsätter att blockera eller avvisa begäranden. Det här scenariot resulterar i en ond cirkel, där fler och fler begäranden skickas till resursen eller tjänsten. Följaktligen minskar dess förmåga att återhämta sig 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). Överväg också om du behöver hå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 försöka 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-koden 503, Tjänsten är inte tillgänglig, med ett Retry-After-huvud i svaret) kan tyda på hur länge felet kan vara eller att tjänsten misslyckades och inte svarar på några efterföljande försök.

  • Överväg att använda en kömetod med obeställbara meddelanden för att se till att all information från det inkommande anropet inte går förlorad när alla återförsök har uttömts.

Undvik antimönster

  • I de flesta fall undviker du implementeringar som innehåller duplicerade lager med återförsökskod. Undvik design som omfattar sammanhängande återförsöksmekanismer 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 undantagsfall använder du principer som förhindrar överdrivna antal återförsök och fördröjningstider, och ser till att du förstår konsekvenserna. Anta till exempel att en komponent skickar en begäran till en annan, som sedan får åtkomst till måltjänsten. Om du implementerar återförsök med antalet tre på båda anropen finns det 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 dessa mekanismer om du behöver implementera återförsök på en högre nivå.

  • Implementera aldrig en oändlig mekanism för återförsök. Om du gör det förhindras troligen resursen eller tjänsten från att återställas från överbelastningssituationer och orsaka 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.

  • Utför aldrig ett omedelbart återförsök mer än en gång.

  • Undvik att använda ett regelbundet återförsöksintervall när du kommer åt 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 backoff-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 kan du införa slumpmässighet i återförsöksintervallen.

Testa din strategi för återförsök och implementering

  • Testa strategin för återförsök fullständigt under en så bred uppsättning omständigheter som möjligt, särskilt när både programmet och målresurserna eller tjänsterna som används är extremt belastade. Om du vill kontrollera beteende under testningen kan du:

    • Mata in tillfälliga och icke-övergående fel i tjänsten. Skicka till exempel ogiltiga begäranden eller lägg till kod som identifierar testbegäranden och svarar med olika typer av fel.

    • Skapa en modell av resursen eller tjänsten som returnerar ett antal fel som den verkliga tjänsten kan returnera. Ta upp alla typer av fel som din strategi för återförsök är utformad för att identifiera.

    • För anpassade tjänster som du skapar och distribuerar tvingar du tillfälliga fel att inträffa 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 feltillstånden, för tillfälliga fel och andra typer av fel.

    • När du testar ett klientwebbprograms motståndskraft mot tillfälliga fel använder du webbläsarens utvecklarverktyg eller testramverkets möjlighet att simulera 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. Dessa tester hjälper också till att säkerställa att återförsöket inte har en negativ effekt på klientens drift eller orsakar korskontaminering mellan begäranden.

Hantera konfigurationer av återförsöksprinciper

  • En återförsöksprincip är en kombination av alla element i din återförsöksstrategi. 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 randomisering), 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 med 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. Lagra till exempel värden som intervall och antal återförsök i programkonfigurationsfiler, läsa dem vid körning och programmatiskt skapa återförsöksprinciperna. På så sätt blir det enklare att hantera inställningarna och ändra och finjustera värdena för att svara på ändrade krav och scenarier. Utforma dock systemet så att värdena lagras 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. Dessa strategier är vanligtvis allmänna. I vissa scenarier kan de vara allt du behöver, men i andra scenarier erbjuder de inte alla alternativ som passar dina specifika krav. För att fastställa de lämpligaste värdena måste du utföra testning för att förstå hur inställningarna påverkar ditt program.

Logga och spåra tillfälliga och icke-tillfälliga fel

  • Som en del av din strategi för återförsök inkluderar du undantagshantering och annan instrumentation som loggar återförsök. Ett tillfälligt tillfälligt fel och återförsök förväntas och indikerar inte något problem. Regelbundna och ökande antal återförsök är dock ofta en indikator på ett problem som kan orsaka ett fel eller som försämrar 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 falska aviseringar.

  • Överväg att lagra ett värde i dina loggposter som anger om återförsök orsakas av begränsning i tjänsten eller av andra typer av fel, till exempel anslutningsfel, så att du kan särskilja dem under analysen av data. En ökning av antalet begränsningsfel är ofta ett tecken på ett utformningsfel i programmet eller på ett behov av att byta till en premiumtjänst som erbjuder dedikerad maskinvara.

  • Överväg att mäta och logga de totala 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 även 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 generera aviseringar när antalet och felfrekvensen, det genomsnittliga antalet återförsök eller de totala tiderna som förflutit innan åtgärderna lyckas ökar.

Hantera åtgärder som kontinuerligt misslyckas

  • Överväg hur du hanterar åtgärder som fortsätter att misslyckas vid varje försök. Situationer som denna är oundvikliga.

    • Även om en strategi för återförsök definierar det maximala antalet gånger som en åtgärd ska försökas 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 permanent gör att den slutar fungera, 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 gör en beställning görs ett nytt försök att utföra åtgärden, även om den misslyckas varje gång.

    • Om du vill 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, returnerar begäranden omedelbart till anroparen som fel och det görs inget försök att komma åt den misslyckade resursen eller tjänsten.

    • Programmet kan regelbundet testa tjänsten, tillfälligt och med långa intervall mellan begäranden, för att identifiera när den blir tillgänglig. Ett lämpligt intervall beror på faktorer som åtgärdens allvarlighetsgrad och tjänstens natur. Det kan vara allt mellan några minuter och flera timmar. När testet lyckas kan programmet återuppta normala åtgärder och skicka begäranden 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 kommer att vara tillgänglig snart. Det kan till exempel vara lämpligt att lagra begäranden för tjänsten i en kö eller ett datalager och försöka 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 om att programmet inte är tillgängligt för närvarande.

Ytterligare överväganden

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

  • Överväg om ett nytt försök med samma åtgärd kan orsaka inkonsekvenser i data. Om vissa delar av en process i flera steg upprepas och åtgärderna inte är idempotenter 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.

  • Överväg omfånget för åtgärder som görs om. Det kan till exempel vara enklare att implementera återförsökskod på en nivå som omfattar flera åtgärder och försöka igen om en misslyckas. Detta kan dock resultera i idempotensproblem 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.

  • Överväg hur din strategi för återförsök kan påverka grannar och andra klientorganisationer i ett delat program och när du använder delade resurser och tjänster. Aggressiva principer för återförsök kan orsaka att ett större antal tillfälliga fel inträffar för dessa andra användare och för program som delar resurserna och tjänsterna. På samma sätt kan ditt program påverkas av återförsöksprinciperna 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.

Anteckning

Se Problem och överväganden i artikeln Omförsöksmönster för ytterligare vägledning om kompromisser och risker.

Azure-underlättande

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

Tjänst Återförsöksfunktioner Principkonfiguration Omfång Telemetrifunktioner
Microsoft Entra ID Inbyggt i Microsoft Authentication Library (MSAL) Inbäddad i MSAL-biblioteket Intern Ingen
Azure Cosmos DB Inbyggt i tjänsten Kan inte konfigureras Global TraceSource
Azure Data Lake Storage Inbyggt i klienten Kan inte konfigureras Enskilda åtgärder Ingen
Azure Event Hubs Inbyggt i klienten Programmässig Client Ingen
Azure IoT Hub Intern i klient-SDK Programmässig Client Ingen
Azure Cache for Redis Inbyggt i klienten Programmässig Client TextWriter
Azure Cognitive Search Inbyggt i klienten Programmässig Client ETW eller anpassad
Azure Service Bus Inbyggt i klienten Programmässig NamespaceManager, MessagingFactory och klienten ETW
Azure Service Fabric Inbyggt i klienten Programmässig Client Ingen
Azure SQL Database med ADO.NET Polly Deklarativ och programmässig Enskilda instruktioner eller kodblock Anpassat
SQL Database med Entity Framework Inbyggt i klienten Programmässig Global per AppDomain Ingen
SQL Database med Entity Framework Core Inbyggt i klienten Programmässig Global per AppDomain Ingen
Azure Storage Inbyggt i klienten Programmässig Klientåtgärder och enskilda åtgärder TraceSource

Anteckning

För de flesta inbyggda återförsöksmekanismer 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.

Exempel

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