Patronen voor toepassingstolerantie

Tip

Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

De eerste verdedigingslinie is toepassingstolerantie.

Hoewel u veel tijd kunt investeren in het schrijven van uw eigen tolerantieframework, bestaan dergelijke producten al. Polly is een uitgebreide bibliotheek voor .NET-tolerantie en tijdelijke foutafhandeling waarmee ontwikkelaars tolerantiebeleid op een vloeiende en thread-veilige manier kunnen uitdrukken. Polly is gericht op toepassingen die zijn gebouwd met .NET Framework of .NET 7. In de volgende tabel worden de tolerantiefuncties beschreven, die policiesbeschikbaar zijn in de Polly-bibliotheek. Ze kunnen afzonderlijk of gegroepeerd worden toegepast.

Beleid	Ervaring
Opnieuw proberen	Configureert bewerkingen voor opnieuw proberen voor aangewezen bewerkingen.
Circuitonderbreker	Hiermee blokkeert u aangevraagde bewerkingen voor een vooraf gedefinieerde periode wanneer fouten een geconfigureerde drempelwaarde overschrijden
Timeout	Hiermee wordt een limiet opgegeven voor de duur waarvoor een beller kan wachten op een antwoord.
Bulkhead	Beperkt acties tot resourcegroep met vaste grootte om te voorkomen dat mislukte aanroepen een resource overspoelen.
Cache	Slaat antwoorden automatisch op.
Terugval	Definieert gestructureerd gedrag bij een fout.

Houd er rekening mee dat in de vorige afbeelding het tolerantiebeleid van toepassing is op aanvragen van berichten, ongeacht of deze afkomstig zijn van een externe client of back-endservice. Het doel is om de aanvraag voor een service te compenseren die tijdelijk niet beschikbaar is. Deze korte onderbrekingen komen meestal voor met de HTTP-statuscodes die in de volgende tabel worden weergegeven.

HTTP-statuscode	Oorzaak
404	Niet gevonden
408	Time-out van aanvraag
429	Te veel aanvragen (u bent waarschijnlijk beperkt)
502	Ongeldige gateway
503	Service niet beschikbaar
504	Time-out van gateway

Vraag: Wilt u een HTTP-statuscode van 403 - Verboden opnieuw proberen? Nee Hier werkt het systeem goed, maar informeert de beller dat deze niet gemachtigd is om de aangevraagde bewerking uit te voeren. U moet ervoor zorgen dat alleen de bewerkingen die worden veroorzaakt door fouten opnieuw proberen.

Zoals aanbevolen in hoofdstuk 1, moeten Microsoft-ontwikkelaars die cloudeigen toepassingen bouwen het .NET-platform richten. Versie 2.1 heeft de HTTPClientFactory-bibliotheek geïntroduceerd voor het maken van HTTP-clientexemplaren voor interactie met op URL gebaseerde resources. De fabrieksklasse vervangt de oorspronkelijke HTTPClient-klasse en biedt ondersteuning voor veel verbeterde functies, waaronder een nauwe integratie met de Polly-tolerantiebibliotheek. Hiermee kunt u eenvoudig tolerantiebeleid definiëren in de opstartklasse van de toepassing om gedeeltelijke fouten en connectiviteitsproblemen af te handelen.

Laten we nu verder gaan met patronen voor opnieuw proberen en circuitonderbrekers.

Patroon voor opnieuw proberen

In een gedistribueerde cloudeigen omgeving kunnen aanroepen naar services en cloudresources mislukken vanwege tijdelijke (kortstondige) fouten, die zichzelf doorgaans na een korte periode corrigeren. Het implementeren van een strategie voor opnieuw proberen helpt een cloudeigen service deze scenario's te beperken.

Met het patroon Opnieuw proberen kan een service een (configureerbaar) aantal keren opnieuw proberen om een mislukte aanvraagbewerking opnieuw uit te voeren met een exponentieel toenemende wachttijd. In afbeelding 6-2 ziet u een nieuwe poging in actie.

Afbeelding 6-2. Patroon voor opnieuw proberen in actie

In de vorige afbeelding is een patroon voor opnieuw proberen geïmplementeerd voor een aanvraagbewerking. Het is geconfigureerd om maximaal vier nieuwe pogingen toe te staan voordat het mislukt met een uitstelinterval (wachttijd) vanaf twee seconden, wat exponentieel verdubbelt voor elke volgende poging.

• De eerste aanroep mislukt en retourneert een HTTP-statuscode van 500. De toepassing wacht twee seconden en voert de aanroep opnieuw uit.
• De tweede aanroep mislukt ook en retourneert een HTTP-statuscode van 500. De toepassing verdubbelt nu het uitstelinterval tot vier seconden en voert de aanroep opnieuw uit.
• Ten slotte slaagt de derde aanroep.
• In dit scenario zou de bewerking voor opnieuw proberen maximaal vier nieuwe pogingen hebben geprobeerd terwijl de duur van de uitstelbewerking wordt verdubbeld voordat de aanroep mislukt.
• Als de 4e poging tot opnieuw proberen is mislukt, wordt er een terugvalbeleid aangeroepen om het probleem correct af te handelen.

Het is belangrijk om de uitstelperiode te verhogen voordat u de aanroep opnieuw probeert uit te voeren om de servicetijd zelf te laten corrigeren. Het is een best practice om een exponentieel toenemende back-off te implementeren (verdubbeling van de periode voor elke nieuwe poging) om voldoende correctietijd toe te staan.

Circuitonderbrekerpatroon

Hoewel het patroon voor opnieuw proberen kan helpen bij het oplossen van een aanvraag die is verstrengeld in een gedeeltelijke fout, zijn er situaties waarin fouten kunnen worden veroorzaakt door onverwachte gebeurtenissen waarvoor langere tijdsperioden nodig zijn om op te lossen. Deze fouten kunnen in ernst variëren, van een gedeeltelijke verbroken verbinding tot het volledig uitvallen van een service. In deze situaties is het zinloos dat een toepassing voortdurend een bewerking opnieuw probeert uit te voeren die waarschijnlijk niet lukt.

Als u het nog erger wilt maken, kunt u met het uitvoeren van doorlopende bewerkingen voor nieuwe pogingen op een niet-responsieve service overschakelen naar een zelf opgelegd denial of service-scenario, waarbij u uw service overspoelt met doorlopende aanroepen, zoals geheugen, threads en databaseverbindingen, waardoor fouten optreden in niet-gerelateerde delen van het systeem die dezelfde resources gebruiken.

In deze situaties is het beter om de bewerking onmiddellijk uit te voeren en alleen de service aan te roepen als deze waarschijnlijk slaagt.

Het circuitonderbrekerpatroon kan voorkomen dat een toepassing herhaaldelijk probeert een bewerking uit te voeren die waarschijnlijk mislukt. Na een vooraf gedefinieerd aantal mislukte aanroepen wordt al het verkeer naar de service geblokkeerd. Periodiek kan een proefgesprek worden gestart om te bepalen of de fout is opgelost. Afbeelding 6-3 toont het circuitonderbrekerpatroon in actie.

Afbeelding 6-3. Circuitonderbrekerpatroon in actie

In de vorige afbeelding is een circuitonderbrekerpatroon toegevoegd aan het oorspronkelijke patroon voor opnieuw proberen. Houd er rekening mee dat na 100 mislukte aanvragen de circuitonderbrekers worden geopend en niet langer aanroepen naar de service worden toegestaan. De waarde CheckCircuit, ingesteld op 30 seconden, geeft aan hoe vaak de bibliotheek één aanvraag toestaat om door te gaan naar de service. Als deze aanroep slaagt, wordt het circuit gesloten en is de service weer beschikbaar voor verkeer.

Houd er rekening mee dat de intentie van het circuitonderbrekerpatroon verschilt van dat van het patroon Opnieuw proberen. Met het patroon Opnieuw proberen kan een toepassing een bewerking opnieuw proberen in de verwachting dat deze zal slagen. Het circuitonderbrekerpatroon voorkomt dat een toepassing een bewerking uitvoert die waarschijnlijk mislukt. Normaal gesproken combineert een toepassing deze twee patronen met behulp van het patroon Opnieuw proberen om een bewerking aan te roepen via een circuitonderbreker.

Testen op flexibiliteit

Testen voor tolerantie kan niet altijd op dezelfde manier worden uitgevoerd als u toepassingsfunctionaliteit test (door eenheidstests, integratietests enzovoort uit te voeren). In plaats daarvan moet u testen hoe de end-to-end-workload presteert onder foutomstandigheden, die alleen af en toe optreden. Bijvoorbeeld: fouten injecteren door vastgelopen processen, verlopen certificaten, afhankelijke services niet beschikbaar te maken, enzovoort. Frameworks zoals chaos-monkey kunnen worden gebruikt voor dergelijke chaostests.

Toepassingstolerantie is een must voor het verwerken van problematische aangevraagde bewerkingen. Maar het is maar de helft van het verhaal. Vervolgens behandelen we tolerantiefuncties die beschikbaar zijn in de Azure-cloud.

VorigeVolgende