Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Alle toepassingen die communiceren met externe services en resources moeten tijdelijke fouten detecteren en herstellen. Deze vereiste geldt met name voor toepassingen die worden uitgevoerd in de cloud. Vanwege de aard van de cloudomgeving en connectiviteit via internet, ondervindt uw toepassing waarschijnlijk vaker tijdelijke fouten. Tijdelijke fouten omvatten het tijdelijke verlies van netwerkconnectiviteit met onderdelen en services, de tijdelijke onbeschikbaarheid van een service en time-outs die optreden wanneer een service bezet is. Deze fouten lossen zichzelf meestal op zonder tussenkomst, dus de actie slaagt waarschijnlijk als de toepassing deze na een geschikte vertraging opnieuw probeert uit te voeren.
Tijdelijke foutafhandeling is een belangrijke tolerantietechniek binnen de pijler Betrouwbaarheid van het Azure Well-Architected Framework. Als u tijdelijke fouten op toepassingsniveau detecteert en herstelt, kunt u trapsgewijze fouten voorkomen die bredere procedures voor incidentrespons of herstel na noodgevallen kunnen activeren. Effectieve tijdelijke foutafhandeling helpt uw workload routineonderbrekingen te verdragen en beschikbaarheid te behouden zonder escalatie naar herstelprocedures op infrastructuurniveau.
Waarom treden tijdelijke fouten op in de cloud?
Tijdelijke fouten kunnen optreden in elke omgeving, op elk platform of besturingssysteem en in elk type toepassing. Voor oplossingen die on-premises infrastructuur worden uitgevoerd, onderhoudt redundante hardware doorgaans de prestaties en beschikbaarheid van de toepassing en de bijbehorende onderdelen. Onderdelen en resources bevinden zich ook dicht bij elkaar. Deze aanpak maakt fouten minder waarschijnlijk, maar tijdelijke fouten kunnen nog steeds optreden. Onverwachte gebeurtenissen, zoals externe voeding of netwerkproblemen, of andere noodscenario's, kunnen storingen veroorzaken. Redundante hardware kan ook duur zijn en wordt vaak onderbenut.
Cloudomgevingen kunnen een hogere algemene beschikbaarheid bieden, omdat ze workloads over veel servers verdelen en redundantie, automatische failover en dynamische resourcetoewijzing gebruiken. Maar de aard van cloudomgevingen maakt tijdelijke fouten waarschijnlijker om verschillende redenen:
Veel resources in een cloudomgeving worden gedeeld en toegang tot deze resources is onderhevig aan beperking om de resources te beveiligen. Sommige services weigeren verbindingen wanneer de belasting een specifiek niveau of een maximale doorvoersnelheid bereikt. Met deze methode kan de service bestaande aanvragen verwerken en de prestaties voor alle gebruikers behouden. Bandbreedtebeperking helpt de kwaliteit van de service te behouden voor buren en andere huurders die gebruikmaken van de gedeelde bron.
Cloudomgevingen maken gebruik van grote aantallen basishardware-eenheden. Ze leveren prestaties door de belasting dynamisch te verdelen over meerdere rekeneenheden en infrastructuuronderdelen. Ze leveren betrouwbaarheid door mislukte eenheden automatisch te recyclen of te vervangen. Vanwege deze dynamische aard kunnen tijdelijke fouten en tijdelijke verbindingsfouten af en toe optreden.
Meer hardwareonderdelen, waaronder netwerkinfrastructuur zoals routers en load balancers, bestaan vaak tussen de toepassing en de resources en services die worden gebruikt. Deze infrastructuur kan af en toe extra verbindingslatentie en tijdelijke verbindingsfouten veroorzaken.
Netwerkomstandigheden tussen de client en server verschillen vaak, met name wanneer communicatie via internet plaatsvindt. Zelfs op on-premises locaties kunnen zware verkeersbelastingen de communicatie vertragen en onregelmatige verbindingsfouten veroorzaken.
Uitdagingen
Tijdelijke fouten kunnen van invloed zijn op de waargenomen beschikbaarheid van een toepassing, zelfs als u deze grondig test onder verwachte omstandigheden. Om ervoor te zorgen dat cloudtoepassingen betrouwbaar werken, moeten ze de volgende uitdagingen aanpakken:
De toepassing moet fouten kunnen detecteren wanneer ze optreden en bepalen of de fouten tijdelijk, langdurig of terminalfouten zijn. Verschillende resources retourneren doorgaans verschillende antwoorden wanneer er een fout optreedt. Deze antwoorden kunnen ook variëren, afhankelijk van de context van de bewerking. Het antwoord op een fout wanneer de toepassing leest uit de opslag, kan bijvoorbeeld verschillen van het antwoord op een fout wanneer deze naar de opslag schrijft.
Veel middelen en diensten hebben goed gedocumenteerde contracten met betrekking tot kortdurende storingen. Wanneer deze informatie niet beschikbaar is, wordt het moeilijker om de aard van de fout te bepalen en of deze waarschijnlijk tijdelijk is.
De toepassing moet de bewerking opnieuw kunnen uitvoeren als wordt vastgesteld dat de fout waarschijnlijk tijdelijk is. Het moet ook het aantal keren bijhouden dat de bewerking opnieuw wordt uitgevoerd.
De toepassing moet een strategie voor opnieuw proberen gebruiken die aan de vereisten voldoet. De strategie geeft aan hoe vaak de toepassing het opnieuw moet proberen, de vertraging tussen pogingen en de acties die moeten worden uitgevoerd na een mislukte poging. Het aantal pogingen en de vertraging tussen elke poging zijn vaak moeilijk te bepalen. De strategie is afhankelijk van het type resource en de huidige operationele omstandigheden van de resource en de toepassing.
Algemene richtlijnen
De volgende richtlijnen kunnen u helpen bij het ontwerpen van geschikte tijdelijke foutafhandelingsmechanismen voor uw toepassingen.
Controleer of er een ingebouwd mechanisme voor opnieuw proberen bestaat
Veel services bieden een SDK of clientbibliotheek die een tijdelijk mechanisme voor foutafhandeling bevat. Het beleid voor opnieuw proberen dat wordt gebruikt, is doorgaans afgestemd op de aard en vereisten van de doelservice. Rest-interfaces voor services kunnen ook informatie retourneren die u kan helpen bepalen of een nieuwe poging nodig is en hoe lang moet worden gewacht voordat de volgende poging wordt uitgevoerd.
Gebruik het ingebouwde mechanisme voor opnieuw proberen wanneer er een ingebouwde optie beschikbaar is, tenzij u specifieke en goed begrepen vereisten hebt die een ander gedrag voor opnieuw proberen geschikter maken voor uw scenario.
Azure-services verwerken allemaal tijdelijke fouten anders. Sommige services bieden beleid voor opnieuw proberen op SDK-niveau met configureerbare back-off-algoritmen. Andere services bieden platformfuncties zoals statustests en zichtbaarheidstime-outs die een aanvulling vormen op logica voor opnieuw proberen op toepassingsniveau. Raadpleeg de betrouwbaarheidshandleiding voor elke Azure-service die u gebruikt. Deze handleidingen bevatten een speciale sectie die servicespecifieke aanbevelingen biedt voor het opnieuw proberen van configuratie, time-outafstemming en statuscontrole.
Controleer of het opnieuw proberen past bij de bewerking
Voer taken alleen opnieuw uit wanneer de fouten tijdelijk zijn, wat de aard van de fout meestal aangeeft en wanneer de bewerking kan slagen wanneer het opnieuw wordt geprobeerd. Voor HTTP-services zijn statuscode 429 (Te veel aanvragen) en 5xx-serverfouten typische kandidaten voor nieuwe pogingen. De meeste 4xx-clientfouten, zoals 400, 401, 403 en 404, geven problemen aan die niet worden opgelost door een nieuwe poging. Voer geen nieuwe pogingen uit die niet kunnen slagen, zoals het bijwerken van een database-item dat niet bestaat of een service aanroept die een fatale fout heeft geretourneerd.
Implementeer over het algemeen alleen nieuwe pogingen wanneer u het volledige effect ervan kunt bepalen en wanneer u de voorwaarden begrijpt en valideert. In dat geval kunt u de aanroepende code de nieuwe pogingen laten implementeren. Fouten die worden geretourneerd door resources en services buiten uw controle, kunnen zich na verloop van tijd ontwikkelen en u moet mogelijk uw logica voor tijdelijke foutdetectie opnieuw bekijken.
Wanneer u services of onderdelen maakt, implementeert u foutcodes en berichten waarmee clients kunnen bepalen of ze mislukte bewerkingen opnieuw moeten proberen. Retourneer bijvoorbeeld een isTransient waarde om aan te geven of de client de bewerking opnieuw moet uitvoeren en stel een geschikte vertraging voor de volgende poging voor. Als u een webservice bouwt, geeft u aangepaste fouten terug die uw servicecontracten definiëren. Algemene clients kunnen deze fouten mogelijk niet lezen, maar ze zijn handig wanneer u aangepaste clients maakt.
Bepaal het juiste aantal nieuwe pogingen en het juiste interval
Optimaliseer het aantal nieuwe pogingen en het interval voor het type use case. Als u niet genoeg opnieuw probeert, kan de toepassing de bewerking niet voltooien en mislukt. Als u het te vaak opnieuw probeert of niet lang genoeg wacht tussen pogingen, bevat de toepassing mogelijk resources zoals threads, verbindingen en geheugen voor lange perioden, wat de toepassingsstatus nadelig beïnvloedt. Zie Herhaalpatroon voor meer informatie.
Pas de waarden voor het tijdsinterval en het aantal nieuwe pogingen aan op basis van het type bewerking. Als de bewerking bijvoorbeeld deel uitmaakt van een gebruikersinteractie, moet het interval kort zijn en moet u slechts een paar nieuwe pogingen proberen. Gebruik deze methode om te voorkomen dat gebruikers wachten op een reactie, die open verbindingen bevat en de beschikbaarheid voor andere gebruikers kan verminderen. Als de bewerking deel uitmaakt van een langlopende of kritieke werkstroom, waarbij het annuleren en opnieuw starten van het proces kostbaar of tijdrovend is, kunt u langer wachten tussen pogingen en meer keren opnieuw proberen.
Het bepalen van de juiste intervallen tussen nieuwe pogingen is het moeilijkste deel van het ontwerpen van een succesvolle strategie. Typische strategieën gebruiken de volgende typen interval voor opnieuw proberen:
Exponentiële back-off: De toepassing wacht even voordat de eerste nieuwe poging plaatsvindt en verlengt vervolgens de tijd tussen elke volgende poging exponentieel. Het kan bijvoorbeeld opnieuw proberen om de bewerking na twee seconden, vier seconden, acht seconden en maximaal een bepaald aantal pogingen of een totale duur opnieuw uit te voeren. Voeg jitter, wat een kleine willekeurige vertraging is, toe aan elk interval voor hernieuwde pogingen om te voorkomen dat meerdere clients hun pogingen synchroniseren en belastingpieken bij de doelservice veroorzaken.
Incrementele intervallen: De toepassing wacht even voordat de eerste nieuwe poging is uitgevoerd en verhoogt vervolgens stapsgewijs de tijd tussen elke volgende nieuwe poging. De bewerking kan bijvoorbeeld na 3 seconden, 7 seconden en 11 seconden opnieuw worden uitgevoerd.
Regelmatige intervallen: De toepassing wacht op dezelfde periode tussen elke poging. De bewerking kan bijvoorbeeld elke drie seconden opnieuw worden uitgevoerd.
Onmiddellijk opnieuw proberen: Tijdelijke fouten die gebeurtenissen zoals een netwerkpakketconflict of een piek in een hardwareonderdeel veroorzaken, zijn doorgaans kort. In deze scenario's kan het opnieuw proberen van de bewerking direct helpen, omdat deze kan slagen als de fout wordt gewist in de tijd die de toepassing nodig heeft om de volgende aanvraag te verzamelen en te verzenden. Probeer niet meer dan één onmiddellijke nieuwe poging. Als de onmiddellijke nieuwe poging mislukt, schakelt u over naar alternatieve strategieën, zoals exponentieel uitstel of terugvalacties.
Randomisatie: Een van de eerder vermelde strategieën voor opnieuw proberen kan randomisatie bevatten om te voorkomen dat meerdere exemplaren van de client volgende nieuwe pogingen tegelijkertijd verzenden. Een exemplaar kan bijvoorbeeld de bewerking na 3 seconden, 11 seconden of 28 seconden opnieuw proberen, terwijl een ander exemplaar de bewerking na 4 seconden, 12 seconden of 26 seconden opnieuw kan proberen. Randomisatie is een handige techniek die u kunt combineren met andere strategieën.
Gebruik een exponentiële back-off-strategie met jitter voor achtergrondbewerkingen en voor interactieve bewerkingen gebruik onmiddellijke herhalingsstrategieën of strategieën met regelmatige intervallen. Kies in beide gevallen de vertraging en het aantal nieuwe pogingen, zodat de maximale latentie voor alle nieuwe pogingen voldoet aan de end-to-end latentievereiste.
Een combinatie van factoren draagt bij aan de totale maximale time-out voor een nieuwe bewerking. Houd rekening met de volgende factoren:
De tijd die een mislukte verbinding nodig heeft om een antwoord te produceren. Een time-outwaarde in de client stelt deze tijd doorgaans in.
De vertraging tussen nieuwe pogingen.
Het maximum aantal nieuwe pogingen.
Het totaal van deze tijden kan leiden tot lange algemene bewerkingstijden, met name wanneer u een exponentiële vertragingsstrategie gebruikt waarbij het interval tussen nieuwe pogingen na elke fout snel toeneemt. Als een proces moet voldoen aan een specifieke serviceniveaudoelstelling (SLO), moet de totale bewerkingstijd, inclusief alle time-outs en vertragingen, binnen de limieten vallen die zijn gedefinieerd in de SLO.
Houd rekening met de time-out van de bewerkingen wanneer u intervallen voor opnieuw proberen kiest om te voorkomen dat een volgende poging onmiddellijk wordt gestart, bijvoorbeeld als de time-outperiode vergelijkbaar is met het interval voor opnieuw proberen. Bepaal of u de totale mogelijke periode wilt behouden. Dit is de time-out plus de intervallen voor opnieuw proberen, onder een specifieke drempelwaarde voor de totale tijd. Als een bewerking een ongebruikelijk korte of lange time-out heeft, kan de time-out van invloed zijn op hoe lang moet worden gewacht en hoe vaak de bewerking opnieuw moet worden uitgevoerd.
Stel time-outs in voor elke uitgaande aanroep voordat u logica voor opnieuw proberen implementeert. Time-outs, nieuwe pogingen en terugtrekbenaderingen werken samen. Een strategie voor opnieuw proberen is slechts zo effectief als de time-outs die elke afzonderlijke poging bepalen. Time-outs die te lang zijn, leiden ertoe dat threads en verbindingen zich opstapelen tijdens storingen. Te korte time-outs veroorzaken vervroegde fouten bij operaties die anders zouden slagen.
Implementeer geen te agressieve strategieën voor opnieuw proberen. Deze strategieën gebruiken intervallen die te kort zijn of nieuwe pogingen die te vaak optreden. Ze kunnen de doelresource of -service nadelig beïnvloeden. Ze kunnen ook voorkomen dat de resource of service wordt hersteld, zodat de resource of service aanvragen blijft blokkeren of weigeren. In dit scenario wordt een cyclus gemaakt waarin de toepassing meer aanvragen naar de resource of service verzendt, waardoor de mogelijkheid om te herstellen verder wordt verminderd.
Gebruik het uitzonderingstype en de gegevens die deze bevatten, of de foutcodes en berichten die de service retourneert, om het aantal nieuwe pogingen en het interval ertussen te optimaliseren. Sommige uitzonderingen of foutcodes, zoals HTTP 503 (service niet beschikbaar), kunnen erop wijzen dat de service is mislukt en niet reageert op verdere pogingen. Wanneer een antwoord een Retry-After header bevat, volgt u deze en wacht u ten minste de opgegeven duur voor de volgende poging. Dit door de server geleverde signaal weerspiegelt de hersteltijdlijn van de service en heeft voorrang op de back-offberekening aan de clientzijde.
Gebruik een wachtrij met dode letters , zodat de gegevens van de binnenkomende aanvraag niet verloren gaan nadat u alle nieuwe pogingen hebt gebruikt. Met deze techniek wordt mislukt werk uitgesteld voor latere verwerking in plaats van deze te verwijderen.
Vermijd antipatronen
Vermijd in de meeste gevallen implementaties die dubbele lagen van code voor opnieuw proberen bevatten. Vermijd ontwerpen die trapsgewijze mechanismen voor opnieuw proberen gebruiken of die nieuwe pogingen toepassen in elke fase van een bewerking waarbij een hiërarchie van aanvragen is betrokken, tenzij u specifieke vereisten hebt. Gebruik in deze uitzonderlijke gevallen beleidsregels die het aantal nieuwe pogingen en vertragingsperioden beperken en zorg ervoor dat u de gevolgen begrijpt.
Denk bijvoorbeeld aan een onderdeel dat een aanvraag indient naar een ander onderdeel, dat vervolgens toegang krijgt tot de doelservice. Een herhaling met een aantal van drie voor beide oproepen resulteert in totaal in negen herhaalde pogingen tegen de service.
Veel services en resources implementeren een ingebouwd mechanisme voor opnieuw proberen. Schakel deze mechanismen uit of wijzig deze als u nieuwe pogingen op een hoger niveau wilt implementeren. Zie Antipatroon van Storm opnieuw proberen voor meer informatie over de risico's van niet-gecoördineerde nieuwe pogingen.
Implementeer nooit een eindeloos mechanisme voor opnieuw proberen. ** Deze aanpak voorkomt doorgaans dat de resource of service herstelt van een situatie van overbelasting en zorgt ervoor dat throttling en geweigerde verbindingen langer doorgaan. Gebruik een beperkt aantal nieuwe pogingen of implementeer een patroon zoals circuitonderbreker om de service te laten herstellen.
Implementeer een budget voor opnieuw proberen om het totale aantal nieuwe pogingen voor alle aanvragen binnen een proces of service te beperken, naast limieten voor elke afzonderlijke aanvraag. U kunt bijvoorbeeld toestaan dat een proces maximaal 60 nieuwe pogingen per minuut uitvoert op basis van een opgegeven afhankelijkheid. Als u het budget uitput, mislukt u de aanvraag onmiddellijk in plaats van opnieuw te proberen.
Alleen limieten voor herhaalpogingen per aanvraag kunnen geen scenario voorkomen waarbij veel gelijktijdige aanvragen enkele keren proberen en gezamenlijk een overbelaste downstreamservice overweldigen. Een budget voor opnieuw proberen beperkt de cumulatieve belasting voor opnieuw proberen en kan het verschil maken tussen een gelokaliseerd capaciteitsprobleem en een trapsgewijze fout.
Probeer het nooit meer dan één keer opnieuw.
Vermijd het gebruik van een regelmatig interval voor opnieuw proberen wanneer u toegang hebt tot services en resources in Azure, met name wanneer u een groot aantal nieuwe pogingen hebt. De beste aanpak in dit scenario is een exponentiële back-off-strategie die gebruikmaakt van een circuitonderbrekingsmogelijkheid.
Voorkomen dat meerdere exemplaren van dezelfde client of meerdere exemplaren van verschillende clients tegelijkertijd nieuwe pogingen verzenden. Als dit scenario waarschijnlijk is, introduceert u randomisatie in de intervallen voor opnieuw proberen.
Test uw strategie en implementatie voor het opnieuw proberen
Test uw strategie voor opnieuw proberen in een breed scala aan voorwaarden, met name wanneer de toepassing en de doelresources of -services onder extreme belasting werken. Als u het gedrag tijdens het testen wilt controleren, kunt u de volgende acties uitvoeren:
Neem tijdelijke fouten op in uw chaos-engineering- en foutinjectieprocedures door ze bewust in te voeren in uw niet-productie- en productie-omgevingen. Verzend bijvoorbeeld niet-ondersteunde aanvragen of voeg code toe die testaanvragen detecteert en reageert met verschillende typen fouten.
Maak een simulatieversie van de resource of service die diverse fouten retourneert die de echte service zou kunnen retourneren. Zorg ervoor dat hierin alle fouttypen worden behandeld die door uw strategie voor opnieuw proberen worden gedetecteerd.
Voor aangepaste services die u maakt en implementeert, dwingt u tijdelijke storingen af door de service tijdelijk offline te halen of de service te overbelasten. Probeer geen gedeelde resources of gedeelde services in Azure te overbelasten.
Overweeg het gebruik van een service voor foutinjectie om gecontroleerde experimenten uit te voeren op uw Azure-resources. Azure Chaos Studio ondersteunt bijvoorbeeld service-directe fouten, zoals het toevoegen van netwerklatentie of het opnieuw opstarten van een cachecluster, en op agents gebaseerde fouten, zoals het toepassen van geheugendruk of het beëindigen van een proces op een virtuele machine (VM). U kunt experimenten voor foutinjectie integreren in uw CI/CD-pijplijnen (continue integratie en continue levering) om continu tolerantie te valideren als onderdeel van uw implementatieproces.
Voor HTTP-API's kunt u overwegen om een bibliotheek in uw geautomatiseerde tests te gebruiken om het resultaat van HTTP-aanvragen te wijzigen, door extra retourtijden toe te voegen of door het antwoord te wijzigen, zoals de HTTP-statuscode, headers, hoofdteksten of andere factoren. Met deze aanpak kunt u een subset van de foutvoorwaarden voor tijdelijke fouten en andere typen fouten deterministisch testen.
Voer tests met een hoge belasting en concurrerende tests uit om ervoor te zorgen dat het opnieuw probeermechanisme en de -strategie correct werken onder deze omstandigheden. Deze tests helpen ook te bevestigen dat nieuwe pogingen geen invloed hebben op clientbewerkingen of kruisbesmetting tussen aanvragen veroorzaken.
Beleidsconfiguraties voor opnieuw proberen beheren
Een beleid voor opnieuw proberen is een combinatie van alle elementen van uw strategie voor opnieuw proberen. Het definieert het detectiemechanisme dat de volgende factoren bepaalt:
- Of een fout waarschijnlijk tijdelijk is
- Het type interval dat moet worden gebruikt, zoals regelmatige, exponentiële back-off of randomisatie
- De werkelijke intervalwaarden
- Het aantal keren dat u het opnieuw moet proberen
Implementeer nieuwe pogingen op veel plaatsen, waaronder in basistoepassingen en op elke laag van complexere toepassingen. Gebruik in plaats van hardcoderingsbeleidselementen op meerdere locaties een centraal punt om alle beleidsregels op te slaan. Sla bijvoorbeeld waarden op zoals het interval en het aantal nieuwe pogingen in toepassingsconfiguratiebestanden, lees ze tijdens runtime en bouw programmatisch het beleid voor opnieuw proberen. Deze aanpak vereenvoudigt het beheer van instellingen en het wijzigen en verfijnen van waarden om te reageren op veranderende vereisten en scenario's. Ontwerp het systeem om de waarden op te slaan in plaats van een configuratiebestand opnieuw te lezen voor elke aanvraag en gebruik geschikte standaardwaarden als de configuratie de waarden niet opgeeft.
Sla de waarden op die worden gebruikt voor het bouwen van het beleid voor opnieuw proberen tijdens runtime in het configuratiesysteem van de toepassing, zodat u deze kunt wijzigen zonder dat u de toepassing opnieuw hoeft te starten.
Profiteer van ingebouwde of standaardstrategieën voor opnieuw proberen die beschikbaar zijn in de client-API's die u gebruikt, maar alleen wanneer ze geschikt zijn voor uw scenario. Deze strategieën zijn doorgaans algemeen. Ze kunnen in sommige scenario's voldoende zijn, maar in andere scenario's bieden ze niet het volledige scala aan opties om aan uw specifieke vereisten te voldoen. Als u de meest geschikte waarden wilt bepalen, test u om te begrijpen hoe de instellingen van invloed zijn op uw toepassing. Raadpleeg de betrouwbaarheidshandleiding voor elke Azure-service in uw architectuur voor servicespecifieke standaardinstellingen en configuratieopties.
Tijdelijke en niet-tijdelijke fouten vastleggen en bijhouden
Uw strategie voor opnieuw proberen moet uitzonderingsafhandeling en andere instrumentatie bevatten die pogingen voor opnieuw proberen registreert. Een incidentele tijdelijke fout en nieuwe poging worden verwacht en duiden niet op een probleem. Maar regelmatige of toenemende aantallen nieuwe pogingen duiden meestal op een probleem dat een fout kan veroorzaken of de prestaties en beschikbaarheid van toepassingen kan verminderen.
Tijdelijke fouten vastleggen als waarschuwingsvermeldingen in plaats van als foutvermeldingen, zodat bewakingssystemen deze niet detecteren als toepassingsfouten die valse waarschuwingen kunnen activeren.
Sla een waarde op in uw logboekvermeldingen die aangeven of er throttling in de service of andere typen fouten, zoals verbindingsfouten, zijn die nieuwe pogingen veroorzaken. Deze aanpak helpt u bij het onderscheiden van de oorzaken tijdens gegevensanalyse. Een toename van beperkingsfoutmeldingen duidt meestal op een ontwerpfout in de toepassing of de noodzaak om te migreren naar een premiumservice die dedicated hardware biedt.
Meet en registreer de totale verstreken tijden voor bewerkingen die een mechanisme voor opnieuw proberen bevatten. Deze metrische waarde geeft nauwkeurig het algehele effect aan dat tijdelijke fouten hebben op reactietijden van gebruikers, proceslatentie en de efficiëntie van toepassingsgebruiksscenario's. Registreer het aantal nieuwe pogingen dat zich voordoet, zodat u inzicht krijgt in de factoren die bijdragen aan de reactietijd.
Implementeer een telemetrie- en bewakingssysteem dat waarschuwingen genereert wanneer de volgende metrische gegevens toenemen:
- Het aantal en de frequentie van fouten
- Het gemiddelde aantal nieuwe pogingen
- De totale tijd die is verstreken voordat bewerkingen zijn voltooid
Bewerkingen beheren die voortdurend mislukken
Maak een plan voor het afhandelen van bewerkingen die bij elke poging blijven mislukken. Deze situaties zijn onvermijdelijk.
Een strategie voor opnieuw proberen definieert het maximum aantal keren dat een toepassing een bewerking opnieuw moet uitvoeren. Het voorkomt niet dat de toepassing de bewerking herhaalt om te beginnen met hetzelfde aantal nieuwe pogingen. Als een orderverwerkingsservice bijvoorbeeld mislukt met een fatale fout die deze permanent uit de service haalt, kan de strategie voor opnieuw proberen een time-out voor de verbinding detecteren en deze behandelen als een tijdelijke fout. De code probeert de bewerking het opgegeven aantal keren opnieuw uit te voeren en stopt vervolgens. Wanneer een andere klant een order plaatst, probeert de toepassing de bewerking opnieuw uit te voeren, probeert het opnieuw en mislukt deze.
Als u continu nieuwe pogingen wilt voorkomen voor bewerkingen die voortdurend mislukken, implementeert u het circuitonderbrekerpatroon. Wanneer u dit patroon gebruikt, als het aantal fouten binnen een opgegeven tijdvenster een drempelwaarde overschrijdt, keren aanvragen onmiddellijk als fouten terug naar de aanroeper en probeert de toepassing geen toegang te krijgen tot de mislukte resource of service.
De toepassing kan de service periodiek testen, op onregelmatige basis en met lange intervallen tussen aanvragen, om te detecteren wanneer deze beschikbaar is. Het interval is afhankelijk van factoren zoals de ernst van de bewerking en de aard van de service. Het kan variëren van een paar minuten tot enkele uren. Wanneer de test is geslaagd, kan de toepassing de normale bewerkingen hervatten en aanvragen doorgeven aan de zojuist herstelde service.
In de tussentijd kunt u mogelijk terugvallen op een ander exemplaar van de service in een ander datacenter of een andere toepassing. U kunt ook een vergelijkbare service gebruiken die compatibel, maar eenvoudiger, functionaliteit biedt of een aantal alternatieve bewerkingen uitvoert op basis van de hoop dat de service binnenkort beschikbaar is. U kunt bijvoorbeeld aanvragen voor de service opslaan in een wachtrij of gegevensarchief en ze later opnieuw proberen. Of u kunt de gebruiker omleiden naar een alternatief exemplaar van de toepassing, de prestaties van de toepassing verminderen, maar toch acceptabele functionaliteit bieden, of gewoon een bericht naar de gebruiker retourneren om aan te geven dat de toepassing momenteel niet beschikbaar is.
Andere overwegingen
Wanneer u de waarden voor het aantal nieuwe pogingen en de intervallen voor nieuwe pogingen voor een beleid bepaalt, kunt u overwegen of de bewerking voor de service of resource deel uitmaakt van een langdurige of multistep-bewerking. Het kan lastig of kostbaar zijn om te compenseren voor alle operationele stappen die al zijn geslaagd wanneer een van deze stappen mislukt. In dit geval kunnen een lang interval en een groot aantal nieuwe pogingen acceptabel zijn zolang de strategie andere bewerkingen niet blokkeert door schaarse resources vast te houden of te vergrendelen.
Overweeg of het opnieuw proberen van dezelfde bewerking kan leiden tot inconsistenties van gegevens. Als een toepassing onderdelen van een proces met meerdere stappen herhaalt en de bewerkingen niet idempotent zijn, kunnen inconsistenties optreden. Als een bewerking waarmee een waarde wordt verhoogd bijvoorbeeld wordt herhaald, resulteert deze in een onjuist resultaat. Een herhaalde bewerking die een bericht naar een wachtrij verzendt, kan ook problemen veroorzaken voor een consument die geen dubbele berichten kan detecteren. Als u deze scenario's wilt voorkomen, ontwerpt u elke stap als een idempotente bewerking. Zie het Idempotent Consumer-patroon voor meer informatie.
Wees doelgericht met het bereik van bewerkingen die de toepassing opnieuw uitvoert. Het kan bijvoorbeeld eenvoudiger zijn om logica voor opnieuw proberen te implementeren op een niveau dat meerdere bewerkingen bevat en die allemaal opnieuw proberen als er een mislukt. Maar deze aanpak kan leiden tot idempotentieproblemen of onnodige terugdraaibewerkingen.
Als u een bereik voor opnieuw proberen kiest dat verschillende bewerkingen bevat, moet u rekening houden met de totale latentie van alle bewerkingen wanneer u intervallen voor opnieuw proberen bepaalt, wanneer u de verstreken tijd van de bewerking bewaakt en voordat u waarschuwingen voor fouten genereert.
Houd rekening met hoe uw strategie voor opnieuw proberen van invloed is op buren en andere tenants in een gedeelde toepassing en wanneer u gedeelde resources en services gebruikt. Agressieve beleidsregels voor opnieuw proberen kunnen het aantal tijdelijke fouten verhogen dat zich voor andere gebruikers voordoet en voor toepassingen die de resources en services delen. Beleid voor opnieuw proberen dat andere gebruikers implementeren, kan ook van invloed zijn op uw toepassing. Gebruik premium-services die niet worden gedeeld voor bedrijfskritieke toepassingen. Met deze aanpak kunt u de belasting en consequente beperking van resources en services beheren, wat de extra kosten kan rechtvaardigen.