Den här artikeln beskriver hur du distribuerar verksamhetskritiska webbprogram med hjälp av Azure App Service. Arkitekturen använder det tillförlitliga webbappsmönstret som utgångspunkt. Använd den här arkitekturen om du har en äldre arbetsbelastning och vill använda PaaS-tjänster (plattform som en tjänst).
Reliable web app pattern for .NET ger vägledning för att uppdatera eller omplatforma webbappar som du flyttar till molnet. Den här metoden hjälper dig att minimera nödvändiga kodändringar och rikta in dig på ett servicenivåmål (SLO) på 99,9%. Verksamhetskritiska arbetsbelastningar har höga krav på tillförlitlighet och tillgänglighet. För att nå ett servicenivåmål på 99,95%, 99,99%eller senare måste du tillämpa kompletterande verksamhetskritiska designmönster och driftstakt. Den här artikeln beskriver viktiga tekniska områden och hur du introducerar och implementerar verksamhetskritiska designmetoder.
Not
Vägledningen i den här artikeln baseras på designmetodik och bästa praxis i Well-Architected Framework verksamhetskritisk arbetsbelastning serien.
I följande avsnitt beskrivs hur du:
- Granska en befintlig arbetsbelastning för att förstå dess komponenter, användar- och systemflöden samt krav på tillgänglighet och skalbarhet.
- Utveckla och implementera en skalningsenhetsarkitektur för att optimera skalbarheten från slutpunkt till slutpunkt genom uppdelning och standardisera processen för att lägga till och ta bort kapacitet.
- Implementera tillståndslösa, tillfälliga skalningsenheter eller distributionsstämplar för att aktivera distributioner med skalbarhet och noll driftstopp.
- Avgör om du kan dela upp arbetsbelastningen i komponenter för att förbereda för skalbarhet. Enskilda komponenter krävs för skalbarhet och avkoppling av flöden.
- Förbered dig för global distribution genom att distribuera en arbetsbelastning i mer än en Azure-region för att förbättra närheten till kunden och förbereda dig för potentiella regionala avbrott.
- Frikoppla komponenter och implementera en händelsedriven arkitektur.
Arkitektur
Följande diagram tillämpar de tidigare övervägandena på det tillförlitliga webbappsmönstret.
Ladda ned en Visio-fil av den här arkitekturen.
Den röda rutan representerar en skalningsenhet med tjänster som skalas tillsammans. Om du vill skala dem effektivt tillsammans optimerar du varje tjänsts storlek, SKU och tillgängliga IP-adresser. Det maximala antalet begäranden som Azure App Configuration hanterar korrelerar till exempel antalet begäranden per sekund som en skalningsenhet tillhandahåller. När du lägger till mer kapacitet i en region måste du också lägga till fler enskilda skalningsenheter.
Dessa enskilda skalningsenheter har inga beroenden på varandra och kommunicerar bara med delade tjänster utanför den enskilda skalningsenheten. Du kan använda dessa skalningsenheter i en blågrön distribution genom att distribuera nya skalningsenheter, verifiera att de fungerar korrekt och gradvis flytta produktionstrafiken till dem.
I det här scenariot betraktar vi skalningsenheter som tillfälliga, vilket optimerar distributionsprocesserna och ger skalbarhet inom och mellan regioner. När du använder den här metoden bör du endast lagra data i databasen eftersom databasen replikeras till den sekundära regionen. Om du behöver lagra data i skalningsenheten bör du överväga att använda Azure Cache for Redis för lagring i skalningsenheten. Om en skalningsenhet måste överges kan lagring av cachen öka svarstiden, men det orsakar inte avbrott.
Application Insights undantas från skalningsenheten. Undanta tjänster som lagrar eller övervakar data. Dela upp dem i en egen resursgrupp med sin egen livscykel.
När du ersätter en skalningsenhet eller distribuerar en ny behåller du historiska data och använder en instans för varje region.
Mer information finns i Programdesign för verksamhetskritiska arbetsbelastningar i Azure.
Komponenter
Den här arkitekturen använder följande komponenter.
- App Service är programvärdplattformen.
- Azure Cache for Redis cachelagrar begäranden.
- App Configuration lagrar konfigurationsinställningar.
- Azure SQL är serverdelsdatabasen.
- Application Insights hämtar telemetri från programmet.
Alternativ
I det tillförlitliga webbappsmönstret kan du:
- Använd Azure Kubernetes Service (AKS) i stället för App Service. Det här alternativet fungerar bra för komplexa arbetsbelastningar som har ett stort antal mikrotjänster. AKS ger mer kontroll över den underliggande infrastrukturen och möjliggör komplexa installationer på flera nivåer.
- Containerisera arbetsbelastningen. App Service stöder containerisering, men i det här exemplet är arbetsbelastningen inte containerbaserad. Använd containrar för att öka tillförlitligheten och portabiliteten.
Mer information finns i Överväganden för programplattform för verksamhetskritiska arbetsbelastningar i Azure.
Överväganden för hög tillgänglighet
Oavsett vilken programplattform du väljer rekommenderar vi att du prioriterar användningen av tillgänglighetszoner för produktionsarbetsbelastningar.
tillgänglighetsuppsättningar sprida distributioner över flera fel- och uppdateringsdomäner i ett datacenter. Tillgänglighetszoner sprida distributioner över enskilda datacenter i en Azure-region. Tillgänglighetszoner prioriteras ofta, men vilken strategi du använder beror på din arbetsbelastning. Till exempel kan svarstidskänsliga eller chattiga arbetsbelastningar ha nytta av att prioritera tillgänglighetsuppsättningar. Om du sprider arbetsbelastningen mellan tillgänglighetszoner kan det öka svarstiden och kostnaden för trafik mellan zoner. När du använder tillgänglighetszoner kontrollerar du att alla tjänster i en skalningsenhet stöder dem. Alla tjänster i det tillförlitliga webbappmönstret stöder tillgänglighetszoner.
Välj dataplattform
Den databasplattform som du väljer påverkar den övergripande arbetsbelastningsarkitekturen, särskilt plattformens stöd för aktiv-aktiv eller aktiv-passiv konfiguration. Det tillförlitliga webbappsmönstret använder Azure SQL, som inte har inbyggt stöd för aktiva-aktiva distributioner som har skrivåtgärder i mer än en instans. I den här konfigurationen är dataplattformen begränsad till en aktiv-passiv strategi. En (partiell) aktiv-aktiv strategi på programnivå är möjlig om det finns skrivskyddade repliker i alla regioner och du bara skriver till en enda region.
Flera databaser är vanliga i komplexa arkitekturer, till exempel mikrotjänstarkitekturer som har en databas för varje tjänst. Med flera databaser kan du använda en databas med flera primära skrivningar, till exempel Azure Cosmos DB, vilket förbättrar hög tillgänglighet och låg svarstid. Svarstid mellan regioner kan skapa begränsningar. Det är viktigt att tänka på icke-funktionella krav och faktorer som konsekvens, driftbarhet, kostnad och komplexitet. Gör det möjligt för enskilda tjänster att använda separata datalager och specialiserade datatekniker för att uppfylla sina unika krav. Mer information finns i dataplattformsöverväganden för verksamhetskritiska arbetsbelastningar i Azure.
Definiera en hälsomodell
I komplexa arbetsbelastningar med flera nivåer som är spridda över flera datacenter och geografiska regioner måste du definiera en hälsomodell.
Så här definierar du en hälsomodell:
- Definiera användar- och systemflöden
- Ange och förstå beroenden mellan tjänsterna
- Förstå vilken effekt avbrott eller prestandaförsämring på någon av tjänsterna kan ha på den övergripande arbetsbelastningen
- Övervaka och visualisera kundupplevelsen för att möjliggöra korrekt övervakning och förbättra manuella och automatiserade åtgärder.
Det föregående diagrammet visar hur ett avbrott eller en försämring av en enskild komponent, till exempel App Configuration, kan orsaka potentiell prestandaförsämring för kunden. När du separerar komponenter i skalningsenheter kan du sluta skicka trafik till den berörda delen av programmet, till exempel en påverkad skalningsenhet eller hela regionen.
Kriterierna för att fastställa hälsotillståndet för en skalningsenhet definieras i hälsomodellen. Den här modellen ansluts sedan till hälsoslutpunkt för skalningsenheten, vilket gör att den globala lastbalanseraren kan köra frågor mot hälsotillståndet för en skalningsenhet och använda den informationen för routningsbeslut.
Mer information finns i Hälsomodellering och observerbarhet för verksamhetskritiska arbetsbelastningar i Azure.
Säkerhet och nätverk
Verksamhetskritiska arbetsbelastningar har strikta nätverks- och säkerhetskrav. Tillämpa flit särskilt på arbetsbelastningar som migrerats från en lokal miljö eftersom inte alla etablerade lokala säkerhetsmetoder översätts till en molnmiljö. Vi rekommenderar att du omvärderar säkerhetskrav under programmigreringen.
Identitet är ofta den primära säkerhetsperimetern för molnbaserade mönster. Företagskunder kan behöva mer omfattande säkerhetsåtgärder. För att uppfylla sina nätverkssäkerhetskrav kan Azure PaaS-tjänster använda Azure Private Link för att implementera nätverket som en säkerhetsperimeter. Private Link hjälper till att säkerställa att tjänster endast är tillgängliga från ett virtuellt nätverk. Alla tjänster är sedan endast tillgängliga via privata slutpunkter. Följande diagram visar hur den enda offentliga Internetuppkopplade slutpunkten är Azure Front Door.
För att det tillförlitliga webbappmönstret ska kunna konfigurera ett nätverk som en säkerhetsperimeter måste det använda:
- Private Link för alla tjänster som stöder det.
- Azure Front Door Premium som den enda internetuppkopplade offentliga slutpunkten.
- Hoppa över rutor för att få åtkomst till tjänster via Azure Bastion.
- Lokalt installerade byggagenter som kan komma åt tjänsterna.
Ett annat vanligt nätverkskrav för verksamhetskritiska program är att begränsa utgående trafik för att förhindra dataexfiltrering. Begränsa utgående trafik genom att dirigera en Azure-brandvägg via en korrekt brandväggsenhet. Filtrera sedan trafik med hjälp av enheten. Den verksamhetskritiska baslinjearkitekturen i Azure med nätverkskontroller använder en brandvägg och Private Link.
Distribution och testning
Driftstopp som orsakas av felaktiga versioner eller mänskliga fel kan vara ett problem för en arbetsbelastning som alltid måste vara tillgänglig. Här är några viktiga områden att tänka på:
- Distributioner med noll stilleståndstid
- Tillfälliga blågröna distributioner
- Livscykelanalys av enskilda och grupperade komponenter
- Kontinuerlig validering
distributioner med noll stilleståndstid är viktiga för verksamhetskritiska arbetsbelastningar. En arbetsbelastning som alltid måste vara igång kan inte ha ett underhållsfönster för att distribuera nyare versioner. För att kringgå den här begränsningen följer den verksamhetskritiska Arkitekturen i Azure mönstret noll driftstopp. Ändringar distribueras som nya skalningsenheter eller stämplar som testas från slutpunkt till slutpunkt innan trafiken dirigeras stegvis till dem. När all trafik dirigeras till den nya stämpeln inaktiveras och tas de gamla stämplarna bort.
Mer information finns i Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure.
Nästa steg
- Utbildningsväg: Skapa verksamhetskritiska arbetsbelastningar i Azure
- Challenge-projekt: Utforma ett verksamhetskritiskt webbprogram
- Learn-modul: Utforma en hälsomodell för din verksamhetskritiska arbetsbelastning