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.
In diesem Artikel wird ein Schlüsselmuster für unternehmenskritische Architekturen in Azure vorgestellt. Wenden Sie dieses Muster an, wenn Sie mit dem Entwurfsprozess beginnen, und wählen Sie dann Komponenten aus, die für Ihre Geschäftsanforderungen am besten geeignet sind. Der Artikel empfiehlt einen Entwurf von star Norden und enthält weitere Beispiele mit gängigen Technologiekomponenten.
Es wird empfohlen, die wichtigsten Entwurfsbereiche auszuwerten, die kritischen Benutzer- und Systemflows zu definieren, die die zugrunde liegenden Komponenten verwenden, und eine Matrix mit Azure-Ressourcen und deren Konfiguration zu entwickeln, wobei die folgenden Merkmale zu berücksichtigen sind.
| Merkmal | Überlegungen |
|---|---|
| Lebensdauer | Wie lautet die erwartete Lebensdauer der Ressource im Verhältnis zu anderen Ressourcen in der Lösung? Sollte die Ressource eine länger oder dieselbe Lebensdauer wie das gesamte System oder die gesamte Region haben, oder sollte sie nur vorübergehend sein? |
| State | Welche Auswirkungen hat der persistente Zustand auf dieser Ebene auf Zuverlässigkeit oder Verwaltbarkeit? |
| Reach | Ist es erforderlich, dass die Ressource global verteilt wird? Kann die Ressource mit anderen Ressourcen kommunizieren, die sich global oder innerhalb dieser Region befinden? |
| Abhängigkeiten | Welche Abhängigkeiten bestehen von anderen Ressourcen? |
| Skalierungslimits | Wie lautet der erwartete Durchsatz für diese Ressource? Wie viel Skalierung wird von der Ressource zur Anpassung an diese Nachfrage bereitgestellt? |
| Verfügbarkeit/Notfallwiederherstellung | Welche Auswirkungen hat ein Notfall auf dieser Ebene auf die Verfügbarkeit? Würde dies zu einem systemischen Ausfall oder nur zu einem Problem mit lokalisierter Kapazität oder Verfügbarkeit führen? |
Wichtig
Dieser Artikel ist Teil der Unternehmenskritisch-Workloadreihe von Azure Well-Architected . Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit einer unternehmenskritischen Workload zu beginnen?
Bestimmte Ressourcen werden von Ressourcen, die in jeder Region bereitgestellt werden, global gemeinsam genutzt. Häufige Beispiele sind Ressourcen, die verwendet werden, um Datenverkehr über mehrere Regionen zu verteilen, den permanenten Zustand für die gesamte Anwendung zu speichern und ressourcen dafür zu überwachen.
| Merkmal | Überlegungen |
|---|---|
| Lebensdauer | Es wird erwartet, dass diese Ressourcen langlebig (nicht kurzlebig) sind. Ihre Lebensdauer umfasst die Lebensdauer des Systems oder mehr. Häufig werden die Ressourcen mit lokalen Daten- und Steuerungsebenenupdates verwaltet, wobei vorausgesetzt wird, dass sie Updatevorgänge ohne jegliche Ausfallzeiten unterstützen. |
| State | Da diese Ressourcen mindestens für die Lebensdauer des Systems existieren, ist diese Ebene häufig für das Speichern globaler, georeplizierter Zustände 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 globale Fehler sein kann. Beispielsweise könnten Zertifikate oder Geheimnisse, die in einem einzelnen Tresor aufbewahrt werden, globale Auswirkungen haben, wenn es am Standort des Tresors zu einem regionalen Ausfall kommt. |
| Skalierungslimits | Häufig handelt es sich bei diesen Ressourcen um Singletoninstanzen im System, und sie sollten in der Lage sein, so zu skalieren, dass sie den Durchsatz des gesamten Systems verarbeiten können. |
| Verfügbarkeit/Notfallwiederherstellung | Regionale Ressourcen und Stempelressourcen können globale Ressourcen verwenden. Es ist wichtig, dass globale Ressourcen mit Hochverfügbarkeit und Notfallwiederherstellung für die Integrität des gesamten Systems konfiguriert werden. |
Der Stempel enthält die Anwendung und die Ressourcen, die am Abschließen von Geschäftstransaktionen beteiligt sind. Ein Stempel entspricht normalerweise einer Bereitstellung in einer Azure-Region. Obwohl eine Region über mehr als einen Stempel verfügen 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 höhere Resilienz, Skalierung und Nähe zu Benutzern bereitzustellen. |
| State | Da Stempel kurzlebig sind und bei jeder Bereitstellung zerstört werden, sollte ein Stempel so weit wie möglich zustandslos sein. |
| Reach | Kann mit regionalen und globalen Ressourcen kommunizieren. Die Kommunikation mit anderen Regionen oder anderen Stempeln 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 basieren sollten. |
| Skalierungslimits | Der Durchsatz wird durch Tests bestimmt. Der Durchsatz des gesamten Stempels ist auf die Ressource mit der niedrigsten Leistung begrenzt. Der Stempeldurchsatz muss den hohen Bedarf schätzen, der durch ein Failover auf einen anderen Stempel verursacht wird. |
| Verfügbarkeit/Notfallwiederherstellung | Aufgrund der temporären Natur von Stempeln erfolgt die Notfallwiederherstellung durch erneute Bereitstellung 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“. Beispiel: Überwachungsressourcen, die Ressourcen auf regionaler Ebene überwachen, einschließlich der Stempel.
| Merkmal | Aspekt |
|---|---|
| Lebensdauer | Die Ressourcen haben dieselbe Lebensdauer wie die Region und eine längere als die der Stempelressourcen. |
| State | Der in einer Region gespeicherte Zustand kann nicht über die Lebensdauer der Region hinaus leben. Wenn der Zustand regionsübergreifend geteilt werden muss, sollten Sie einen globalen Datenspeicher verwenden. |
| Reach | Die Ressourcen müssen nicht global verteilt sein. Direkte Kommunikation mit anderen Regionen sollte unter allen Umständen vermieden werden. |
| Abhängigkeiten | Die Ressourcen können Abhängigkeiten von globalen Ressourcen haben, aber nicht von Stempelressourcen, da Stempel als kurzlebig konzipiert sind. |
| Skalierungslimits | Bestimmen Sie die Skalierungslimits der regionalen Ressourcen, indem Sie alle Stempel innerhalb der Region kombinieren. |
Diese Basisbeispiele dienen als empfohlene Nord-star-Architektur für unternehmenskritische Anwendungen. Die Baseline empfiehlt dringend die Containerisierung und die Verwendung eines Containerorchestrators für die Anwendungsplattform. Die Baseline verwendet Azure Kubernetes Service (AKS).
Weitere Informationen finden Sie unter Unternehmenskritische Workloads mit Well-Architected: Containerisierung.
Wenn Sie gerade erst mit Ihrer unternehmenskritischen Reise beginnen, verwenden Sie diese Architektur als Referenz. Der Zugriff auf die Workload erfolgt über einen öffentlichen Endpunkt und erfordert keine private Netzwerkkonnektivität mit anderen Unternehmensressourcen.
Diese Architektur baut auf der Basisarchitektur auf. Der Entwurf wurde erweitert, um strenge Netzwerkkontrollen bereitzustellen, um nicht autorisierten öffentlichen Zugriff aus dem Internet auf die Workloadressourcen zu verhindern.
Diese Architektur eignet sich, wenn Sie die Workload in einem Unternehmenssetup bereitstellen, in dem die Integration in eine umfassendere organization erforderlich ist. Die Workload verwendet zentralisierte freigegebene Dienste, benötigt lokale Konnektivität und lässt sich in andere Workloads innerhalb des Unternehmens integrieren. Sie wird in einem Azure-Zielzonenabonnement bereitgestellt, das von der Unternehmensverwaltungsgruppe erbt.
Diese Architektur erweitert die Basisreferenz, indem App Services als primäre Anwendungshostingtechnologie betrachtet wird und eine benutzerfreundliche Umgebung für Containerbereitstellungen bereitgestellt wird.
Es wird empfohlen, den bereitgestellten Entwurfsleitfaden zu verwenden, um die wichtigsten Entwurfsentscheidungen zu steuern, um eine optimale Lösung zu erzielen. Weitere Informationen finden Sie unter Was sind die wichtigsten Entwurfsbereiche?
Überprüfen Sie die bewährten Methoden für das Entwerfen unternehmenskritischer Anwendungsszenarien.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für