Deze browser wordt niet meer ondersteund.
Upgrade naar Microsoft Edge om te profiteren van de nieuwste functies, beveiligingsupdates en technische ondersteuning.
Dit artikel bevat een sleutelpatroon voor bedrijfskritieke architecturen in Azure. Pas dit patroon toe wanneer u het ontwerpproces start en selecteer vervolgens onderdelen die het meest geschikt zijn voor uw zakelijke vereisten. In het artikel wordt een north star-ontwerpbenadering aanbevolen en worden andere voorbeelden met algemene technologieonderdelen beschreven.
We raden u aan de belangrijkste ontwerpgebieden te evalueren, de kritieke gebruikers- en systeemstromen te definiëren die gebruikmaken van de onderliggende onderdelen, en een matrix van Azure-resources en hun configuratie te ontwikkelen, waarbij u rekening houdt met de volgende kenmerken.
| Kenmerk | Overwegingen |
|---|---|
| Levensduur | Wat is de verwachte levensduur van de resource ten opzichte van andere resources in de oplossing? Moet de resource overleven of de levensduur delen met het hele systeem of de hele regio, of moet deze tijdelijk zijn? |
| Staat | Welke invloed heeft de persistente status op deze laag op de betrouwbaarheid of beheerbaarheid? |
| Reach | Moet de resource wereldwijd worden gedistribueerd? Kan de resource communiceren met andere resources die zich wereldwijd of binnen die regio bevinden? |
| Afhankelijkheden | Wat zijn de afhankelijkheden van andere resources? |
| Schaallimieten | Wat is de verwachte doorvoer voor die resource? Hoeveel schaal wordt door de resource geleverd om aan die vraag te voldoen? |
| Beschikbaarheid/herstel na noodgevallen | Wat is de impact op de beschikbaarheid van een noodgeval in deze laag? Zou dit een systeemstoring veroorzaken of alleen een probleem met gelokaliseerde capaciteit of beschikbaarheid? |
Belangrijk
Dit artikel maakt deel uit van de reeks bedrijfskritische workloads van Azure Well-Architected . Als u niet bekend bent met deze reeks, raden we u aan te beginnen met wat is een essentiële workload?
Bepaalde resources worden wereldwijd gedeeld door resources die binnen elke regio zijn geïmplementeerd. Veelvoorkomende voorbeelden zijn resources die worden gebruikt voor het distribueren van verkeer over meerdere regio's, het opslaan van de permanente status voor de hele toepassing en het bewaken van resources voor deze resources.
| Kenmerk | Overwegingen |
|---|---|
| Levensduur | Van deze resources wordt verwacht dat ze lang leven (niet-kortstondig). Hun levensduur beslaat de levensduur van het systeem of langer. Vaak worden de resources beheerd met in-place gegevens- en besturingsvlakupdates, ervan uitgaande dat ze updatebewerkingen zonder downtime ondersteunen. |
| Staat | Omdat deze resources ten minste de levensduur van het systeem hebben, is deze laag vaak verantwoordelijk voor het opslaan van de globale, geo-gerepliceerde status. |
| Reach | De resources moeten wereldwijd worden gedistribueerd en gerepliceerd naar de regio's waar deze resources worden gehost. Het is raadzaam dat deze resources communiceren met regionale of andere resources met lage latentie en de gewenste consistentie. |
| Afhankelijkheden | De resources moeten afhankelijkheden van regionale resources vermijden, omdat hun onbeschikbaarheid een oorzaak kan zijn van globale fouten. Certificaten of geheimen die in één kluis worden bewaard, kunnen bijvoorbeeld globale gevolgen hebben als er een regionale fout optreedt in de locatie van de kluis. |
| Schaallimieten | Vaak zijn deze resources singleton-exemplaren in het systeem en moeten ze zodanig kunnen worden geschaald dat ze de doorvoer van het systeem als geheel kunnen verwerken. |
| Beschikbaarheid/herstel na noodgevallen | Regionale resources en stempelresources kunnen gebruikmaken van globale resources. Het is essentieel dat wereldwijde resources zijn geconfigureerd met hoge beschikbaarheid en herstel na noodgevallen voor de status van het hele systeem. |
Het stempel bevat de toepassing en resources die deelnemen aan het voltooien van zakelijke transacties. Een stempel komt doorgaans overeen met een implementatie in een Azure-regio. Hoewel een regio meer dan één stempel kan hebben.
| Kenmerk | Overwegingen |
|---|---|
| Levensduur | De resources hebben naar verwachting een korte levensduur (kortstondig) met de bedoeling dat ze dynamisch kunnen worden toegevoegd en verwijderd, terwijl regionale resources buiten de zegel blijven bestaan. De tijdelijke aard is nodig om gebruikers meer flexibiliteit, schaal en nabijheid te bieden. |
| Staat | Omdat zegels kortstondig zijn en bij elke implementatie worden vernietigd, moet een stempel zoveel mogelijk staatloos zijn. |
| Reach | Kan communiceren met regionale en wereldwijde resources. Communicatie met andere regio's of andere stempels moet echter worden vermeden. |
| Afhankelijkheden | De zegelresources moeten onafhankelijk zijn. Ze hebben naar verwachting regionale en globale afhankelijkheden, maar mogen niet afhankelijk zijn van onderdelen in andere stempels in dezelfde of andere regio's. |
| Schaallimieten | De doorvoer wordt vastgesteld door middel van tests. De doorvoer van de algehele zegel is beperkt tot de minst presterende resource. Zegeldoorvoer moet het hoge vraagniveau schatten dat wordt veroorzaakt door een failover naar een andere stempel. |
| Beschikbaarheid/herstel na noodgevallen | Vanwege de tijdelijke aard van stempels wordt herstel na noodgevallen uitgevoerd door de stempel opnieuw te implementeren. Als resources een slechte status hebben, kan het stempel als geheel worden vernietigd en opnieuw worden geïmplementeerd. |
Een systeem kan resources hebben die in de regio worden geïmplementeerd, maar de zegelresources overleven. Bijvoorbeeld waarneembaarheidsresources die resources op regionaal niveau bewaken, inclusief de stempels.
| Kenmerk | Overweging |
|---|---|
| Levensduur | De resources delen de levensduur van de regio en live de zegelresources. |
| Staat | De status die is opgeslagen in een regio, kan niet langer duren dan de levensduur van de regio. Als de status moet worden gedeeld tussen regio's, kunt u overwegen om een globaal gegevensarchief te gebruiken. |
| Reach | De resources hoeven niet wereldwijd te worden gedistribueerd. Directe communicatie met andere regio's moet koste wat het kost worden vermeden. |
| Afhankelijkheden | De resources kunnen afhankelijk zijn van globale resources, maar niet van zegelresources, omdat stempels bedoeld zijn voor een korte levensduur. |
| Schaallimieten | Bepaal de schaallimiet voor regionale resources door alle stempels binnen de regio te combineren. |
Deze basislijnvoorbeelden fungeren als de aanbevolen north star-architectuur voor bedrijfskritieke toepassingen. In de basislijn wordt ten zeerste aanbevolen containerisatie en het gebruik van een containerorchestrator voor het toepassingsplatform. De basislijn maakt gebruik van Azure Kubernetes Service (AKS).
Raadpleeg Goed ontworpen bedrijfskritische workloads: Containerisatie.
Als u net begint met uw missiekritieke traject, gebruikt u deze architectuur als referentie. De workload is toegankelijk via een openbaar eindpunt en vereist geen privénetwerkverbinding met andere bedrijfsresources.
Deze architectuur bouwt voort op de basislijnarchitectuur. Het ontwerp is uitgebreid om strikte netwerkcontroles te bieden om onbevoegde openbare toegang vanaf internet tot de workloadresources te voorkomen.
Deze architectuur is geschikt als u de workload implementeert in een bedrijfsinstallatie waarbij integratie binnen een bredere organisatie vereist is. De workload maakt gebruik van gecentraliseerde gedeelde services, heeft on-premises connectiviteit nodig en kan worden geïntegreerd met andere workloads binnen de onderneming. Het wordt geïmplementeerd in een Azure-landingszone-abonnement dat wordt overgenomen van de corp.-beheergroep.
Deze architectuur breidt de referentiebasislijn uit door App Services te beschouwen als de primaire technologie voor het hosten van toepassingen, wat een gebruiksvriendelijke omgeving biedt voor containerimplementaties.
We raden u aan de opgegeven ontwerprichtlijnen te gebruiken om door de belangrijkste ontwerpbeslissingen te navigeren om tot een optimale oplossing te komen. Zie Wat zijn de belangrijkste ontwerpgebieden? voor meer informatie.
Bekijk de best practices voor het ontwerpen van bedrijfskritieke toepassingsscenario's.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor