Patroon Circuitonderbreker

Handel fouten af waarvoor een wisselende hoeveelheid tijd nodig is om van te herstellen bij het verbinden met een externe service of resource. Dit patroon kan de stabiliteit en tolerantie van een toepassing verbeteren.

Context en probleem

In een gedistribueerde omgeving kunnen aanroepen naar externe resources en services mislukken vanwege tijdelijke fouten, zoals trage netwerkverbindingen, time-outs of de resources die worden overgecommitteerd of tijdelijk niet beschikbaar zijn. Na een korte periode corrigeren deze fouten zich doorgaans zelf. Er moet een robuuste cloudtoepassing worden voorbereid om deze met behulp van een strategie, zoals het Patroon Opnieuw proberen, af te handelen.

Er kunnen zich echter ook situaties voordoen waarbij fouten het gevolg zijn van onverwachte gebeurtenissen en die kunnen veel meer tijd kosten 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 kan het zinloos zijn voor een toepassing om voortdurend een bewerking opnieuw uit te voeren die waarschijnlijk niet lukt. In plaats daarvan moet de toepassing snel accepteren dat de bewerking is mislukt en deze fout dienovereenkomstig afhandelen.

Als een service bezet is, kan een storing in een deel van het systeem bovendien leiden tot een opeenstapeling van storingen. Een bewerking die een service aanroept, kan bijvoorbeeld worden geconfigureerd om een time-out te implementeren en een foutbericht te beantwoorden als de service niet binnen deze periode reageert. Deze strategie kan er echter toe leiden dat veel gelijktijdige aanvragen voor dezelfde bewerking worden geblokkeerd totdat de time-outperiode verloopt. Deze geblokkeerde aanvragen kunnen kritische systeemresources bevatten, zoals geheugen, threads, databaseverbindingen enzovoort. Deze resources kunnen dus uitgeput raken, waardoor andere mogelijk niet-gerelateerde onderdelen van het systeem die dezelfde resources moeten gebruiken, mislukken. In deze situaties is het beter als de bewerking meteen mislukt en de service alleen aanroept als deze waarschijnlijk met succes wordt uitgevoerd. Het instellen van een kortere time-out kan helpen dit probleem op te lossen, maar de time-out mag niet zo kort zijn dat de bewerking meestal mislukt, zelfs als de aanvraag voor de service uiteindelijk zou slagen.

Oplossing

Het circuitonderbrekerpatroon kan voorkomen dat een toepassing herhaaldelijk probeert een bewerking uit te voeren die waarschijnlijk mislukt. Hierdoor gaat deze verder zonder te wachten tot de fout is hersteld of er CPU-cycli worden verspild terwijl er wordt vastgesteld dat de fout langdurig is. Met het patroon Circuitonderbreker kan een toepassing ook detecteren of de fout is opgelost. Als het probleem lijkt te zijn opgelost, kan de toepassing de bewerking proberen aan te roepen.

Het doel van het patroon Circuitonderbreker verschilt van het patroon Opnieuw proberen. Met het patroon Opnieuw proberen probeert een toepassing een bewerking opnieuw in de verwachting dat deze zal slagen. Met het patroon Circuitonderbreker wordt voorkomen dat een toepassing een bewerking uitvoert die waarschijnlijk zal mislukken. Een toepassing kan deze twee patronen combineren door het patroon Opnieuw proberen te gebruiken om een bewerking aan te roepen via een circuitonderbreker. De pogingslogica moet echter gevoelig zijn voor eventuele uitzonderingen die door de circuitonderbreker worden geretourneerd en moet nieuwe pogingen afbreken als de circuitonderbreker aangeeft dat een fout niet tijdelijk is.

Een circuitonderbreker fungeert als een proxy voor bewerkingen die kunnen mislukken. De proxy moet het aantal recente fouten controleren dat is opgetreden en deze informatie gebruiken om te bepalen of de bewerking moet worden voortgezet of dat er onmiddellijk een uitzondering wordt geretourneerd.

De proxy kan worden geïmplementeerd als een toestandsmachine met de volgende statussen die de functionaliteit van een elektrische circuitonderbreker nabootsen:

• Gesloten: de aanvraag van de toepassing wordt doorgestuurd naar de bewerking. De proxy houdt een telling bij van het aantal recente fouten en als de aanroep naar de bewerking mislukt, verhoogt de proxy dit aantal. Als het aantal recente fouten binnen een bepaalde tijdsperiode een opgegeven drempelwaarde overschrijdt, wordt de proxy in de status Open geplaatst. Op dit moment start de proxy een time-outtimer en wanneer deze timer verloopt, wordt de proxy in de status Halfopen geplaatst.

  Het doel van de time-outtimer is om het systeem tijd te geven om het probleem op te lossen dat de fout heeft veroorzaakt voordat de toepassing de bewerking opnieuw kan uitvoeren.

• Open: de aanvraag van de toepassing mislukt onmiddellijk en er wordt een uitzondering naar de toepassing geretourneerd.

• Halfopen: een beperkt aantal aanvragen van de toepassing mag worden doorgegeven en de bewerking aanroepen. Als deze aanvragen zijn geslaagd, wordt ervan uitgegaan dat de fout die eerder de storing heeft veroorzaakt, is opgelost en de circuitonderbreker schakelt naar de status Gesloten (de foutenteller wordt opnieuw ingesteld). Als een aanvraag mislukt, gaat de circuitonderbreker ervan uit dat de fout nog steeds aanwezig is, zodat deze teruggaat naar de status Openen en de time-outtimer opnieuw start om het systeem een verdere periode te geven om van de fout te herstellen.

  De status Halfopen is handig om te voorkomen dat een herstellende service plotseling wordt overspoeld met aanvragen. Als een service herstelt, kan het mogelijk een beperkt aantal aanvragen ondersteunen totdat het herstel is voltooid, maar terwijl het herstel wordt uitgevoerd, kan een stroom werk ertoe leiden dat de service een time-out optreedt of opnieuw mislukt.

De foutenteller die in de afbeelding wordt gebruikt door de status Gesloten is gebaseerd op tijd. Deze wordt periodiek automatisch opnieuw ingesteld. Dit ontwerp helpt voorkomen dat de circuitonderbreker de status Openen invoert als er af en toe storingen optreden. De foutdrempelwaarde waarbij de circuitonderbreker de status Open activeert, wordt alleen bereikt wanneer een opgegeven aantal fouten is opgetreden tijdens een opgegeven interval. De teller die door de status Halfopen wordt gebruikt, legt het aantal geslaagde pogingen om de bewerking aan te roepen vast. De circuitonderbreker keert terug naar de status Gesloten nadat een opgegeven aantal opeenvolgende bewerkingsaanroepen is geslaagd. Als een aanroep is mislukt, schakelt de circuitonderbreker onmiddellijk naar de status Open. De teller voor succes wordt opnieuw ingesteld wanneer er naar de status Halfopen wordt geschakeld.

Hoe het systeem herstelt, wordt extern afgehandeld, bijvoorbeeld door het herstellen of opnieuw starten van een mislukt onderdeel of het herstellen van een netwerkverbinding.

Het patroon Circuitonderbreker biedt stabiliteit terwijl het systeem van een fout herstelt en minimaliseert de gevolgen met betrekking tot prestaties. Het kan helpen om de reactietijd van het systeem te behouden door een aanvraag voor een bewerking die waarschijnlijk gaat mislukken snel te weigeren, in plaats van te wachten totdat er een time-out optreedt of de bewerking nooit terugkeert. Als de circuitonderbreker een gebeurtenis genereert telkens wanneer de status wijzigt, kan deze informatie worden gebruikt om de status van het onderdeel van het systeem dat door de circuitonderbreker wordt beveiligd te bewaken of om een beheerder te waarschuwen wanneer een circuitonderbreker naar de status Open schakelt.

Het patroon kan worden aangepast op basis van het type van de mogelijke fout. U kunt bijvoorbeeld een toenemende time-outtimer toepassen op een circuitonderbreker. U kunt de circuitonderbreker in de status openen plaatsen in eerste instantie en als de fout niet is opgelost, verhoogt u de time-out tot een paar minuten, enzovoort. In sommige gevallen kan het handig zijn om een standaardwaarde te retourneren die zinvol is voor de toepassing, in plaats van dat de status Open een fout retourneert en een uitzondering genereert.

Problemen en overwegingen

U moet de volgende punten overwegen wanneer u besluit hoe u dit patroon wilt implementeren:

uitzonderingsafhandeling: een toepassing die een bewerking aanroept via een circuitonderbreker, moet worden voorbereid om de uitzonderingen af te handelen die optreden als de bewerking niet beschikbaar is. De manier waarop uitzonderingen worden afgehandeld, is toepassingsspecifiek. Een toepassing kan bijvoorbeeld de functionaliteit tijdelijk verlagen, een alternatieve bewerking aanroepen om te proberen dezelfde taak uit te voeren of dezelfde gegevens te verkrijgen, of de uitzondering aan de gebruiker rapporteren en vragen het later opnieuw te proberen.

Typen uitzonderingen: een aanvraag kan om verschillende redenen mislukken, waarvan sommige kunnen duiden op een ernstiger type fout dan andere. Een aanvraag kan bijvoorbeeld mislukken omdat een externe service is vastgelopen en enkele minuten duurt om te herstellen, of vanwege een time-out omdat de service tijdelijk overbelast is. Een circuitonderbreker kan mogelijk de typen uitzonderingen die optreden onderzoeken en de strategie aanpassen afhankelijk van de aard van deze uitzonderingen. Het kan bijvoorbeeld een groter aantal time-outuitzonderingen vereisen om de circuitonderbreker naar de status Openen te laten gaan in vergelijking met het aantal storingen omdat de service volledig niet beschikbaar is.

Bewaking: een circuitonderbreker moet duidelijke waarneembaarheid bieden in zowel mislukte als geslaagde aanvragen, zodat operationele teams de systeemstatus kunnen beoordelen. Gedistribueerde tracering gebruiken voor end-to-end zichtbaarheid van services.

Herstelbaarheid: u moet de circuitonderbreker zo configureren dat deze overeenkomt met het waarschijnlijke herstelpatroon van de bewerking die wordt beveiligd. Als de circuitonderbreker bijvoorbeeld gedurende een lange periode in de status Open blijft, kan deze uitzonderingen genereren, zelfs als de oorzaak van het probleem is opgelost. Op dezelfde manier kan een circuitonderbreker variëren en de reactietijden van toepassingen verkorten als deze te snel van de status Open naar de status Halfopen schakelt.

Mislukte bewerkingen testen: in de status openen in plaats van een timer te gebruiken om te bepalen wanneer moet worden overgeschakeld naar de halfopen status, kan een circuitonderbreker de externe service of resource periodiek pingen om te bepalen of deze weer beschikbaar is. Deze ping kan de vorm hebben van een poging om een bewerking die eerder is mislukt aan te roepen of deze kan een speciale bewerking gebruiken die specifiek door de externe service wordt geleverd voor het testen van de status van de service, zoals is beschreven in Health Endpoint Monitoring pattern (Patroon Eindpuntstatusbewaking).

Handmatige onderdrukking: in een systeem waarin de hersteltijd voor een mislukte bewerking extreem variabel is, is het handig om een handmatige resetoptie te bieden waarmee een beheerder een circuitonderbreker kan sluiten (en de foutteller opnieuw kan instellen). Op dezelfde manier kan een beheerder een circuitonderbreker forceren in de status Openen (en de time-outtimer opnieuw starten) als de bewerking die wordt beveiligd door de circuitonderbreker tijdelijk niet beschikbaar is.

gelijktijdigheid: dezelfde circuitonderbreker kan worden geopend door een groot aantal gelijktijdige exemplaren van een toepassing. De implementatie mag gelijktijdige aanvragen niet blokkeren of overmatige overhead toevoegen aan elke aanroep naar een bewerking.

Resource-differentiatie: wees voorzichtig bij het gebruik van één circuitonderbreker voor één type resource als er mogelijk meerdere onderliggende onafhankelijke providers zijn. In een gegevensopslag met meerdere shards kan bijvoorbeeld één shard volledig toegankelijk zijn terwijl een andere een tijdelijk probleem ondervindt. Als de foutberichten in deze scenario's worden samengevoegd, kan een toepassing toegang proberen te krijgen tot sommige shards zelfs wanneer dit zeer waarschijnlijk gaat mislukken, terwijl de toegang tot andere shards mogelijk is geblokkeerd zelfs als dit waarschijnlijk met succes wordt uitgevoerd.

versneld circuitonderbreking: soms kan een foutreactie voldoende informatie bevatten voor de circuitonderbreker om onmiddellijk te reizen en gedurende een minimale tijd te blijven. Het foutbericht van een gedeelde resource die is overbelast kan er bijvoorbeeld op duiden dat een directe nieuwe poging niet wordt aanbevolen en dat de toepassing het over enkele minuten opnieuw moet proberen.

implementaties voor meerdere regio's: een circuitonderbreker kan worden ontworpen voor implementaties met één of meerdere regio's. De laatste kan worden geïmplementeerd met behulp van wereldwijde load balancers of aangepaste regiobewuste circuitonderbrekingsstrategieën die zorgen voor beheerde failover, latentieoptimalisatie en naleving van regelgeving.

Service mesh circuitonderbrekers: circuitonderbrekers kunnen worden geïmplementeerd op de toepassingslaag of als een geabstraheerde, geabstraheerde functie. Service-meshes ondersteunen bijvoorbeeld vaak circuitonderbrekingen als een sidecar of als zelfstandige mogelijkheid zonder toepassingscode te wijzigen.

Mislukte aanvragen opnieuw afspelen: in de status Openen, in plaats van dat ze snel mislukken, kan een circuitonderbreker ook de details van elke aanvraag in een logboek vastleggen en ervoor zorgen dat deze aanvragen opnieuw worden afgespeeld wanneer de externe resource of service beschikbaar wordt.

Ongepaste time-outs voor externe services: een circuitonderbreker kan toepassingen mogelijk niet volledig beveiligen tegen bewerkingen die mislukken in externe services die zijn geconfigureerd met een lange time-outperiode. Als de time-out te lang is, kan een thread waarop een circuitonderbreker wordt uitgevoerd gedurende een langere periode worden geblokkeerd voordat de circuitonderbreker aangeeft dat de bewerking is mislukt. Gedurende deze tijd kunnen ook veel andere exemplaren van de toepassing de service proberen aan te roepen via de circuitonderbreker en een groot aantal threads bezighouden voordat ze allemaal mislukken.

Aanpassingsvermogen voor het berekenen van de diversificatie: circuitonderbrekers moeten rekening houden met verschillende rekenomgevingen, van serverloze tot containerworkloads, waarbij factoren zoals koude start- en schaalbaarheidsfouten verwerken. Adaptieve benaderingen kunnen strategieën dynamisch aanpassen op basis van het rekentype, waardoor tolerantie in heterogene architecturen wordt gegarandeerd.

Wanneer dit patroon gebruiken

U gebruikt dit patroon voor het volgende:

• Om trapsgewijze fouten te voorkomen door overmatige aanroepen door een externe service of toegangsaanvragen voor een gedeelde resource te stoppen als deze bewerkingen hoogstwaarschijnlijk mislukken.
• Om de tolerantie voor meerdere regio's te verbeteren door verkeer intelligent te routeren op basis van realtime foutsignalen.
• Om te beschermen tegen trage afhankelijkheden, helpt u uw serviceniveaudoelstellingen (SLO's) bij te houden en prestatievermindering te voorkomen vanwege services met hoge latentie.
• Om onregelmatige connectiviteitsproblemen af te handelen en aanvraagfouten in gedistribueerde omgevingen te verminderen.

Dit patroon wordt niet aanbevolen voor het volgende:

• Voor het verwerken van toegang tot lokale privébronnen in een toepassing, zoals een gegevensstructuur in het geheugen. In deze omgeving voegt het gebruik van een circuitonderbreker overhead toe aan uw systeem.
• Als alternatief voor het afhandelen van uitzonderingen in de bedrijfslogica van uw toepassingen.
• Wanneer bekende algoritmen voor opnieuw proberen voldoende zijn en uw afhankelijkheden zijn ontworpen om te kunnen omgaan met mechanismen voor opnieuw proberen. Het implementeren van een circuitonderbreker in uw toepassing in dit geval kan onnodige complexiteit aan uw systeem toevoegen.
• Wanneer u wacht tot een circuitonderbreker opnieuw wordt ingesteld, kan dit leiden tot onaanvaardbare vertragingen.
• Als u een berichtgestuurde of gebeurtenisgestuurde architectuur hebt, omdat ze vaak mislukte berichten routeren naar een wachtrij met dode letters (DLQ) voor handmatige of uitgestelde verwerking. De ingebouwde isolatie van fouten en mechanismen voor opnieuw proberen die doorgaans in deze ontwerpen worden geïmplementeerd, zijn vaak voldoende.
• Als herstel na fouten wordt beheerd op het niveau van de infrastructuur of het platform, zoals met statuscontroles in globale load balancers of service-meshes, zijn circuitonderbrekers mogelijk niet nodig.

Workloadontwerp

Een architect moet evalueren hoe het circuitonderbrekerpatroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Voorbeeld

In dit voorbeeld ziet u het circuitonderbrekerpatroon dat is geïmplementeerd om te voorkomen dat de quotumoverschrijding wordt overschreden met behulp van de gratis laag van Azure Cosmos DB. Deze laag wordt voornamelijk gebruikt voor niet-kritieke gegevens. De doorvoer wordt bepaald door een capaciteitsplan dat een toegewezen quotum van resource-eenheden per seconde inricht. Tijdens seizoensgebonden gebeurtenissen kan de vraag de opgegeven capaciteit overschrijden, wat resulteert in 429 (Te veel aanvragen) antwoorden.

Wanneer er pieken in de vraag optreden, Azure Monitor-waarschuwingen met dynamische drempelwaarden detecteert en proactief de operationele en beheerteams waarschuwt die aangeven dat het schalen van de databasecapaciteit vereist kan zijn. Tegelijkertijd is een circuitonderbreker, afgestemd met behulp van historische foutpatronen, ritten om trapsgewijze fouten te voorkomen. In deze status wordt de toepassing probleemloos gedegradeerd door standaard- of in de cache opgeslagen antwoorden te retourneren, waarbij gebruikers worden geïnformeerd over de tijdelijke niet-beschikbaarheid van bepaalde gegevens, terwijl de algehele systeemstabiliteit behouden blijft.

Deze strategie verbetert de tolerantie die is afgestemd op zakelijke redenen. Door capaciteitspieken te beheren, kan het workloadteam opzettelijk kostenverhogingen beheren en wordt de servicekwaliteit gehandhaafd zonder onverwachte bedrijfskosten te verhogen. Zodra de vraag afneemt of de capaciteit is verhoogd, wordt de circuitonderbreker opnieuw ingesteld en wordt de toepassing teruggezet naar volledige functionaliteit in overeenstemming met zowel technische als budgettaire doelstellingen.

Stroom A - Gesloten status

1. Het systeem werkt normaal en alle aanvragen bereiken de database zonder 429 HTTP-antwoorden (Te veel aanvragen) te retourneren.
2. De circuitonderbreker blijft gesloten en er zijn geen standaard- of in de cache opgeslagen antwoorden nodig.

Stroom B - Status openen

1. Na ontvangst van het eerste 429 antwoord wordt de circuitonderbreker naar een open status geroepen.
2. Volgende aanvragen worden onmiddellijk kortsluiting, retourneren standaard- of in de cache opgeslagen antwoorden terwijl gebruikers worden geïnformeerd over tijdelijke afname en de toepassing wordt beschermd tegen verdere overbelasting.
3. Logboeken en telemetriegegevens worden vastgelegd en verzonden naar Azure Monitor om te worden geëvalueerd op basis van dynamische drempelwaarden. Er wordt een waarschuwing geactiveerd als aan de voorwaarden van de waarschuwingsregel wordt voldaan.
4. Een actiegroep meldt proactief het operationele team van de overbelastingsvoorwaarde.
5. Na goedkeuring van het workloadteam kan het operations-team de ingerichte doorvoer verhogen om overbelasting te verlichten, of kan het schalen vertragen als de belasting van nature afneemt.

Stroom C - Halfopen status

1. Na een vooraf gedefinieerde time-out voert de circuitonderbreker een halfopen status in, waardoor een beperkt aantal proefaanvragen is toegestaan.
2. Als deze proefaanvragen slagen zonder 429 antwoorden te retourneren, wordt de onderbreking opnieuw ingesteld op een gesloten status en worden normale bewerkingen teruggezet naar Flow A. Als fouten zich blijven voordoen, wordt de status geopend, namelijk Stroom B.

Ontwerpen

• Azure App Services- als host fungeert voor de webtoepassing die fungeert als het primaire toegangspunt voor clientaanvragen. De toepassingscode implementeert de logica die beleid voor circuitonderbrekers afdwingt en levert standaard- of in de cache opgeslagen antwoorden wanneer het circuit is geopend. Deze architectuur voorkomt overbelasting op downstreamsystemen en zorgt ervoor dat de gebruikerservaring wordt gehandhaafd tijdens piekvraag of storingen.
• Azure Cosmos DB- is een van de gegevensarchieven van de toepassing. Het dient niet-kritieke gegevens met behulp van de gratis laag. De gratis laag wordt het beste gebruikt voor het uitvoeren van kleine productieworkloads. Het circuitonderbrekermechanisme helpt het verkeer naar de database te beperken tijdens perioden van hoge vraag.
• Azure Monitor fungeert als gecentraliseerde bewakingsoplossing, waarbij alle activiteitenlogboeken worden samengevoegd om een uitgebreide end-to-end waarneembaarheid te garanderen. Logboeken en telemetriegegevens van Azure App Services en belangrijke metrische gegevens van Azure Cosmos DB (zoals het aantal 429 antwoorden) worden verzonden naar Azure Monitor voor aggregatie en analyse.
• Azure Monitor-waarschuwingen waarschuwingsregels afwegen tegen dynamische drempelwaarden mogelijke storingen te identificeren op basis van historische gegevens. Vooraf gedefinieerde waarschuwingen melden het operationele team wanneer drempelwaarden worden overschreden. Het kan voorkomen dat het workloadteam de toename van de ingerichte doorvoer goedkeurt, maar het operations-team verwacht dat het systeem zelfstandig zal herstellen, omdat de belasting niet te hoog is. In deze gevallen is de time-out van de circuitonderbreker natuurlijk verstreken. Als de 429 antwoorden gedurende deze periode niet meer worden uitgevoerd, detecteert de drempelwaardeberekening de langdurige storingen en sluit deze uit van het leeralgoritmen. Als gevolg hiervan wacht de volgende keer dat een overbelasting optreedt, de drempelwaarde wacht op een hoger foutpercentage in Azure Cosmos DB en wordt de melding vertraagd. Met deze wijziging kan de circuitonderbreker het probleem afhandelen zonder onmiddellijke waarschuwing en worden efficiëntie in kosten en operationele lasten gerealiseerd.

Verwante resources

De volgende patronen zijn mogelijk ook nuttig bij de implementatie van dit patroon:

• Betrouwbaar web-app-patroon laat zien hoe u het circuitonderbrekerpatroon kunt toepassen op webtoepassingen die in de cloud worden samengevoegd.

• Retry-patroon. Beschrijft hoe een toepassing verwachte, tijdelijke fouten kan afhandelen als er wordt geprobeerd om verbinding te maken met een service of netwerkresource door een bewerking die eerder is mislukt, transparant opnieuw te proberen.

• Patroon Statuseindpuntbewaking. Een circuitonderbreker kan mogelijk de status van een service testen door een aanvraag naar een eindpunt te verzenden die door de service wordt weergegeven. De service moet informatie retourneren die de status aangeeft.