Delen via

Tolerantie en hoge beschikbaarheid in microservices

  • Artikel

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.

PDF downloaden

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

Het oplossen van onverwachte fouten is een van de moeilijkste problemen, met name in een gedistribueerd systeem. Veel van de code die ontwikkelaars schrijven, omvat het verwerken van uitzonderingen, en dit is ook waar de meeste tijd wordt besteed aan het testen. Het probleem is meer betrokken dan het schrijven van code voor het afhandelen van fouten. Wat gebeurt er wanneer de machine waarop de microservice wordt uitgevoerd, mislukt? U moet deze microservicefout niet alleen detecteren (een moeilijk probleem zelf), maar u hebt ook iets nodig om uw microservice opnieuw op te starten.

Een microservice moet bestand zijn tegen fouten en kan vaak opnieuw worden opgestart op een andere computer voor beschikbaarheid. Deze tolerantie komt ook neer op de status die is opgeslagen namens de microservice, waar de microservice deze status kan herstellen en of de microservice opnieuw kan worden opgestart. Met andere woorden, er moet tolerantie zijn in de rekenfunctie (het proces kan op elk gewenst moment opnieuw worden opgestart) en tolerantie in de status of gegevens (geen gegevensverlies en de gegevens blijven consistent).

De problemen met tolerantie worden tijdens andere scenario's samengesteld, zoals wanneer er fouten optreden tijdens een upgrade van een toepassing. De microservice, die met het implementatiesysteem werkt, moet bepalen of het kan doorgaan naar de nieuwere versie of in plaats daarvan teruggaan naar een eerdere versie om een consistente status te behouden. Vragen zoals of er voldoende machines beschikbaar zijn om verder te gaan en hoe u eerdere versies van de microservice kunt herstellen, moet worden overwogen. Deze aanpak vereist dat de microservice statusinformatie verzendt, zodat de algehele toepassing en orchestrator deze beslissingen kunnen nemen.

Daarnaast is tolerantie gerelateerd aan hoe cloudsystemen zich moeten gedragen. Zoals vermeld, moet een cloudsysteem fouten omarmen en proberen om er automatisch van te herstellen. In het geval van netwerk- of containerfouten moeten client-apps of clientservices bijvoorbeeld een strategie hebben om berichten opnieuw te verzenden of aanvragen opnieuw uit te voeren, omdat in veel gevallen fouten in de cloud gedeeltelijk zijn. In de sectie Resilient Applications implementeren in deze handleiding wordt uitgelegd hoe u gedeeltelijke fouten kunt afhandelen. Het beschrijft technieken zoals nieuwe pogingen met exponentieel uitstel of het circuitonderbrekerpatroon in .NET met behulp van bibliotheken zoals Polly, die een grote verscheidenheid aan beleidsregels biedt voor het afhandelen van dit onderwerp.

Statusbeheer en diagnostische gegevens in microservices

Het lijkt misschien duidelijk en het wordt vaak over het hoofd gezien, maar een microservice moet de status en diagnose rapporteren. Anders is er weinig inzicht vanuit het perspectief van bewerkingen. Het correleren van diagnostische gebeurtenissen in een set onafhankelijke services en het omgaan met scheeftrekken van machineklokken om te begrijpen dat de gebeurtenisvolgorde lastig is. Op dezelfde manier dat u met een microservice communiceert over overeengekomen protocollen en gegevensindelingen, is er behoefte aan standaardisatie voor het vastleggen van status- en diagnostische gebeurtenissen die uiteindelijk in een gebeurtenisarchief terechtkomen om query's uit te voeren en te bekijken. In een microservicesbenadering is het belangrijk dat verschillende teams het eens zijn over één indeling voor logboekregistratie. Er moet een consistente benadering zijn voor het weergeven van diagnostische gebeurtenissen in de toepassing.

Statuscontroles

De status verschilt van diagnostische gegevens. De status gaat over de microservice die de huidige status rapporteert om passende acties uit te voeren. Een goed voorbeeld is het werken met upgrade- en implementatiemechanismen om de beschikbaarheid te behouden. Hoewel een service momenteel niet in orde is vanwege een procescrash of het opnieuw opstarten van de machine, is de service mogelijk nog steeds operationeel. Het laatste wat u nodig hebt, is om dit erger te maken door een upgrade uit te voeren. De beste aanpak is om eerst een onderzoek uit te voeren of tijd te bieden voor het herstellen van de microservice. Gezondheidsgebeurtenissen van een microservice helpen ons weloverwogen beslissingen te nemen en, in feite, zelfhersteldiensten te creëren.

In de sectie Statuscontroles implementeren in ASP.NET Sectie Kernservices van deze handleiding leggen we uit hoe u een nieuwe ASP.NET HealthChecks-bibliotheek in uw microservices kunt gebruiken, zodat ze hun status kunnen rapporteren aan een bewakingsservice om de juiste acties uit te voeren.

U hebt ook de mogelijkheid om een uitstekende opensource-bibliotheek met de naam AspNetCore.Diagnostics.HealthChecks te gebruiken, beschikbaar op GitHub en als een NuGet-pakket. Deze bibliotheek voert ook statuscontroles uit, met een twist, en verwerkt twee soorten controles:

  • Liveness: controleert of de microservice actief is, dat wil gezegd, als deze aanvragen kan accepteren en erop kan reageren.
  • Gereedheid: controleert of de afhankelijkheden van de microservice (database, wachtrijservices, enzovoort) zelf gereed zijn, zodat de microservice kan doen wat het moet doen.

Gebeurtenisstromen voor diagnostische gegevens en logboeken gebruiken

Logboeken bevatten informatie over hoe een toepassing of service wordt uitgevoerd, waaronder uitzonderingen, waarschuwingen en eenvoudige informatieve berichten. Normaal gesproken heeft elk logboek een tekstindeling met één regel per gebeurtenis, hoewel uitzonderingen ook vaak de stacktracering op meerdere regels weergeven.

In monolithische servertoepassingen kunt u logboeken schrijven naar een bestand op schijf (een logboekbestand) en deze vervolgens analyseren met elk hulpprogramma. Omdat de uitvoering van toepassingen beperkt is tot een vaste server of VIRTUELE machine, is het over het algemeen niet te complex om de stroom van gebeurtenissen te analyseren. In een gedistribueerde toepassing waarin meerdere services worden uitgevoerd op veel knooppunten in een orchestratorcluster, is het echter een uitdaging om gedistribueerde gebeurtenissen te correleren.

Een microservicetoepassing mag niet proberen de uitvoerstroom van gebeurtenissen of logboekbestanden zelf op te slaan en niet eens proberen de routering van de gebeurtenissen naar een centrale plaats te beheren. Het moet transparant zijn, wat betekent dat elk proces alleen de gebeurtenisstroom moet schrijven naar een standaarduitvoer die eronder wordt verzameld door de infrastructuur van de uitvoeringsomgeving waar het wordt uitgevoerd. Een voorbeeld van deze gebeurtenisstroomrouters is Microsoft.Diagnostic.EventFlow, dat gebeurtenisstromen van meerdere bronnen verzamelt en publiceert naar uitvoersystemen. Dit kan bestaan uit eenvoudige standaarduitvoer voor een ontwikkelomgeving of cloudsystemen zoals Azure Monitor en Azure Diagnostics. Er zijn ook goede platformen en hulpprogramma's voor logboekanalyse van derden die logboeken kunnen doorzoeken, waarschuwen, rapporteren en bewaken, zelfs in realtime, zoals Splunk.

Orchestrators die status- en diagnostische gegevens beheren

Wanneer u een toepassing op basis van een microservice maakt, moet u te maken krijgen met complexiteit. Natuurlijk is één microservice eenvoudig om mee om te gaan, maar tientallen of honderden typen en duizenden exemplaren van microservices is een complex probleem. Het gaat niet alleen om het bouwen van uw microservicearchitectuur. U hebt ook hoge beschikbaarheid, adresseerbaarheid, tolerantie, status en diagnostische gegevens nodig als u een stabiel en samenhangend systeem wilt hebben.

Diagram of clusters supplying a support platform for microservices.

Afbeelding 4-22. Een Microservice-platform is essentieel voor het statusbeheer van een toepassing

De complexe problemen die in afbeelding 4-22 worden weergegeven, zijn moeilijk zelf op te lossen. Ontwikkelteams moeten zich richten op het oplossen van zakelijke problemen en het bouwen van aangepaste toepassingen met op microservice gebaseerde benaderingen. Ze moeten zich niet richten op het oplossen van complexe infrastructuurproblemen; Als dat het geval is, zijn de kosten van een toepassing op basis van microservices enorm. Daarom zijn er microservicegeoriënteerde platforms, ook wel orchestrators of microserviceclusters genoemd, die proberen de harde problemen op te lossen van het bouwen en uitvoeren van een service en het efficiënt gebruiken van infrastructuurbronnen. Deze aanpak vermindert de complexiteit van het bouwen van toepassingen die gebruikmaken van een microservicesbenadering.

Verschillende orchestrators kunnen vergelijkbaar klinken, maar de diagnostische en statuscontroles die door elk ervan worden aangeboden, verschillen in functies en de volwassenheid, soms afhankelijk van het besturingssysteemplatform, zoals wordt uitgelegd in de volgende sectie.

Aanvullende bronnen

VorigeVolgende