Design för självåterställning

Designa programmet så att det återställer sig självt när fel uppstår

I ett distribuerat system kan fel inträffa. Det kan uppstå fel i maskinvaran. Nätverket kan drabbas av tillfälliga fel. Mer sällsynt är att en hel tjänst eller region kan drabbas av avbrott, men även det måste du planera för.

Därför ska du designa programmet så att det återställer sig självt när fel uppstår. Detta kräver ett angreppssätt med tre huvudlinjer:

• Identifiera fel.
• Hantera fel på ett konstruktivt sätt.
• Logga och övervaka fel för att få operativa insikter.

Hur du svarar på en viss typ av fel kan bero på programmets tillgänglighetskrav. Om du till exempel behöver mycket hög tillgänglighet kan du automatiskt redundansväxla till en sekundär region under ett regionalt strömavbrott. Dock ger detta en högre kostnad än omfördelning inom en enskild region.

Du ska inte heller bara tänka på stora händelser, t.ex. regionala strömavbrott, som oftast är ovanliga. Du bör fokusera minst lika mycket på hur du hanterar lokala, tillfälliga fel, till exempel fel vid anslutning till nätverket eller misslyckade databasanslutningar.

Rekommendationer

Försök att utföra misslyckade åtgärder igen. Tillfälliga fel kan inträffa på grund av tillfälligt förlorade nätverksanslutningar, en nedkopplad databasanslutning eller att en tidsgräns uppnås när en tjänst är upptagen. Bygg in logik för omförsök i ditt program för att hantera tillfälliga fel. För många Azure-tjänster implementerar klient-SDK automatiska omförsök. Mer information finns i Hantering av tillfälliga fel och Återförsöksmönster.

Skydda misslyckade fjärrtjänster (kretsbrytare). Det är bra att försöka igen efter ett tillfälligt fel, men om felet kvarstår kan du få för många anrop till en tjänst som inte fungerar. Detta kan leda till kaskadfel, när begäranden ställs i kö. Använd kretsbrytarmönstret för att misslyckas snabbt (utan att göra fjärranropet) när en åtgärd troligen kommer att misslyckas.

Isolera kritiska resurser (vattentäta skott). Fel i ett delsystem kan ibland spridas. Det här kan inträffa om ett fel gör att vissa resurser, till exempel trådar eller sockets, inte frigörs i rimlig tid, vilket leder till resursuttömning. Du kan undvika det här genom att dela upp systemet i isolerade grupper, så att ett fel i en del inte påverkar hela systemet.

Utför belastningsutjämning. Det kan uppstå plötsliga trafiktoppar i program som överbelastar tjänsterna i serverdelen. Undvik detta genom att använda mönstret köbaserad belastningsutjämning för att köa arbetsobjekt för att köra asynkront. Kön fungerar som en buffert som jämnar ut toppar i belastningen.

Redundans . Om en instans inte går att nå, kan du redundansväxla till en annan instans. Placera flera instanser bakom en lastbalanserare eller Traffic Manager för saker som är tillståndslösa, som en webbserver. Använd repliker och redundansväxling för saker som lagrar tillstånd, t.ex. en databas. Det här kan kräva att programmet hanterar slutlig konsekvens, beroende på datalagret och hur det replikeras.

Kompensera för misslyckade transaktioner. Undvik i allmänhet distribuerade transaktioner, eftersom de kräver samordning över tjänster och resurser. Skapa i stället en åtgärd från mindre enskilda transaktioner. Om åtgärden misslyckas halvvägs använder du kompenserande transaktioner för att ångra eventuella steg som redan slutförts.

Kontrollpunkt för långvariga transaktioner. Kontrollpunkter kan tillhandahålla återhämtningskapacitet om en tidskrävande åtgärd misslyckas. När åtgärden startar om (om den till exempel övertas av en annan virtuell dator), kan den återupptas från den senaste kontrollpunkten.

Nedgradera på ett smidigt sätt. Ibland kan du inte undvika ett problem, men du kan tillhandahålla nedsatt funktionalitet som fortfarande är användbar. 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 är det för en e-handelsplats förmodligen mindre viktigt att visa produktrekommendationer än att behandla order.

Begränsa klienter. Ibland skapar ett litet antal användare hög belastning som kan minska programmets tillgänglighet för andra användare. I så fall kan du begränsa klienten under en viss tidsperiod. Se Mönstret Begränsning.

Blockera obehöriga. Bara för att du begränsar en klient, innebär det inte att klienten handlade illvilligt. Det betyder bara att klienten har överskridit sin kvot av tjänsten. Men om en klient upprepade gånger överskrider sin kvot eller på annat sätt handlar felaktigt, kan du behöva blockera dem. Definiera en out-of-band-process för användaren att begära att blockeringen hävs.

Använd val av ledare. När du vill samordna en aktivitet använder du Val av ledare för att välja en koordinator. På så sätt är koordinatorn inte en enskild felpunkt. Om koordinatorn misslyckas, väljs en ny. Överväg att använda ett standardprogram, till exempel Zookeeper, i stället för att implementera en algoritm för val av ledare från grunden.

Testa med felinmatning. Alltför ofta testas rätt väg, men inte fel väg. Ett system kan användas i produktion under lång tid innan en felaktighet inträffar. Använd felinmatning för att testa elasticiteten i systemet vid fel, antingen genom att utlösa faktiska fel eller genom att simulera dem.

Omfatta kaostekniker. Kaostekniker utökar begreppet felinmatning genom att mata in slumpmässiga fel eller avvikande villkor i produktionsinstanser.

En strukturerad metod för att göra dina program självläkande finns i Utforma tillförlitliga program för Azure.