Den här artikeln visar hur du använder mönstret Reliable Web App. Mönstret Reliable Web App är en uppsättning principer och implementeringstekniker som definierar hur du ska ändra webbappar (omplatform) när du migrerar till molnet. Den fokuserar på de minimala koduppdateringar som du behöver göra för att lyckas i molnet.
För att underlätta tillämpningen av den här vägledningen finns det en referensimplementering av det Reliable Web App-mönster som du kan distribuera.
Arkitektur för referensimplementeringen. Ladda ned en Visio-fil med den här arkitekturen.
I följande vägledning används referensimplementeringen som ett exempel hela vägen. Följ dessa steg för att planera en implementering av reliable web app-mönstret:
Definiera affärsmål
Det första steget i övergången till molnbaserad databehandling är att formulera dina affärsmål. Mönstret Reliable Web App betonar vikten av att ange både omedelbara och framtida mål för ditt webbprogram. Dessa mål påverkar ditt val av molntjänster och arkitekturen för ditt webbprogram i molnet.
Exempel: Det fiktiva företaget Relecloud säljer biljetter via sin lokala webbapp. Relecloud har en positiv försäljningsprognos och förväntar sig ökad efterfrågan på sin biljettwebbapp. För att möta denna efterfrågan definierade de målen för webbappen:
- Tillämpa kodändringar med låga kostnader och höga värden
- Nå ett servicenivåmål (SLO) på 99,9 %
- Anta DevOps-metoder
- Skapa kostnadsoptimerade miljöer
- Förbättra tillförlitligheten och säkerheten
Releclouds lokala infrastruktur var inte en kostnadseffektiv lösning för att nå dessa mål. Därför bestämde de sig för att migrera sina webbprogram till Azure var det mest kostnadseffektiva sättet att uppnå sina omedelbara och framtida mål.
Välj rätt hanterade tjänster
När du flyttar en webbapp till molnet bör du välja Azure-tjänster som uppfyller dina affärskrav och som överensstämmer med de aktuella funktionerna i den lokala webbappen. Justeringen hjälper till att minimera omplatformningsarbetet. Använd till exempel tjänster som gör att du kan behålla samma databasmotor och stödja befintliga mellanprogram och ramverk. Följande avsnitt innehåller vägledning för att välja rätt Azure-tjänster för din webbapp.
Exempel: Innan du flyttade till molnet var Releclouds biljettwebbapp en lokal, monolitisk ASP.NET app. Den kördes på två virtuella datorer och hade en Microsoft SQL Server-databas. Webbappen har drabbats av vanliga utmaningar när det gäller skalbarhet och funktionsdistribution. Den här utgångspunkten, deras affärsmål och SLO drev deras tjänstval.
Programplattform
Välj den bästa programvärdplattformen för din webbapp. Azure har många olika beräkningsalternativ för att uppfylla en rad olika krav för webbappar. Hjälp med att begränsa alternativen finns i beslutsträdet för Azure-beräkning.
Exempel: Relecloud valde Azure App Service som programplattform av följande skäl:
Serviceavtal (SLA): Det har ett högt serviceavtal som uppfyller serviceavtalet för produktionsmiljön på 99,9 %.
Minskade hanteringskostnader: Det är en helt hanterad lösning som hanterar skalning, hälsokontroller och belastningsutjämning.
.NET-stöd: Den stöder den version av .NET som programmet är skrivet i.
Kapacitet för containerisering: Webbappen kan konvergera i molnet utan containerstorlek, men programplattformen stöder även containerisering utan att ändra Azure-tjänster
Autoskalning: Webbappen kan automatiskt skala upp, ned, in och ut baserat på användartrafik och inställningar.
Identitetshantering
Välj den bästa identitetshanteringslösningen för din webbapp. Mer information finns i jämföra lösningar för identitetshantering och autentiseringsmetoder.
Exempel: Relecloud valde Microsoft Entra-ID av följande skäl:
Autentisering och auktorisering: Programmet måste autentisera och auktorisera callcenter-anställda.
Skalbar: Den skalas för att stödja större scenarier.
Användaridentitetskontroll: Callcenter-anställda kan använda sina befintliga företagsidentiteter.
Stöd för auktoriseringsprotokoll: Det stöder OAuth 2.0 för hanterade identiteter.
Databas
Välj den bästa databasen för din webbapp. Hjälp med att begränsa alternativen finns i beslutsträdet för Azure Data Store.
Exempel: Webbappen använde SQL Server lokalt och Relecloud ville använda det befintliga databasschemat, lagrade procedurer och funktioner. Flera SQL-produkter är tillgängliga i Azure, men Relecloud valde Azure SQL Database av följande skäl:
Tillförlitlighet: Nivån generell användning ger ett högt serviceavtal och redundans i flera regioner. Det kan ge stöd för hög användarbelastning.
Minskade hanteringskostnader: Den tillhandahåller en hanterad SQL-databasinstans.
Stöd för migrering: Den stöder databasmigrering från lokal SQL Server.
Konsekvens med lokala konfigurationer: Den stöder befintliga lagrade procedurer, funktioner och vyer.
Återhämtning: Den stöder säkerhetskopieringar och återställning till tidpunkt.
Expertis och minimal omarbetning: SQL Database drar nytta av den interna expertisen och kräver minimalt arbete att använda.
Övervakning av programprestanda
Välj en övervakning av programprestanda för webbappen. Application Insights är den Azure-inbyggda lösningen för programprestandahantering (APM). Det är en funktion i Azures övervakningslösning, Azure Monitor.
Exempel: Relecloud valde att använda Application Insights av följande skäl:
Integrering med Azure Monitor: Det ger den bästa integreringen med Azure Monitor.
Avvikelseidentifiering: Den identifierar automatiskt prestandaavvikelser.
Felsökning: Det hjälper dig att diagnostisera problem i appen som körs.
Övervakning: Den samlar in information om hur användare använder appen och gör att du enkelt kan spåra anpassade händelser.
Synlighetsgap: Den lokala lösningen hade ingen lösning för övervakning av programprestanda. Application Insights ger enkel integrering med programplattformen och koden.
Cache
Välj om du vill lägga till cache i webbappens arkitektur. Azure Cache for Redis är Azures primära cachelösning. Det är ett hanterat minnesinternt datalager baserat på Redis-programvaran.
Exempel: Releclouds webbappsbelastning är kraftigt skev mot att visa konserter och platsinformation. Den lade till Azure Cache for Redis av följande skäl:
Minskade hanteringskostnader: Det är en fullständigt hanterad tjänst.
Hastighet och volym: Den har dataflöde med hög dataflöde och låg latensläsning för data som ofta används och som ändras långsamt.
Mångsidig support: Det är en enhetlig cacheplats för alla instanser av webbappen att använda.
Externt datalager: De lokala programservrarna utförde VM-lokal cachelagring. Den här konfigurationen avlastade inte mycket frekventa data och det gick inte att ogiltigförklara data.
Nonsticky-sessioner: Externalisering av sessionstillstånd stöder icke-stickiga sessioner.
Lastbalanserare
Välj den bästa lastbalanseraren för webbappen. Azure har flera lastbalanserare. Om du vill ha hjälp med att begränsa alternativen kan du läsa välja den bästa lastbalanseraren för din app.
Exempel: Relecloud behövde en layer-7-lastbalanserare som kunde dirigera trafik över flera regioner. Relecloud behövde en webbapp för flera regioner för att uppfylla SLO på 99,9 %. Relecloud valde Azure Front Door av följande skäl:
Global belastningsutjämning: Det är en layer-7-lastbalanserare som kan dirigera trafik över flera regioner.
Brandvägg för webbprogram: Den integreras internt med Azure Web Application Firewall.
Flexibilitet för routning: Det gör att programteamet kan konfigurera inkommande behov för att stödja framtida ändringar i programmet.
Trafikacceleration: Den använder anycast för att nå närmaste Azure-närvaropunkt och hitta den snabbaste vägen till webbappen.
Anpassade domäner: Den stöder anpassade domännamn med flexibel domänverifiering.
Hälsoavsökningar: Programmet behöver intelligent hälsoavsökningsövervakning. Azure Front Door använder svar från avsökningen för att fastställa det bästa ursprunget för routning av klientbegäranden.
Stöd för övervakning: Den stöder inbyggda rapporter med en allt-i-ett-instrumentpanel för både Front Door och säkerhetsmönster. Du kan konfigurera aviseringar som integreras med Azure Monitor. Programmet kan logga varje begäran och misslyckade hälsoavsökningar.
DDoS-skydd: Det har inbyggt layer 3-4 DDoS-skydd.
Nätverk för innehållsleverans: Relecloud får i uppdrag att använda ett nätverk för innehållsleverans. Nätverket för innehållsleverans ger platsacceleration.
Brandvägg för webbaserade program
Välj en brandvägg för webbprogram för att skydda din webbapp mot webbattacker. Azure Web Application Firewall (WAF) är Azures brandvägg för webbprogram och ger centraliserat skydd mot vanliga webbexploateringar och sårbarheter.
Exempel: Relecloud behövs för att skydda webbappen från webbattacker. De använde Azure Web Application Firewall av följande skäl:
Globalt skydd: Det ger förbättrat globalt webbappskydd utan att offra prestanda.
Botnet-skydd: Teamet kan övervaka och konfigurera för att hantera säkerhetsproblem från botnät.
Paritet med lokal: Den lokala lösningen kördes bakom en brandvägg för webbprogram som hanteras av IT.
Användarvänlighet: Brandväggen för webbaserade program integreras med Azure Front Door.
Konfigurationslagring
Välj om du vill lägga till appkonfigurationslagring i webbappen. Azure App Configuration är en tjänst för central hantering av programinställningar och funktionsflaggor. Läs metodtipsen för appkonfiguration för att avgöra om den här tjänsten passar din app.
Exempel: Relecloud ville ersätta filbaserad konfiguration med ett centralt konfigurationslager som integreras med programplattformen och koden. De har lagt till App Configuration i arkitekturen av följande skäl:
Flexibilitet: Den stöder funktionsflaggor. Med funktionsflaggor kan användare välja att använda funktioner för tidig förhandsversion i en produktionsmiljö utan att distribuera om appen.
Stöder Git-pipeline: Sanningskällan för konfigurationsdata som behövs för att vara en Git-lagringsplats. Pipelinen som behövs för att uppdatera data i det centrala konfigurationsarkivet.
Stöder hanterade identiteter: Den stöder hanterade identiteter för att förenkla och skydda anslutningen till konfigurationsarkivet.
Hemlighetshanteraren
Använd Azure Key Vault om du har hemligheter att hantera i Azure. Du kan införliva Key Vault i .NET-appar med hjälp av ConfigurationBuilder-objektet.
Exempel: Releclouds lokala webbapp lagrade hemligheter i kodkonfigurationsfiler, men det är en bättre säkerhetspraxis att externalisera hemligheter. Även om hanterade identiteter är den bästa lösningen för att ansluta till Azure-resurser, hade Relecloud programhemligheter som de behövde hantera. Relecloud använde Key Vault av följande skäl:
Kryptering: Den stöder kryptering i vila och under överföring.
Hanterade identiteter: Programtjänsterna kan använda hanterade identiteter för att komma åt det hemliga arkivet.
Övervakning och loggning: Det underlättar granskningsåtkomst och genererar aviseringar när lagrade hemligheter ändras.
Integrering: Den tillhandahåller intern integrering med Azure-konfigurationsarkivet (App Configuration) och webbvärdplattformen (App Service).
Lagringslösning
Välj den bästa lagringslösningen för din webbapp. Mer information finns i Granska dina lagringsalternativ.
Exempel: Lokalt hade webbappen disklagring monterad på varje webbserver, men teamet ville använda en extern datalagringslösning. Relecloud valde Azure Blob Storage av följande skäl:
Säker åtkomst: Webbappen kan eliminera slutpunkter för åtkomst till lagring som exponeras för offentligt Internet med anonym åtkomst.
Kryptering: Den krypterar vilande data och under överföring.
Återhämtning: Den stöder zonredundant lagring (ZRS). Zonredundant lagring replikerar data synkront över tre Azure-tillgänglighetszoner i den primära regionen. Varje tillgänglighetszon finns på en separat fysisk plats som har oberoende ström, kylning och nätverk. Den här konfigurationen bör göra biljettbilderna motståndskraftiga mot förlust.
Slutpunktssäkerhet
Välj att endast aktivera privat åtkomst till Azure-tjänster. Azure Private Link ger åtkomst till lösningar för plattform som en tjänst via en privat slutpunkt i ditt virtuella nätverk. Trafik mellan ditt virtuella nätverk och tjänsten färdas över Microsofts stamnätverk.
Exempel: Relecloud använde Private Link av följande skäl:
Förbättrad säkerhetskommunikation: Det ger programmet privat åtkomst till tjänster på Azure-plattformen och minskar nätverksavtrycket för datalager för att skydda mot dataläckage.
Minimalt arbete: De privata slutpunkterna stöder webbappplattformen och databasplattformen som webbappen använder. Båda plattformarna speglar befintliga lokala konfigurationer för minimal ändring.
Nätverkssäkerhet
Välj om du vill lägga till nätverkssäkerhetstjänster i dina virtuella nätverk. Azure Firewall är tillståndskänslig, nätverksbrandväggen som inspekterar nätverkstrafiken. Med Azure Bastion kan du ansluta till virtuella datorer på ett säkert sätt utan att exponera RDP/SSH-portar.
Exempel: Relecloud antog en nätverkstopologi för nav och ekrar och ville placera delade nätverkssäkerhetstjänster i hubben. Azure Firewall förbättrar säkerheten genom att inspektera all utgående trafik från ekrarna för att öka nätverkssäkerheten. Relecloud behövde Azure Bastion för säkra distributioner från en jump-värd i DevOps-undernätet.
Välj rätt arkitektur
När du har definierat vad som är tillgängligt för din webbapp och valt de bästa molntjänsterna måste du fastställa den bästa arkitekturen för din webbapp. Din arkitektur måste stödja dina affärskrav, tekniska krav och SLO.
Välj arkitekturredundans
Affärsmålen avgör vilken infrastruktur- och dataredundansnivå som webbappen behöver. Webbappens SLO ger en bra baslinje för att förstå dina redundanskrav. Beräkna det sammansatta serviceavtalet alla beroenden för den kritiska sökvägen för tillgänglighet. Beroenden bör omfatta Azure-tjänster och lösningar som inte kommer från Microsoft.
Tilldela en tillgänglighetsuppskattning för varje beroende. Serviceavtal (SLA) är en bra utgångspunkt, men serviceavtalen tar inte hänsyn till kod, distributionsstrategier och beslut om arkitekturanslutning.
Exempel: Relecloud identifierade tjänsterna på den kritiska tillgänglighetsvägen. De använde azure-serviceavtal för tillgänglighetsuppskattningar. Baserat på den sammansatta SLA-beräkningen behövde Relecloud en arkitektur med flera regioner för att uppfylla SLO:et på 99,9 %.
Välj en nätverkstopologi
Välj rätt nätverkstopologi för dina webb- och nätverkskrav. En nätverkstopologi för nav och ekrar är standardkonfigurationen i Azure. Det ger kostnads-, hanterings- och säkerhetsfördelar. Den stöder även hybridanslutningsalternativ till lokala nätverk.
Exempel: Relecloud valde en topologi för nav- och ekernätverk för att öka säkerheten för distributionen i flera regioner till lägre kostnad och hanteringskostnader.
Välj dataredundans
Se till att data är tillförlitliga genom att distribuera dem mellan Azures regioner och tillgänglighetszoner. ju större geografisk separation, desto högre tillförlitlighet.
Ange ett mål för återställningspunkt (RPO). RPO definierar den maximala tillåtna dataförlusten under ett avbrott, som styr hur ofta data behöver replikering. Till exempel innebär ett RPO på en timme att acceptera upp till en timmes dataförlust.
Implementera datareplikering. Justera datareplikeringen med din arkitektur och RPO. Azure stöder vanligtvis synkron replikering i tillgänglighetszoner. Använd flera zoner för att förbättra tillförlitligheten enkelt. För webbappar i flera regioner i en aktiv-passiv konfiguration replikerar du data till den passiva regionen enligt webbappens RPO, vilket säkerställer att replikeringsfrekvensen överskrider RPO. Aktiva-aktiva konfigurationer kräver datasynkronisering i nära realtid mellan regioner, vilket kan kräva kodjusteringar.
Skapa en redundansplan. Utveckla en redundansplan (haveriberedskap) som beskriver svarsstrategier för avbrott, som bestäms av driftstopp eller funktionsförlust. Ange mål för återställningstid (RTO) för maximal acceptabel stilleståndstid. Se till att redundansväxlingsprocessen är snabbare än RTO. Besluta om automatiserade eller manuella redundansmekanismer för konsekvens och kontroll och ange hur du återgår till normal drift. Testa redundansplanen för att säkerställa effektiviteten.
Gå vidare
Den här artikeln visar hur du planerar en implementering av reliable web app-mönstret. Nästa steg är att tillämpa implementeringstekniker för reliable web app-mönstret.