Återhämtning av program och infrastruktur
Återhämtning är möjligheten att återställa från tillfälliga fel. Appens återställningsstrategi återställer normal funktion med minimal användarpåverkan. Fel kan inträffa i molnmiljöer och appen bör svara på ett sätt som minimerar driftstopp och dataförlust. I en idealisk situation hanterar appen fel på ett smidigt sätt utan att användaren någonsin vet att det har uppstått ett problem.
Eftersom mikrotjänstmiljöer kan vara instabila kan du utforma dina appar så att de kan förvänta sig och hantera partiella fel. Ett partiellt fel kan till exempel omfatta kodfel, nätverksfel, serverprocesser som inte svarar eller maskinvarufel. Även planerade aktiviteter, till exempel att flytta containrar till en annan nod i ett Kubernetes-kluster, kan orsaka ett tillfälligt fel.
Återhämtningsmetoder
När du utformar motståndskraftiga program måste du ofta välja mellan snabb och graciös försämring. Med "fail fast" menas att programmet omedelbart utlöser ett fel eller undantag när något går snett, snarare än att försöka återhämta sig eller kringgå problemet. Detta gör att problem kan identifieras och åtgärdas snabbt. En gradvis försämring innebär att programmet försöker fortsätta att fungera med begränsad funktionalitet även när någon komponent misslyckas.
I molnbaserade program är det viktigt att tjänsterna hanterar fel på ett korrekt sätt i stället för att misslyckas snabbt. Eftersom mikrotjänster är decentraliserade och oberoende distributionsbara förväntas partiella fel. Att misslyckas snabbt skulle kunna orsaka att ett fel i en tjänst snabbt drar ner beroende tjänster, vilket minskar den övergripande systemresiliensen. I stället bör mikrotjänster kodas för att förutse och tolerera både interna och externa tjänstfel. Den här graciösa försämringen gör att det övergripande systemet kan fortsätta att fungera även om vissa tjänster störs. Kritiska användarinriktade funktioner kan upprätthållas, vilket undviker ett fullständigt avbrott. Ett smidigt fel gör också att störd tjänsttid kan återställas eller repareras själv innan resten av systemet påverkas. Så för mikrotjänstbaserade program överensstämmer graciös nedbrytning bättre med resilienspraxis som felisolering och snabb återställning. Det hindrar lokala incidenter från att spridas över hela systemet.
Det finns två grundläggande metoder för att stödja en graciös försämring med återhämtning: program och infrastruktur. Varje metod har fördelar och nackdelar. Båda metoderna kan vara lämpliga beroende på situationen. I den här modulen beskrivs hur du implementerar både kodbaserad och infrastrukturbaserad resiliens.
Kodbaserad återhämtning
För att implementera kodbaserad återhämtning har .NET ett tilläggsbibliotek för motståndskraft och hantering av tillfälliga fel, Microsoft.Extensions.Http.Resilience.
Den använder en flytande, lättförstuderad syntax för att skapa felhanteringskod på ett trådsäkert sätt. Det finns flera motståndskraftsprinciper som definierar beteende för felhantering. I den här modulen tillämpar du strategierna Retry och Circuit Breaker på HTTP-klientåtgärder.
Återförsöksstrategi
En Försök igen strategi är precis vad namnet antyder. Begäran görs på nytt efter en kort väntan om ett felsvar tas emot. Väntetiden ökar för varje nytt försök. Ökningen kan vara linjär eller exponentiell.
När det maximala antalet återförsök har nåtts ger strategin upp och utlöser ett undantag. Från användarens perspektiv tar appen vanligtvis längre tid att slutföra vissa åtgärder. Det kan också ta lite tid innan appen informerar användaren om att den inte kunde slutföra åtgärden.
Strategi för kretsbrytare
En kretsbrytare strategi ger en måltjänst en paus efter ett upprepat antal fel genom att pausa försök att kommunicera med den. Tjänsten kan ha ett allvarligt problem och kan tillfälligt inte svara. Efter ett definierat antal efterföljande fel pausas anslutningsförsöken öppnar kretsen. Under den här väntan misslyckas ytterligare åtgärder på måltjänsten omedelbart, utan att man ens försöker ansluta till tjänsten. När väntetiden har förflutit görs åtgärden igen. Om tjänsten svarar framgångsrikt stängs kretsen och systemet återgår till det normala.
Infrastrukturbaserad återhämtning
Om du vill implementera infrastrukturbaserad återhämtning kan du använda ett nätverkslager. Förutom återhämtning utan att ändra kod ger ett servicenät trafikhantering, princip, säkerhet, stark identitet och observerbarhet. Appen är frikopplad från dessa driftfunktioner som flyttas till infrastrukturlagret.
Jämförelse med kodbaserade metoder
En infrastrukturbaserad återhämtningsmetod kan använda en måttbaserad vy som gör att den kan anpassas dynamiskt till klusterförhållanden i realtid. Den här metoden lägger till ytterligare en dimension för att hantera klustret men lägger inte till någon kod.
Med en kodbaserad metod:
- Krävs för att gissa vilka parametrar för återförsök och tidsgräns som är lämpliga.
- Fokusera på en specifik HTTP-begäran.
Det finns inget rimligt sätt att svara på ett infrastrukturfel i appens kod. Överväg de hundratals eller tusentals begäranden som bearbetas samtidigt. Även ett nytt försök med exponentiell back-off baserat på antal begäranden kan överbelasta en tjänst.
Infrastrukturbaserade metoder är däremot inte medvetna om appars interna funktioner. Till exempel är komplexa databastransaktioner osynliga för tjänstnät. Sådana transaktioner kan endast skyddas från fel med en kodbaserad metod.
I kommande avsnitt implementerar du resiliens för en mikrotjänstbaserad applikation med hjälp av .NET HTTP-resiliens i kod och ett Linkerd-service mesh.