Hälsokontroller och kontrollerad degradering

Hälsokontroller är den mekanism som lastbalanserare och trafikhanterare använder för att upptäcka om en backend-instans kan hantera begäranden. Utan hälsokontroller kan en lastbalanserare fortsätta att skicka trafik till en server som har slutat fungera eller inte svarar, vilket orsakar fel som användarna ser. Korrekt konfigurerade hälsokontroller möjliggör automatisk omdirigering av trafik bort från instanser som inte är friska inom några sekunder efter ett fel.

Azure Load Balancer stöder två typer av hälsokontroller:

• TCP probe — kontrollerar om backend kan acceptera en TCP-anslutning på en angiven port. Enkelt, men verifierar inte programlogiken.
• HTTP/HTTPS probe — skickar en GET-begäran till en angiven sökväg och förväntar sig ett 200 OK-svar. Mer träffsäkert eftersom det testar programmets slutpunkt direkt.

En backend markeras som ej frisk om kontrollen misslyckas ett konfigurerbart antal gånger i följd.

En väl utformad hälso-slutpunkt (/health) gör mer än att returnera 200 OK — den verifierar att programmets kritiska beroenden kan nås. En omfattande hälsokontroll kan testa anslutningen till databasen, cachen och eventuella efterföljande API:er. Om något beroende inte är tillgängligt returnerar slutpunkten en 5xx-statuskod, vilket signalerar till lastbalanseraren att ta bort instansen från rotationen.

Azure Traffic Manager använder också hälsokontroller, men på regional nivå. Den skickar regelbundna HTTP- eller HTTPS GET-begäranden till den konfigurerade slutpunkts-URL:en i varje region. Om en slutpunkt inte svarar inom tidsgränsen under ett angivet antal intervall i följd markerar Traffic Manager slutpunkten som degraderad och slutar dirigera DNS-frågor till den. Användarna omdirigeras då till en frisk region.

Azure Application Gateway har mer avancerade funktioner för hälsokontroller än standardversionen av Load Balancer. Den stöder anpassade hälsokontroller där ni kan ange värdhuvudet, det förväntade intervallet för statuskoder (till exempel 200-399) och en sträng som ska matchas i innehållet. Application Gateway stöder även dirigering per sökväg, så att olika backend-pooler kan ha olika konfigurationer för hälsokontroller för olika URL-sökvägar.

Kontrollerad degradering är ett programs förmåga att fortsätta tillhandahålla begränsad funktionalitet när ett eller flera av dess beroenden slutar fungera. I stället för att krascha helt upptäcker programmet att en icke-kritisk tjänst inte är tillgänglig och växlar till ett degraderat men fortfarande användbart läge. Om till exempel en rekommendationstjänst slutar fungera kan en e-handelswebbplats visa generella förslag i stället för att hela produktsidan kraschar.

Circuit breaker-mönstret förhindrar att en applikation upprepade gånger anropar en underliggande tjänst som inte fungerar. När en tjänst börjar fallera öppnas circuit breakern och returnerar omedelbart ett fel eller ett reservsvar utan att göra nätverksanropet. Efter en nedkylningsperiod övergår den till tillståndet halvöppet och tillåter ett testanrop. Om det lyckas stängs circuit breakern och normal drift återupptas.

För tillfälliga fel (korta nätverksstörningar eller tillfällig överbelastning av en tjänst) är en strategi med nytt försök och exponentiell backoff lämplig. Applikationen försöker anropa tjänsten igen efter en fördröjning och fördubblar fördröjningen vid varje försök upp till ett maximum. Genom att lägga till jitter (slumpmässig variation) i fördröjningen förhindrar du att alla nya försök synkroniseras och överbelastar en tjänst som håller på att återhämta sig.

Bulkhead-mönstret isolerar olika delar av en applikation i separata resurspooler, så att ett fel i ett område inte förbrukar alla resurser och slår ut hela systemet. Namnet kommer från skott i fartyg, som hindrar ett vattenfyllt utrymme från att sänka hela fartyget. I Azure kan detta innebära att separata trådpooler eller separata App Service-planer används för olika tjänster för att begränsa effekten av fel.

En vanlig teknik för degradering under kontrollerade former är att tillhandahålla cachade eller inaktuella data när en datakälla i realtid inte är tillgänglig. En produkts katalogsida kan till exempel visa gårdagens cachade priser från Azure Cache for Redis i stället för ett felmeddelande om databasen tillfälligt inte kan nås. Användarna upplever då en mindre olägenhet (något inaktuella priser) i stället för ett fullständigt avbrott.

Degradering under kontrollerade former ska vara synlig och mätbar. Använd Application Insights för att spåra frekvensen av öppnade circuit breakers, reservsvar och nya försök som anpassade mätvärden. Konfigurera aviseringar när dessa mätvärden överskrider tröskelvärden, så att beredskapsteamet informeras om att applikationen körs i ett degraderat tillstånd även om användarupplevelsen verkar acceptabel.

I den här lektionen har du lärt dig att hälsokontroller gör det möjligt för lastbalanserare att upptäcka backend-servrar som inte fungerar och automatiskt dirigera om trafik; att degradering under kontrollerade former håller applikationer delvis fungerande när beroenden fallerar; samt att mönster som circuit breaker, retry med backoff och bulkhead implementerar motståndskraft på applikationsnivå. Härnäst utforskar vi koncept inom haveriberedskap — RTO, RPO och återställningsnivåer.