Dela via

Återhämtning och hög tillgänglighet i mikrotjänster

  • 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.

Att hantera oväntade fel är ett av de svåraste problemen att lösa, särskilt i ett distribuerat system. Mycket av den kod som utvecklare skriver omfattar hantering av undantag, och det är också här som mest tid ägnas åt testning. Problemet är mer inblandat än att skriva kod för att hantera fel. Vad händer när datorn där mikrotjänsten körs misslyckas? Du behöver inte bara identifiera det här mikrotjänstfelet (ett hårt problem på egen hand), utan du behöver också något för att starta om mikrotjänsten.

En mikrotjänst måste vara motståndskraftig mot fel och kunna startas om ofta på en annan dator för tillgänglighet. Den här motståndskraften beror också på det tillstånd som sparades för mikrotjänstens räkning, där mikrotjänsten kan återställa det här tillståndet från och om mikrotjänsten kan startas om. Med andra ord måste det finnas återhämtning i beräkningsfunktionen (processen kan startas om när som helst) samt återhämtning i tillståndet eller data (ingen dataförlust och data förblir konsekventa).

Problem med återhämtning förvärras under andra scenarier, till exempel när fel inträffar under en programuppgradering. Mikrotjänsten, som arbetar med distributionssystemet, måste avgöra om den kan fortsätta att gå vidare till den nyare versionen eller i stället återställa till en tidigare version för att upprätthålla ett konsekvent tillstånd. Frågor som om tillräckligt många datorer är tillgängliga för att fortsätta framåt och hur du återställer tidigare versioner av mikrotjänsten måste beaktas. Den här metoden kräver att mikrotjänsten genererar hälsoinformation så att det övergripande programmet och orkestreraren kan fatta dessa beslut.

Dessutom är återhämtning relaterad till hur molnbaserade system måste bete sig. Som nämnts måste ett molnbaserat system omfatta fel och måste försöka återställa automatiskt från dem. Om det till exempel uppstår nätverks- eller containerfel måste klientappar eller klienttjänster ha en strategi för att försöka skicka meddelanden igen eller försöka skicka begäranden igen, eftersom fel i molnet i många fall är partiella. Avsnittet Implementera elastiska program i den här guiden beskriver hur du hanterar partiella fel. Den beskriver tekniker som återförsök med exponentiell backoff eller kretsbrytarmönstret i .NET med hjälp av bibliotek som Polly, som erbjuder en mängd olika principer för att hantera det här ämnet.

Hälsohantering och diagnostik i mikrotjänster

Det kan verka uppenbart, och det förbises ofta, men en mikrotjänst måste rapportera sin hälsa och diagnostik. Annars finns det lite insikt ur ett driftsperspektiv. Det är svårt att korrelera diagnostikhändelser i en uppsättning oberoende tjänster och hantera maskinursnedvridningar för att förstå händelseordningen. På samma sätt som du interagerar med en mikrotjänst över överenskomna protokoll och dataformat, finns det ett behov av standardisering i hur du loggar hälso- och diagnostikhändelser som slutligen hamnar i ett händelselager för frågor och visning. I en mikrotjänstmetod är det viktigt att olika team är överens om ett enda loggningsformat. Det måste finnas en konsekvent metod för att visa diagnostikhändelser i programmet.

Hälsokontroller

Hälsa skiljer sig från diagnostik. Hälsa handlar om att mikrotjänsten rapporterar sitt aktuella tillstånd för att vidta lämpliga åtgärder. Ett bra exempel är att arbeta med uppgraderings- och distributionsmekanismer för att upprätthålla tillgängligheten. Även om en tjänst för närvarande kan vara felaktig på grund av en processkrasch eller omstart av datorn, kan tjänsten fortfarande vara i drift. Det sista du behöver är att göra detta värre genom att utföra en uppgradering. Det bästa sättet är att göra en undersökning först eller ge mikrotjänsten tid att återställa. Hälsohändelser från en mikrotjänst hjälper oss att fatta välgrundade beslut och i själva verket hjälpa till att skapa självåterställningstjänster.

I avsnittet Implementera hälsokontroller i ASP.NET Core-tjänster i den här guiden förklarar vi hur du använder ett nytt ASP.NET HealthChecks-bibliotek i dina mikrotjänster så att de kan rapportera sitt tillstånd till en övervakningstjänst för att vidta lämpliga åtgärder.

Du kan också använda ett utmärkt bibliotek med öppen källkod som heter AspNetCore.Diagnostics.HealthChecks, tillgängligt på GitHub och som ett NuGet-paket. Det här biblioteket utför även hälsokontroller, med en twist, som hanterar två typer av kontroller:

  • Liveness: Kontrollerar om mikrotjänsten är vid liv, dvs. om den kan acceptera begäranden och svara.
  • Beredskap: Kontrollerar om mikrotjänstens beroenden (databas, kötjänster osv.) själva är klara, så att mikrotjänsten kan göra vad den ska göra.

Använda diagnostik och loggar händelseströmmar

Loggarna innehåller information om hur ett program eller en tjänst körs, inklusive undantag, varningar och enkla informationsmeddelanden. Vanligtvis är varje logg i ett textformat med en rad per händelse, men undantag visar ofta stackspårningen över flera rader.

I monolitiska serverbaserade program kan du skriva loggar till en fil på disk (en loggfil) och sedan analysera den med valfritt verktyg. Eftersom programkörningen är begränsad till en fast server eller virtuell dator är det vanligtvis inte så komplext att analysera händelseflödet. I ett distribuerat program där flera tjänster körs över många noder i ett orchestrator-kluster är det dock en utmaning att kunna korrelera distribuerade händelser.

Ett mikrotjänstbaserat program bör inte försöka lagra utdataströmmen av händelser eller loggfiler på egen hand och inte ens försöka hantera routningen av händelserna till en central plats. Det bör vara transparent, vilket innebär att varje process bara ska skriva sin händelseström till en standardutdata som under samlas in av infrastrukturen för körningsmiljön där den körs. Ett exempel på dessa händelseströmsroutrar är Microsoft.Diagnostic.EventFlow, som samlar in händelseströmmar från flera källor och publicerar dem till utdatasystem. Dessa kan omfatta enkla standardutdata för en utvecklingsmiljö eller molnsystem som Azure Monitor och Azure Diagnostics. Det finns också bra plattformar och verktyg för logganalys från tredje part som kan söka efter, varna, rapportera och övervaka loggar, även i realtid, till exempel Splunk.

Orkestratorer som hanterar hälso- och diagnostikinformation

När du skapar ett mikrotjänstbaserat program måste du hantera komplexiteten. Naturligtvis är en enda mikrotjänst enkel att hantera, men dussintals eller hundratals typer och tusentals instanser av mikrotjänster är ett komplext problem. Det handlar inte bara om att skapa din mikrotjänstarkitektur – du behöver också hög tillgänglighet, adresserbarhet, återhämtning, hälsa och diagnostik om du tänker ha ett stabilt och sammanhängande system.

Diagram of clusters supplying a support platform for microservices.

Bild 4-22. En mikrotjänstplattform är grundläggande för ett programs hälsohantering

De komplexa problem som visas i bild 4-22 är svåra att lösa själv. Utvecklingsteamen bör fokusera på att lösa affärsproblem och skapa anpassade program med mikrotjänstbaserade metoder. De bör inte fokusera på att lösa komplexa infrastrukturproblem. Om de gjorde det skulle kostnaden för ett mikrotjänstbaserat program vara enorm. Därför finns det mikrotjänstorienterade plattformar, så kallade orkestrerings- eller mikrotjänstkluster, som försöker lösa de svåra problemen med att skapa och köra en tjänst och använda infrastrukturresurser effektivt. Den här metoden minskar komplexiteten i att skapa program som använder en mikrotjänstmetod.

Olika orkestrerare kan låta liknande, men diagnostik- och hälsokontrollerna som erbjuds av var och en av dem skiljer sig åt i funktioner och mognadstillstånd, ibland beroende på OS-plattformen, som beskrivs i nästa avsnitt.

Ytterligare resurser

FöregåendeNästa