Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
Dieser Artikel enthält ein Schlüsselmuster für unternehmenskritische Architekturen in Azure. Wenden Sie dieses Muster an, wenn Sie den Entwurfsprozess starten, und wählen Sie dann Komponenten aus, die für Ihre Geschäftlichen Anforderungen am besten geeignet sind. Der Artikel empfiehlt einen Polarstern-Entwurfsansatz und enthält weitere Beispiele mit häufig verwendeten Technologiekomponenten.
Es wird empfohlen, die wichtigen Designbereiche zu bewerten, die kritischen Benutzer- und Systemflüsse zu definieren, die die zugrunde liegenden Komponenten verwenden, und eine Matrix von Azure-Ressourcen und deren Konfiguration zu entwickeln, wobei Sie die folgenden Merkmale berücksichtigen.
| Merkmal | Überlegungen |
|---|---|
| Lebensdauer | Was ist die erwartete Lebensdauer der Ressource im Verhältnis zu anderen Ressourcen in der Lösung? Sollte die Ressource die Lebensdauer des gesamten Systems oder der gesamten Region überdauern oder teilen, oder sollte sie vorübergehend sein? |
| Staat | Welche Auswirkungen hat der permanente Zustand auf dieser Ebene auf Zuverlässigkeit oder Verwaltbarkeit? |
| Reach | Muss die Ressource global verteilt werden? Kann die Ressource mit anderen Ressourcen kommunizieren, die sich global oder innerhalb dieser Region befinden? |
| Abhängigkeiten | Was sind die Abhängigkeiten von anderen Ressourcen? |
| Skalierungsgrenzwerte | Was ist der erwartete Durchsatz für diese Ressource? Wie viel Skalierbarkeit wird von der Ressource bereitgestellt, um dieser Nachfrage gerecht zu werden? |
| Verfügbarkeit/Notfallwiederherstellung | Welche Auswirkungen hat eine Katastrophe auf die Verfügbarkeit auf dieser Ebene? Würde dies zu einem systemischen Ausfall oder nur zu einem lokalisierten Kapazitäts- oder Verfügbarkeitsproblem führen? |
Wichtig
Dieser Artikel ist Teil der Reihe geschäftskritischen Azure Well-Architected-Workloads. Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit Was ist ein geschäftskritischer Workload? zu beginnen.
Bestimmte Ressourcen werden global von den Ressourcen geteilt, die in den jeweiligen Regionen bereitgestellt werden. Häufige Beispiele sind Ressourcen, die zum Verteilen von Datenverkehr über mehrere Regionen hinweg verwendet werden, den permanenten Zustand für die gesamte Anwendung speichern und die entsprechenden Ressourcen überwachen.
| Merkmal | Überlegungen |
|---|---|
| Lebensdauer | Es wird erwartet, dass diese Ressourcen langlebig (nicht kurzlebig) sind. Ihre Lebensdauer erstreckt sich über die Lebensdauer des Systems oder länger. Häufig werden die Ressourcen mit lokalen Daten- und Steuerungsebenenupdates verwaltet, wobei vorausgesetzt wird, dass sie Updatevorgänge ohne jegliche Ausfallzeiten unterstützen. |
| Zustand | Da diese Ressourcen mindestens für die Lebensdauer des Systems vorhanden sind, ist diese Ebene häufig für das Speichern des globalen, geo-replizierten Zustands verantwortlich. |
| Reach | Die Ressourcen sollten global verteilt und in die Regionen repliziert werden, in denen diese Ressourcen gehostet werden. Es wird empfohlen, dass diese Ressourcen mit regionalen oder anderen Ressourcen mit geringer Latenz und der gewünschten Konsistenz kommunizieren. |
| Abhängigkeiten | Die Ressourcen sollten Abhängigkeiten von regionalen Ressourcen vermeiden, da ihre Nichtverfügbarkeit eine Ursache für einen globalen Fehler sein kann. Beispielsweise könnten Zertifikate oder Geheimnisse, die in einem einzigen Tresor aufbewahrt werden, globale Auswirkungen haben, wenn ein regionaler Ausfall dort auftritt, wo sich der Tresor befindet. |
| Skalierungsgrenzwerte | Häufig handelt es sich bei diesen Ressourcen um Singletoninstanzen im System, und sie sollten so skaliert werden können, dass sie den Durchsatz des Systems als Ganzes verarbeiten können. |
| Verfügbarkeit/Notfallwiederherstellung | Regionale und Stempelressourcen können globale Ressourcen verwenden. Es ist entscheidend, dass globale Ressourcen mit hoher Verfügbarkeit und Notfallwiederherstellung für die Gesundheit des gesamten Systems konfiguriert sind. |
Der Stempel enthält die Anwendung und die Ressourcen, die an der Durchführung von Geschäftstransaktionen beteiligt sind. Ein Stempel entspricht normalerweise einer Bereitstellung in einer Azure-Region. Obwohl eine Region mehrere Stempel aufweisen kann.
| Merkmal | Überlegungen |
|---|---|
| Lebensdauer | Es wird erwartet, dass diese Ressourcen eine kurze Lebensdauer (kurzlebig) haben werden, mit der Absicht, dass sie dynamisch hinzugefügt und entfernt werden können, während regionale Ressourcen außerhalb des Stempels weiterhin bestehen bleiben. Die kurzlebige Natur ist erforderlich, um benutzern mehr Resilienz, Skalierung und Nähe zu bieten. |
| Zustand | Da Stempel kurzlebig sind und bei jeder Bereitstellung zerstört werden, sollte ein Stempel zustandslos sein soweit möglich. |
| Reach | Kann mit regionalen und globalen Ressourcen kommunizieren. Die Kommunikation mit anderen Regionen oder anderen Briefmarken sollte jedoch vermieden werden. |
| Abhängigkeiten | Die Stempelressourcen müssen unabhängig sein. Es wird erwartet, dass sie regionale und globale Abhängigkeiten haben, aber nicht auf Komponenten in anderen Stempeln in derselben oder anderen Regionen vertrauen sollten. |
| Skalierungsgrenzwerte | Der Durchsatz wird durch Tests bestimmt. Der Durchsatz des gesamten Stempels ist auf die Ressource mit der niedrigsten Leistung begrenzt. Der Stempeldurchsatz muss den Grad des Bedarfs berücksichtigen, der durch ein Failover zu einem anderen Stempel verursacht wird. |
| Verfügbarkeit/Notfallwiederherstellung | Aufgrund der temporären Art von Stempeln erfolgt die Notfallwiederherstellung durch erneutes Bereitstellen des Stempels. Wenn Ressourcen sich in einem fehlerhaften Zustand befinden, kann der Stempel als Ganzes zerstört und erneut bereitgestellt werden. |
Ein System kann über Ressourcen verfügen, die in der Region bereitgestellt sind, die Stempelressourcen aber „überleben“. Beispielsweise können dies Einblickressourcen, die Ressourcen auf regionaler Ebene überwachen, einschließlich Stempeln.
| Merkmal | Aspekt |
|---|---|
| Lebensdauer | Die Ressourcen haben dieselbe Lebensdauer wie die Region und eine längere als die der Stempelressourcen. |
| Staat | Der in einer Region gespeicherte Zustand bleibt nicht über die Lebensdauer der Region hinaus erhalten. Wenn der Zustand regionsübergreifend geteilt werden muss, sollten Sie einen globalen Datenspeicher verwenden. |
| Reach | Die Ressourcen müssen nicht global verteilt werden. Die direkte Kommunikation mit anderen Regionen sollte zu allen Kosten vermieden werden. |
| Abhängigkeiten | Die Ressourcen können Abhängigkeiten von globalen Ressourcen haben, aber nicht von Stempelressourcen, da Stempel kurzlebig sein sollen. |
| Skalierungsgrenzwerte | Bestimmen Sie die Skalierungslimits der regionalen Ressourcen, indem Sie alle Stempel innerhalb der Region kombinieren. |
Diese Basisbeispiele dienen als empfohlene Nordsternarchitektur für unternehmenskritische Anwendungen. Die grundlegende Empfehlung rät dringend zur Containerisierung und zur Verwendung eines Container-Orchestrators für die Anwendungsplattform. Die Basisarchitektur verwendet Azure Kubernetes Service (AKS).
Weitere Informationen finden Sie unter Geschäftskritische Well-Architected Framework-Workloads: Containerisierung.
Wenn Sie Ihre geschäftskritische Journey gerade erst starten, sollten Sie diese Architektur als Referenz verwenden. Auf die Workload wird über einen öffentlichen Endpunkt zugegriffen und erfordert keine private Netzwerkkonnektivität mit anderen Unternehmensressourcen.
Diese Architektur baut auf der Basisarchitektur auf. Das Design wird um die Bereitstellung strenger Netzwerkkontrollen erweitert, die den nicht autorisierten öffentlichen Zugriff aus dem Internet auf die Workloadressourcen verhindern.
Diese Architektur ist geeignet, wenn Sie die Workload in einem Unternehmenssetup bereitstellen, bei dem die Integration in einer breiteren Organisation erforderlich ist. Die Workload verwendet zentralisierte gemeinsame Dienste, benötigt lokale Konnektivität und integriert sich in andere Workloads innerhalb des Unternehmens. Sie wird in einem Azure-Zielzonenabonnement bereitgestellt, das von der Verwaltungsgruppe des Unternehmens abgeleitet ist.
Diese Architektur erweitert die Basisreferenz, indem App Services als primäre Technologie für das Hosten von Anwendungen betrachtet wird, die eine benutzerfreundliche Umgebung für Containerbereitstellungen bietet.
Es wird empfohlen, die bereitgestellten Entwurfsanleitungen zu verwenden, um in den wichtigsten Entwurfsentscheidungen zu navigieren, um eine optimale Lösung zu erreichen. Weitere Informationen finden Sie unter Was sind die wichtigsten Entwurfsbereiche?
Überprüfen Sie die bewährten Methoden zum Entwerfen unternehmenskritischer Anwendungsszenarien.