Dela via

Strategier för att hantera partiella fel

  • Artikel

Dricks

Det här innehållet är ett utdrag från eBook, .NET Microservices Architecture for Containerized .NET Applications, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.

Ladda ned PDF

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Om du vill hantera partiella fel använder du någon av de strategier som beskrivs här.

Använd asynkron kommunikation (till exempel meddelandebaserad kommunikation) mellan interna mikrotjänster. Det är mycket lämpligt att inte skapa långa kedjor av synkrona HTTP-anrop i de interna mikrotjänsterna eftersom den felaktiga designen så småningom blir den främsta orsaken till dåliga avbrott. Tvärtom, med undantag för klientdelskommunikationen mellan klientprogrammen och den första nivån av mikrotjänster eller detaljerade API Gateways rekommenderar vi att du endast använder asynkron (meddelandebaserad) kommunikation en gång efter den första begäran/svar-cykeln, över de interna mikrotjänsterna. Slutlig konsekvens och händelsedrivna arkitekturer hjälper till att minimera krusningseffekter. Dessa metoder tvingar fram en högre nivå av mikrotjänstautonomi och förhindrar därför mot det problem som anges här.

Använd återförsök med exponentiell backoff. Den här tekniken hjälper till att undvika korta och tillfälliga fel genom att utföra återförsök vid anrop ett visst antal gånger, om tjänsten inte bara var tillgänglig under en kort tid. Detta kan inträffa på grund av tillfälliga nätverksproblem eller när en mikrotjänst/container flyttas till en annan nod i ett kluster. Men om dessa återförsök inte är utformade korrekt med kretsbrytare kan det förvärra krusningseffekterna, vilket i slutändan till och med orsakar en DoS (Denial of Service).

Kringgå tidsgränser för nätverk. I allmänhet bör klienter utformas för att inte blockeras på obestämd tid och att alltid använda timeouter när de väntar på ett svar. Med timeouter säkerställer du att resurserna aldrig är bundna på obestämd tid.

Använd kretsbrytarmönstret. I den här metoden spårar klientprocessen antalet misslyckade begäranden. Om felfrekvensen överskrider en konfigurerad gräns, utlöser en kretsbrytare så att ytterligare försök misslyckas omedelbart. (Om ett stort antal begäranden misslyckas tyder det på att tjänsten inte är tillgänglig och att det är meningslöst att skicka begäranden.) Efter en timeoutperiod bör klienten försöka igen och stänga kretsbrytaren om de nya begärandena lyckas.

Ange återställningar. I den här metoden utför klientprocessen återställningslogik när en begäran misslyckas, till exempel när cachelagrade data returneras eller ett standardvärde. Det här är en metod som lämpar sig för frågor och är mer komplex för uppdateringar eller kommandon.

Begränsa antalet köade begäranden. Klienter bör också införa en övre gräns för antalet utestående begäranden som en klientmikrotjänst kan skicka till en viss tjänst. Om gränsen har nåtts är det förmodligen meningslöst att göra ytterligare begäranden, och dessa försök bör misslyckas omedelbart. När det gäller implementering kan polly bulkhead-isoleringsprincipen användas för att uppfylla detta krav. Den här metoden är i princip en parallelliseringsbegränsning med SemaphoreSlim som implementering. Det tillåter också en "kö" utanför skottet. Du kan proaktivt sprida överbelastning även före körning (till exempel eftersom kapaciteten anses vara full). Detta gör dess svar på vissa felscenarier snabbare än en kretsbrytare skulle vara, eftersom kretsbrytaren väntar på felen. BulkheadPolicy-objektet i Polly visar hur full skottet och kön är och erbjuder händelser på spill så att de även kan användas för automatisk horisontell skalning.

Ytterligare resurser

FöregåendeNästa