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.
Den här artikeln beskriver 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 de komponenter som passar bäst för dina affärsbehov. Artikeln rekommenderar en metod för nord star design 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? |
| Tillstånd | Vilken inverkan kommer det beständiga tillståndet på det här lagret att ha på tillförlitligheten eller hanterbarheten? |
| Reach | 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 | Vilket dataflöde förväntas för den resursen? Hur mycket skala tillhandahålls av resursen för att passa den efterfrågan? |
| Tillgänglighet/haveriberedskap | Hur påverkas tillgängligheten av en katastrof på det här lagret? Skulle det orsaka ett systemfel eller bara ett lokaliserat kapacitets- eller tillgänglighetsproblem? |
Viktigt
Den här artikeln är en del av azure Well-Architected verksamhetskritiska arbetsbelastningsserie . Om du inte är bekant med den här serien rekommenderar vi att du börjar med 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 över 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 åtgärder för nollstoppsuppdatering. |
| Tillstånd | Eftersom dessa resurser finns under systemets livslängd ansvarar det här lagret ofta för att lagra globalt, geo-replikerat tillstånd. |
| Reach | Resurserna ska distribueras globalt och replikeras till de regioner som är värdar för dessa resurser. Vi rekommenderar att dessa resurser kommunicerar med regionala eller andra resurser med låg svarstid och önskad konsekvens. |
| 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 skalas så att de kan hantera systemets dataflöde 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 haveriberedskap för hela systemets hälsotillstånd. |
Stämpeln innehåller programmet och de resurser som ingår i slutförandet av affärstransaktioner. En stämpel motsvarar vanligtvis en distribution till en Azure-region. Även om en region kan ha fler än en stämpel.
| Egenskap | Ö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. |
| Tillstånd | Eftersom stämplar är tillfälliga och kommer att förstöras för varje distribution, bör en stämpel vara tillståndslös så mycket som möjligt. |
| Reach | 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 upprättas genom testning. Dataflödet för den övergripande stämpeln är begränsat till resursen med minst prestanda. Stämpelgenomflödet måste uppskatta den höga efterfrågan som orsakas av en redundansväxling till en annan stämpel. |
| Tillgänglighet/haveriberedskap | På grund av stämplarnas tillfälliga karaktär utförs haveriberedskap genom omdistribution av stämpeln. Om resurserna är i ett feltillstånd kan stämpeln som helhet förstöras och distribueras om. |
Ett system kan ha resurser som distribueras i regionen men som sänder ut stämpelresurserna. Till exempel observerbarhetsresurser som övervakar resurser på regional nivå, inklusive stämplarna.
| Egenskap | Att tänka på |
|---|---|
| Livstid | Resurserna delar regionens livslängd och lever ut stämpelresurserna. |
| Tillstånd | Tillstånd som lagras i en region får 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. |
| Reach | Resurserna behöver inte distribueras globalt. Direkt kommunikation med andra regioner bör undvikas till varje pris. |
| Beroenden | Resurserna kan ha beroenden av globala resurser, men inte på stämpelresurser eftersom stämplar är avsedda att vara kortvariga. |
| Skalningsgränser | Fastställ skalningsgränsen för regionala resurser genom att kombinera alla stämplar i regionen. |
Dessa baslinjeexempel fungerar som den rekommenderade north star-arkitekturen 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 Väldefinierade 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 ge 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 inom företaget. Den distribueras i en Azure-landningszonprenumeration 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 tillhandahållna 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?
Gå igenom metodtipsen för att utforma verksamhetskritiska programscenarier.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för