Gedeeltelijke fout afhandelen
Tip
Deze inhoud is een fragment uit het eBook, .NET Microservices Architecture for Containerized .NET Applications, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.
In gedistribueerde systemen, zoals toepassingen op basis van microservices, bestaat er een steeds aanwezig risico op gedeeltelijke storingen. Een enkele microservice/container kan bijvoorbeeld mislukken of is mogelijk niet beschikbaar om te reageren gedurende korte tijd, of een enkele VIRTUELE machine of server kan vastlopen. Omdat clients en services afzonderlijke processen zijn, kan een service mogelijk niet tijdig reageren op de aanvraag van een client. De service is mogelijk overbelast en reageert erg langzaam op aanvragen of is mogelijk gedurende korte tijd niet toegankelijk vanwege netwerkproblemen.
Denk bijvoorbeeld aan de pagina Ordergegevens uit de voorbeeldtoepassing eShopOnContainers. Als de bestellende microservice niet reageert wanneer de gebruiker probeert een bestelling in te dienen, blokkeert een slechte implementatie van het clientproces (de MVC-webtoepassing) bijvoorbeeld, als de clientcode synchrone RPC's zonder time-out zou gebruiken, threads voor onbepaalde tijd blokkeren die op een antwoord wachten. Naast het creëren van een slechte gebruikerservaring, verbruikt elke niet-reagerende wachttijd een thread of blokkeert een thread en threads zijn uiterst waardevol in zeer schaalbare toepassingen. Als er veel geblokkeerde threads zijn, kan de runtime van de toepassing uiteindelijk geen threads meer bevatten. In dat geval kan de toepassing globaal niet meer reageren in plaats van slechts gedeeltelijk niet meer reageren, zoals wordt weergegeven in afbeelding 8-1.
Afbeelding 8-1. Gedeeltelijke fouten vanwege afhankelijkheden die van invloed zijn op de beschikbaarheid van servicethreads
In een grote toepassing op basis van microservices kan elke gedeeltelijke fout worden versterkt, met name als de meeste interne microservicesinteractie is gebaseerd op synchrone HTTP-aanroepen (wat wordt beschouwd als een antipatroon). Denk aan een systeem dat miljoenen binnenkomende oproepen per dag ontvangt. Als uw systeem een slecht ontwerp heeft dat is gebaseerd op lange ketens van synchrone HTTP-aanroepen, kunnen deze binnenkomende aanroepen leiden tot veel meer miljoenen uitgaande aanroepen (stel dat een verhouding van 1:4) tot tientallen interne microservices als synchrone afhankelijkheden wordt gebruikt. Deze situatie wordt weergegeven in afbeelding 8-2, met name afhankelijkheid #3, die een keten start, afhankelijkheid aanroept #4, die vervolgens #5 aanroept.
Afbeelding 8-2. De impact van een onjuist ontwerp met lange ketens van HTTP-aanvragen
Onregelmatige fouten worden gegarandeerd in een gedistribueerd en cloudsysteem, zelfs als elke afhankelijkheid zelf een uitstekende beschikbaarheid heeft. Het is een feit dat je moet overwegen.
Als u geen technieken ontwerpt en implementeert om fouttolerantie te garanderen, kunnen zelfs kleine downtimes worden versterkt. Bijvoorbeeld: 50 afhankelijkheden met elk 99,99% van de beschikbaarheid zouden leiden tot enkele uren downtime per maand vanwege dit rimpeleffect. Wanneer een microserviceafhankelijkheid mislukt tijdens het verwerken van een groot aantal aanvragen, kan die fout snel alle beschikbare aanvraagthreads in elke service verzadigen en de hele toepassing vastlopen.
Afbeelding 8-3. Gedeeltelijke fout versterkt door microservices met lange ketens van synchrone HTTP-aanroepen
Om dit probleem te minimaliseren, dwingt deze handleiding u aan om in de sectie Asynchrone microserviceintegratie de autonomie van microservices af te dwingen.
Daarnaast is het essentieel dat u uw microservices en clienttoepassingen ontwerpt om gedeeltelijke fouten af te handelen, dat wil gezegd, om tolerante microservices en clienttoepassingen te bouwen.
