Återhämtning av program och infrastruktur
Motståndskraft är möjligheten att återställa efter övergående fel. Appens återhämtningsstrategi återställer normal funktion med minimal inverkan på användaren. 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.
Metoder för motståndskraft
När du utformar motståndskraftiga program måste du ofta välja mellan snabb och graciös försämring. Om det inte går snabbt utlöser programmet omedelbart ett fel eller ett undantag när något går fel, i stället för att försöka återställa eller kringgå problemet. Detta gör att problem kan identifieras och åtgärdas snabbt. En graciös försämring innebär att programmet försöker fortsätta att fungera i en begränsad kapacitet ä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. Om du misslyckas snabbt kan ett fel i en tjänst snabbt ta bort beroende tjänster, vilket minskar den övergripande systemåterhämtningen. 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 försämring bättre med bästa praxis för återhämtning 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 förklaras hur du implementerar både kodbaserad och infrastrukturbaserad återhämtning.
Kodbaserad motståndskraft
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 beteendet hos felhanteringen. I den här modulen tillämpar du strategierna Retry och Circuit Breaker på HTTP-klientåtgärder.
Återförsöksstrategi
En strategi för återförsök är exakt vad namnet antyder. Ett återförsök utförs för begäran efter en kort väntetid 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 kretsbrytarstrategi 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, vilket öppnar kretsen. Under den här väntan misslyckas ytterligare åtgärder på måltjänsten omedelbart utan att ens försöka ansluta tjänsten. När väntetiden har förflutit sker ett nytt försök med åtgärden. Om tjänsten svarar stängs kretsen och systemet återgår till det normala.
Infrastrukturbaserad motståndskraft
För implementering av infrastrukturbaserad motståndskraft kan du använda ett tjänstnät. Utöver motståndskraft som inte kräver kodändringar tillhandahåller tjänstnät trafikhantering, principer, säkerhet, stark identitet och överskådlighet. Din app är frikopplad från dessa operativa funktioner, som flyttas till infrastrukturskiktet.
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 en extra dimension vad gäller hantering av klustret, men den lägger inte till någon kod.
Med en kodbaserad metod:
- Du måste gissa vilka parametrar för återförsök och tidsgräns som är lämpliga.
- Du måste fokusera på en specifik HTTP-begäran.
Det finns inget rimligt sätt att svara på ett infrastrukturfel i koden för din app. Tänk dig de hundratals eller tusentals begäranden som bearbetas samtidigt. Även ett återförsök med exponentiell begränsning (gånger antalet begäranden) kan överbelasta en tjänst.
Infrastrukturbaserade metoder är däremot inte medvetna om interna appar. 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 enheter implementerar du motståndskraft för en mikrotjänstbaserad app med hjälp av .NET HTTP-återhämtning i kod och ett Linkerd-tjänstnät.