Den här artikeln beskriver hur du distribuerar verksamhetskritiska webbprogram med hjälp av Azure App Service. Arkitekturen använder det tillförlitliga webbappmönstret som utgångspunkt. Använd den här arkitekturen om du har en äldre arbetsbelastning och vill använda PaaS-tjänster (platform-as-a-service).
Tillförlitligt webbappmönster för .NET ger vägledning för att uppdatera eller omplatforma webbappar som du flyttar till molnet, 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 högre måste du tillämpa kompletterande verksamhetskritiska designmönster och driftstakt. Den här artikeln beskriver viktiga tekniska områden och hur du implementerar och introducerar verksamhetskritiska designmetoder.
Kommentar
Vägledningen i den här artikeln baseras på designmetodik och metodtips i den verksamhetskritiska arbetsbelastningsserien Well-Architected Framework.
I följande avsnitt finns beskrivningar om att:
- Granska den befintliga arbetsbelastningen 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 indelning 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.
- Kontrollera 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 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 med 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 och kommunicerar bara med delade tjänster utanför den enskilda skalningsenheten. Du kan testa oberoende skalningsenheter i förväg. För att undvika att påverka andra distributionsområden distribuerar du oberoende skalningsenheter och introducerar alternativet att ersätta tjänster i en ny version.
För verksamhetskritiska arbetsbelastningar är oberoende skalningsenheter tillfälliga, vilket optimerar distributionsprocesserna och ger skalbarhet inom och mellan regioner. Undvik att lagra tillstånd i oberoende skalningsenheter. Överväg att använda Azure Cache for Redis för lagring i skalningsenheten och lagra endast kritiskt tillstånd eller data som också lagras i databasen. Om det uppstår ett avbrott i skalningsenheten eller om du växlar till en annan skalningsenhet kan det uppstå en avmattning eller en ny inloggning krävs, men Azure Cache for Redis körs fortfarande.
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 per 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.
Välj programplattform
Tillgänglighetsnivån beror på ditt val och din konfiguration av programplattformen. Överväg följande verksamhetskritiska vägledning:
- Använd tillgänglighetszoner när det är möjligt.
- Välj rätt plattformstjänst för din arbetsbelastning.
- Containerisera arbetsbelastningen.
Tillgänglighetsuppsättningar sprider distributioner över flera fel- och uppdateringsdomäner i ett datacenter. Tillgänglighetszoner sprider 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 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 aktiv-aktiva distributioner med skrivåtgärder i mer än en instans. Databasnivån är därför begränsad till en aktiv-passiv strategi. En aktiv-aktiv strategi på programnivå är möjlig om det finns skrivskyddade repliker och du endast skriver till en enda region.
Ladda ned en Visio-fil med den här arkitekturen.
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 fler primär skrivdatabas som 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. Definiera användar- och systemflöden, ange och förstå beroenden mellan tjänsterna, förstå vilken effekt avbrott eller prestandaförsämring på en av tjänsterna kan ha på den övergripande arbetsbelastningen samt ö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.
Mer information finns i Hälsomodellering och observerbarhet för verksamhetskritiska arbetsbelastningar i Azure.
Säkerhet och nätverk
Det finns strikta nätverks- och säkerhetskrav för arbetsbelastningar som migreras från en lokal företagsdistribution. Alla etablerade lokala processer översätts inte till en molnmiljö. Utvärdera dessa krav om de är tillämpliga i molnmiljöer.
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 de flesta Azure PaaS-tjänster använda Azure Private Link för att implementera nätverket som en säkerhetsperimeter. Private Link kan se till att tjänsterna endast är tillgängliga från ett virtuellt nätverk. Alla tjänster är endast tillgängliga via privata slutpunkter. Följande diagram visar hur den enda offentliga Internetuppkopplade slutpunkten är Azure Front Door.
Ladda ned en Visio-fil med den här arkitekturen.
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.
- Jumpboxar 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 och filtrera den med enheten. Den verksamhetskritiska baslinjearkitekturen i Azure med nätverkskontroller använder en brandvägg och Private Link.
Distribution och testning
Stilleståndstid 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
- Analysera livscykeln för enskilda komponenter och gruppera dem tillsammans
- Kontinuerlig validering
Distributioner med noll driftstopp ä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 gamla stämplar bort.
Mer information finns i Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure.
Nästa steg
- Utbildningsväg: Skapa verksamhetskritiska arbetsbelastningar i Azure
- Utmaningsprojekt: Utforma ett verksamhetskritiskt webbprogram
- Learn-modul: Utforma en hälsomodell för din verksamhetskritiska arbetsbelastning