Dela via

Rekommendationer för självåterställning och självbevarelsedrift

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Reliability:

RE:07 Förbättra återhämtning och återställning av din arbetsbelastning genom att implementera självbevarande och självåterställningsåtgärder. Skapa funktioner i lösningen med hjälp av infrastrukturbaserade tillförlitlighetsmönster och programvarubaserade designmönster för att hantera komponentfel och tillfälliga fel. Skapa funktioner i systemet för att identifiera lösningskomponentfel och initiera automatiskt korrigerande åtgärder medan arbetsbelastningen fortsätter att fungera med fullständig eller reducerad funktionalitet.

Relaterade guider: Bakgrundsjobb | Tillfälliga fel

Den här guiden beskriver rekommendationerna för att skapa självåterställning och självbevarande funktioner i din programarkitektur för att optimera tillförlitligheten.

Självbevarande funktioner ökar motståndskraften i din arbetsbelastning. De minskar sannolikheten för ett fullständigt avbrott och gör att arbetsbelastningen kan fungera i ett degraderat tillstånd medan misslyckade komponenter återställs. Självåterställningsfunktioner hjälper dig att undvika stilleståndstid genom att skapa felidentifiering och automatiska korrigerande åtgärder för att svara på olika feltyper.

Den här guiden beskriver designmönster som fokuserar på självbevarelsedrift och självåterställning. Införliva dem i din arbetsbelastning för att stärka dess återhämtning och återställning. Om du inte implementerar mönster riskerar dina appar att misslyckas när oundvikliga problem uppstår.

Definitioner

Period Definition
Självläkning Arbetsbelastningens möjlighet att automatiskt lösa problem genom att återställa berörda komponenter och vid behov växla över till redundant infrastruktur.
Självbevarelsedrift Arbetsbelastningens förmåga att vara motståndskraftig mot potentiella problem.

Viktiga designstrategier

Design för självbevarelsedrift

Om du vill utforma din arbetsbelastning för självbevarelsedrift följer du designmönstren för infrastruktur och programarkitektur för att optimera arbetsbelastningens återhämtning. För att minimera risken för ett fullständigt programstopp ökar du lösningens återhämtning genom att eliminera enskilda felpunkter och minimera felradien. Designmetoderna i den här artikeln innehåller flera alternativ för att stärka arbetsbelastningens motståndskraft och uppfylla arbetsbelastningens definierade tillförlitlighetsmål.

Vägledning och mönster för infrastrukturdesign

På infrastrukturnivå bör en redundant arkitekturdesign stödja dina kritiska flöden, med resurser distribuerade över tillgänglighetszoner eller regioner. Implementera autoskalning när det är möjligt. Autoskalning hjälper till att skydda din arbetsbelastning mot oväntade aktivitetstoppar, vilket ytterligare förstärker infrastrukturen.

Använd mönstret Distributionsstämplar eller Bulkhead-mönstret för att minimera explosionsradien när problem uppstår. Dessa mönster hjälper dig att hålla din arbetsbelastning tillgänglig om en enskild komponent inte är tillgänglig. Använd följande mönster för programdesign i kombination med din strategi för automatisk skalning.

  • Mönster för distributionsstämplar: Etablera, hantera och övervaka en varierad grupp resurser som ska vara värd för och använda flera arbetsbelastningar eller klientorganisationer. Varje enskild kopia kallas för en stämpel, eller ibland en tjänstenhet, skalningsenhet eller cell.

  • Skottmönster: Partitionera tjänstinstanser i olika grupper, så kallade pooler, baserat på kraven på konsumentbelastning och tillgänglighet. Den här designen hjälper till att isolera fel och gör att du kan upprätthålla tjänstfunktioner för vissa konsumenter, även under ett fel.

Vägledning och mönster för programdesign

Undvik att skapa monolitiska program i programdesignen. Använd löst kopplade tjänster eller mikrotjänster som kommunicerar med varandra via väldefinierade standarder för att minska risken för omfattande problem när fel uppstår på en enskild komponent. Du kan till exempel standardisera användningen av en Service Bus för att hantera all asynkron kommunikation. Standardisering av kommunikationsprotokoll säkerställer att programdesignen är konsekvent och förenklad, vilket gör arbetsbelastningen mer tillförlitlig och enklare att felsöka när fel inträffar. När det är praktiskt föredrar du asynkron kommunikation mellan komponenter framför synkron kommunikation för att minimera timeout-problem, till exempel obeställbara bokstäver. Följande designmönster hjälper dig att organisera din arbetsbelastning och definiera kommunikationen mellan komponenter på ett sätt som bäst uppfyller dina affärskrav.

  • Ambassadörsmönster: Separera din affärslogik från din nätverkskod och återhämtningslogik. Skapa hjälpkomponenttjänster som skickar nätverksförfrågningar åt en konsumenttjänst eller ett konsumentprogram. Du kan använda det här mönstret för att implementera återförsöksmekanismer eller kretsbrytningar.

  • Asynkront mönster för begäran-svar: Frikoppla serverdelsbearbetning från en klientdelsvärd om serverdelsbearbetningen måste vara asynkron, men klientdelen behöver ett tydligt svar.

  • Cache-Aside-mönster: Läs in data på begäran från ett datalager till en cache. Det här mönstret kan förbättra prestandan och bidra till att upprätthålla konsekvensen mellan data som lagras i cacheminnet och data som finns i det underliggande datalagret.

  • Kretsbrytarmönster: Använd kretsbrytare för att proaktivt avgöra om en åtgärd ska kunna fortsätta eller returnera ett undantag baserat på antalet fel nyligen.

  • Mönster för anspråkskontroll: Dela upp ett stort meddelande i en anspråkskontroll och en nyttolast. Skicka anspråkskontrollen till meddelandeplattformen och lagra nyttolasten i en extern tjänst. Det här mönstret gör att stora meddelanden kan bearbetas samtidigt som meddelandebussen skyddas och klienten inte överbelastas eller saktas ned.

  • Mönster för konkurrerande konsumenter: Gör det möjligt för flera samtidiga konsumenter att bearbeta meddelanden som tas emot på samma meddelandekanal. Ett system kan bearbeta flera meddelanden samtidigt, vilket optimerar dataflödet, förbättrar skalbarheten och tillgängligheten och balanserar arbetsbelastningen.

  • Konfigurera tidsgränser för begäran: Konfigurera tidsgränser för begäranden för anrop till tjänster eller databaser. Tidsgränser för databasanslutning är vanligtvis inställda på 30 sekunder.

  • Gatekeeper-mönster: Skydda program och tjänster med hjälp av en dedikerad värdinstans för att asynkrona begäranden mellan klienter och programmet eller tjänsten. Mäklaren validerar och sanerar begäranden och kan ge ett extra säkerhetslager för att begränsa systemets attackyta.

  • Mönster för köbaserad belastningsutjämning: Frikoppla uppgifterna från tjänsten i din lösning med hjälp av en kö mellan dem så att de kan köras asynkront. Använd en kö som en buffert mellan en aktivitet och en tjänst som den anropar för att jämna ut tillfälliga tunga belastningar som kan orsaka att tjänsten misslyckas eller att aktiviteten överskrider tidsgränsen. Det här mönstret kan hjälpa till att minimera effekten av toppar i efterfrågan på tillgänglighet och svarstider för uppgiften och tjänsten.

  • Begränsningsmönster: Kontrollera förbrukningen av resurser som används av en instans av ett program, en enskild klientorganisation eller en hel tjänst. Det här mönstret gör att systemet kan fortsätta att fungera och uppfylla serviceavtal (SLA), även när en ökad efterfrågan lägger en extrem belastning på resurserna.

  • Mönster för hantering av tillfälliga fel och återförsök: Implementera en strategi för att hantera tillfälliga fel för att ge återhämtning i din arbetsbelastning. Tillfälliga fel är normala och förväntade förekomster i molnmiljöer. Vanliga orsaker till tillfälliga fel är tillfällig nätverksförlust, en borttagen databasanslutning eller en tidsgräns när en tjänst är upptagen. Mer information om hur du utvecklar en återförsöksstrategi finns i guiden för tillfällig felhantering i den här serien.

Bakgrundsjobb

Bakgrundsjobb är ett effektivt sätt att förbättra systemets tillförlitlighet genom att ta bort uppgifter från användargränssnittet . Implementera en uppgift som ett bakgrundsjobb om den inte kräver användarindata eller feedback och om den inte påverkar användargränssnittets svarstider.

Vanliga exempel på bakgrundsjobb är:

  • CPU-intensiva jobb, till exempel att utföra komplexa beräkningar eller analysera strukturella modeller.
  • I/O-intensiva jobb, till exempel att köra flera lagringsåtgärder eller indexera stora filer.
  • Batchjobb, till exempel uppdatering av data regelbundet eller bearbetning av uppgifter vid en viss tidpunkt.
  • Långvariga arbetsflöden, till exempel att slutföra en beställning eller etablera tjänster och system.

Mer information finns i Rekommendationer för bakgrundsjobb.

Design för självåterställning

Om du vill utforma arbetsbelastningen för självåterställning implementerar du felidentifiering så att automatiska svar utlöses och kritiska flöden återställs korrekt. Aktivera loggning för att ge driftinsikter om felets art och återställningens framgång. De metoder som du använder för att uppnå självåterställning för ett kritiskt flöde beror på de tillförlitlighetsmål som definieras för det flödet och flödets komponenter och beroenden.

Vägledning för infrastrukturdesign

På infrastrukturnivå bör dina kritiska flöden stödjas av en redundant arkitekturdesign med automatisk redundans aktiverad för komponenter som stöder den. Du kan aktivera automatisk redundans för följande typer av tjänster:

  • Beräkningsresurser: Azure Virtual Machine Scale Sets och de flesta PaaS-beräkningstjänster (plattform som en tjänst) kan konfigureras för automatisk redundans.

  • Databaser: Relationsdatabaser kan konfigureras för automatisk redundans med lösningar som Azure SQL-redundanskluster, AlwaysOn-tillgänglighetsgrupper eller inbyggda funktioner med PaaS-tjänster. NoSQL-databaser har liknande klustringsfunktioner och inbyggda funktioner för PaaS-tjänster.

  • Lagring: Använd redundanta lagringsalternativ med automatisk redundans.

Vägledning och mönster för programdesign

  • Blockera dåliga aktörer: Om du begränsar en klient betyder det inte att klienten agerade skadligt. Det kan innebära att klienten överskred sin tjänstkvot. Men om en klient konsekvent överskrider sin kvot eller på annat sätt beter sig dåligt kan du blockera dem. Definiera en out-of-band-process för en klient för att begära avblockering.

  • Kretsbrytarmönster: Om ett fel kvarstår efter att återförsöksmekanismen har initierats riskerar du sammanhängande fel till följd av en växande kvarvarande anrop. En kretsbrytare som är utformad för att fungera med återförsöksmekanismen begränsar risken för sammanhängande fel genom att hindra appen från att upprepade gånger försöka köra en åtgärd som sannolikt kommer att misslyckas.

  • Kompenserande transaktionsmönster: Om du använder en så småningom konsekvent åtgärd som består av en serie steg implementerar du mönstret Kompenserande transaktion. Om ett eller flera av stegen misslyckas kan du använda det här mönstret för att ångra det arbete som stegen utförde.

  • Försämras på ett smidigt sätt: Ibland kan du inte kringgå ett problem, men du kan ge nedsatt funktionalitet. Tänk dig ett program som visar en katalog med böcker. Om programmet inte kan hämta miniatyrbilden för omslaget kan det visas en platshållarbild istället. Hela delsystem kanske är icke-kritiska för programmet. Till exempel för en e-handelswebbplats är det förmodligen mindre viktigt att visa produktrekommendationer än att bearbeta beställningar. En graciös försämring kan även omfatta automatiska redundansåtgärder. När en databas automatiskt redundansväxlar till en replik på grund av ett problem med den primära instansen, försämras prestandan under en kort tid.

  • Valmönster för ledare: När du behöver samordna en uppgift använder du val av ledare för att välja en koordinator så att en koordinator inte är en enda felpunkt. Om koordinatorn misslyckas, väljs en ny. I stället för att implementera en valalgoritm för ledare från grunden bör du överväga en lösning utanför hyllan, till exempel ZooKeeper.

  • Testmönster: Inkludera testning av de mönster som du implementerar som en del av standardtestningsprocedurerna.

  • Använd kontrollpunkter för långvariga transaktioner: Kontrollpunkter kan ge återhämtning om en långvarig åtgärd misslyckas. När åtgärden startas om, till exempel om den hämtas av en annan virtuell dator, kan den återupptas från den senaste kontrollpunkten. Överväg att implementera en mekanism som registrerar tillståndsinformation om aktiviteten med jämna mellanrum. Spara det här tillståndet i varaktig lagring som kan nås av alla instanser av processen som kör uppgiften. Om processen stängs av kan det arbete som den utförde återupptas från den senaste kontrollpunkten med hjälp av en annan instans. Det finns bibliotek som tillhandahåller den här funktionen, till exempel NServiceBus och MassTransit. De bevarar transparent tillstånd, där intervallen är anpassade till bearbetningen av meddelanden från köer i Azure Service Bus.

Automatiserade självåterställningsåtgärder

En annan metod för självåterställning är användningen av automatiserade åtgärder som utlöses av övervakningslösningen när fördefinierade ändringar av hälsostatus identifieras. Om din övervakning till exempel upptäcker att en webbapp inte svarar på begäranden kan du skapa automatisering via ett PowerShell-skript för att starta om apptjänsten. Beroende på teamets kompetensuppsättning och önskade utvecklingstekniker använder du en webhook eller funktion för att skapa mer komplexa automatiseringsåtgärder. Se referensarkitekturen för händelsebaserad molnautomatisering för ett exempel på hur du använder en funktion för att svara på databasbegränsning. Med automatiserade åtgärder kan du snabbt återställa och minimera behovet av mänsklig inblandning.

Azure-underlättande

De flesta Azure-tjänster och klient-SDK:er har en återförsöksmekanism. Men de skiljer sig eftersom varje tjänst har olika egenskaper och krav, så varje återförsöksmekanism justeras till en specifik tjänst. Mer information finns i Rekommendationer för tillfällig felhantering.

Använd Azure Monitor-åtgärdsgrupper för aviseringar, till exempel e-post, röst eller SMS, och för att utlösa automatiserade åtgärder. När du får ett meddelande om ett fel utlöser du en Azure Automation-runbook, Azure Event Hubs, en Azure-funktion, en logikapp eller en webhook för att utföra en automatisk återställningsåtgärd.

Att tänka på

Bekanta dig med övervägandena för varje mönster. Se till att mönstret passar dina arbetsbelastnings- och affärskrav före implementeringen.

Exempel

Exempel på användningsfall för vissa mönster finns i det tillförlitliga webbappmönstret för .NET. Följ de här stegen för att distribuera en referensimplementering.

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Checklista för tillförlitlighet