Den här webbläsaren stöds inte längre.
Uppgradera till Microsoft Edge och dra nytta av de senaste funktionerna och säkerhetsuppdateringarna, samt teknisk support.
I den här artikeln beskrivs ett nyckelmönster för verksamhetskritiska arkitekturer i Azure. Använd det här mönstret när du startar designprocessen och välj sedan komponenter som passar bäst för dina affärsbehov. Artikeln rekommenderar en nordstjärna designmetod och innehåller andra exempel med vanliga teknikkomponenter.
Vi rekommenderar att du utvärderar de viktigaste designområdena, definierar de kritiska användar- och systemflöden som använder de underliggande komponenterna och utvecklar en matris med Azure-resurser och deras konfiguration samtidigt som du tänker på följande egenskaper.
| Egenskap | Överväganden |
|---|---|
| Livstid | Vad är den förväntade livslängden för resursen i förhållande till andra resurser i lösningen? Ska resursen överleva eller dela livslängden med hela systemet eller regionen, eller ska den vara tillfällig? |
| Stat | Vilken inverkan kommer det beständiga tillståndet på det här lagret att ha på tillförlitligheten eller hanterbarheten? |
| Nå | Måste resursen distribueras globalt? Kan resursen kommunicera med andra resurser som finns globalt eller inom den regionen? |
| Beroenden | Vilka är beroendena av andra resurser? |
| Skalningsgränser | Vad är den förväntade genomströmningen för den resursen? Hur stor skala tillhandahålls av resursen för att passa den efterfrågan? |
| Tillgänglighet/haveriberedskap | Vad påverkar tillgängligheten från en katastrof på det här lagret? Skulle det orsaka ett systemfel eller bara ett lokaliserat kapacitets- eller tillgänglighetsproblem? |
Viktig
Den här artikeln är en del av Azure Well-Architected verksamhetskritisk arbetsbelastning serie. Om du inte är bekant med den här serien rekommenderar vi att du börjar med vad är en verksamhetskritisk arbetsbelastning?
Vissa resurser delas globalt av resurser som distribueras inom varje region. Vanliga exempel är resurser som används för att distribuera trafik mellan flera regioner, lagra permanent tillstånd för hela programmet och övervaka resurser för dem.
| Egenskap | Överväganden |
|---|---|
| Livstid | Dessa resurser förväntas vara långlivade (icke-tillfälliga). Deras livslängd sträcker sig över systemets livslängd eller längre. Ofta hanteras resurserna med data på plats och kontrollplansuppdateringar, förutsatt att de stöder uppdateringsåtgärder utan stilleståndstid. |
| Stat | Eftersom dessa resurser finns under systemets livslängd är det ofta det här lagret som ansvarar för att lagra globalt, geo-replikerat tillstånd. |
| Nå | Resurserna ska distribueras globalt och replikeras till de regioner som är värdar för dessa resurser. Det rekommenderas att dessa resurser kommunicerar med regionala eller andra resurser med låg svarstid och önskad konsistens. |
| Beroenden | Resurserna bör undvika beroenden av regionala resurser eftersom deras otillgänglighet kan vara en orsak till globala fel. Till exempel kan certifikat eller hemligheter som lagras i ett enda valv ha global inverkan om det uppstår ett regionalt fel där valvet finns. |
| Skalningsgränser | Dessa resurser är ofta singleton-instanser i systemet, och de bör kunna skala så att de kan hantera dataflödet i systemet som helhet. |
| Tillgänglighet/haveriberedskap | Regionala resurser och stämpelresurser kan använda globala resurser. Det är viktigt att globala resurser konfigureras med hög tillgänglighet och katastrofåterställning för hela systemets hälsa. |
Stämpeln innehåller programmet och resurserna som deltar i slutförandet av affärstransaktioner. En stämpel motsvarar vanligtvis en distribution till en Azure-region. Även om en region kan ha mer än en stämpel.
| Kännetecken | Överväganden |
|---|---|
| Livstid | Resurserna förväntas ha en kort livslängd (tillfällig) med avsikten att de kan läggas till och tas bort dynamiskt medan regionala resurser utanför stämpeln fortsätter att finnas kvar. Den tillfälliga naturen behövs för att ge mer återhämtning, skala och närhet till användare. |
| Stat | Eftersom stämplar är kortlivade och kommer att förstöras vid varje användning, bör en stämpel vara tillståndslös i möjligaste mån. |
| Räckvidd | Kan kommunicera med regionala och globala resurser. Kommunikation med andra regioner eller andra stämplar bör dock undvikas. |
| Beroenden | Stämpelresurserna måste vara oberoende. De förväntas ha regionala och globala beroenden men bör inte förlita sig på komponenter i andra stämplar i samma eller andra regioner. |
| Skalningsgränser | Dataflödet fastställs genom testning. Dataflödet för den övergripande stämpeln är begränsat till den resurs som har minst prestanda. Stämpelgenomströmningskapacitet måste uppskatta den hög efterfrågan som orsakas av en avbrottsövergång till en annan stämpel. |
| Tillgänglighet/haveriberedskap | På grund av stämplarnas tillfälliga karaktär utförs haveriberedskap genom omdistribuering av stämpeln. Om resurserna är i ett ohälsosamt tillstånd kan stämpeln som helhet förstöras och återdistribueras. |
Ett system kan ha resurser som distribueras i regionen men som överlever stämpelresurserna. Till exempel observerbarhetsresurser som övervakar resurser på regional nivå, inklusive stämplarna.
| Karakteristisk | Hänsyn |
|---|---|
| Livstid | Resurserna delar regionens livslängd och överlever stämpelresurserna. |
| Stat | Tillstånd som lagras i en region kan inte leva längre än regionens livslängd. Om tillstånd måste delas mellan regioner bör du överväga att använda ett globalt datalager. |
| Nå | Resurserna behöver inte distribueras globalt. Direkt kommunikation med andra regioner bör undvikas till varje pris. |
| Beroenden | Resurserna kan ha beroenden på globala resurser, men inte på stämpelresurser eftersom stämpelresurser är avsedda att vara kortlivade. |
| Skalningsgränser | Fastställa skalningsgränsen för regionala resurser genom att kombinera alla stämplar i regionen. |
Dessa baslinjeexempel fungerar som den rekommenderade nordstjärnans arkitektur för verksamhetskritiska program. Baslinjen rekommenderar starkt containerisering och användning av en containerorkestrerare för programplattformen. Baslinjen använder Azure Kubernetes Service (AKS).
Se Well-Architected verksamhetskritiska arbetsbelastningar: Containerisering.
Om du precis har påbörjat din verksamhetskritiska resa använder du den här arkitekturen som referens. Arbetsbelastningen nås via en offentlig slutpunkt och kräver inte privat nätverksanslutning till andra företagsresurser.
Den här arkitekturen bygger på baslinjearkitekturen. Designen utökas för att tillhandahålla strikta nätverkskontroller för att förhindra obehörig offentlig åtkomst från Internet till arbetsbelastningsresurserna.
Den här arkitekturen är lämplig om du distribuerar arbetsbelastningen i en företagskonfiguration där integrering inom en bredare organisation krävs. Arbetsbelastningen använder centraliserade delade tjänster, behöver lokal anslutning och integreras med andra arbetsbelastningar i företaget. Den distribueras i en Azure-landningszonsprenumeration som ärver från Corp.-hanteringsgruppen.
Den här arkitekturen utökar baslinjereferensen genom att betrakta App Services som den primära programvärdtekniken, vilket ger en lätthanterlig miljö för containerdistributioner.
Vi rekommenderar att du använder den angivna designvägledningen för att navigera i de viktigaste designbesluten för att nå en optimal lösning. Mer information finns i Vilka är de viktigaste designområdena?
Granska metodtipsen för att utforma verksamhetskritiska programscenarier.