Architekturstile

Ein Architekturstil ist eine Familie von Architekturen, die bestimmte Merkmale aufweisen. Beispielsweise ist N-Ebene ein gängiger Architekturstil. In letzter Zeit haben Microservice-Architekturen an Beliebtheit gewonnen. Architekturstile erfordern nicht die Verwendung bestimmter Technologien, aber einige Technologien eignen sich gut für bestimmte Architekturen. Container eignen sich beispielsweise natürlich für Microservices.

Wir haben eine Reihe von Architekturstilen identifiziert, die häufig in Cloudanwendungen zu finden sind. Der Artikel zu den einzelnen Stilen enthält Folgendes:

• Eine Beschreibung und ein logisches Schaubild des Stils.
• Empfehlungen, wann dieser Stil gewählt werden sollte.
• Vorteile, Herausforderungen und bewährte Methoden.
• Eine empfohlene Bereitstellung mit relevanten Azure-Diensten.

Eine kurze Tour durch die Stile

In diesem Abschnitt erhalten Sie eine kurze Übersicht über die von uns identifizierten Architekturstile sowie einige allgemeine Überlegungen zur Verwendung. Bitte beachten Sie, dass die Liste nicht vollständig ist. Weitere Informationen finden Sie in den verknüpften Themen.

N-Ebene

N-Ebene ist eine herkömmliche Architektur für Unternehmensanwendungen. Abhängigkeiten werden verwaltet, indem die Anwendung in Ebenen unterteilt wird, die logische Funktionen ausführen, z. B. Präsentation, Geschäftslogik und Datenzugriff. Eine Ebene kann nur Ebenen aufrufen, die sich darunter befinden. Diese horizontale Schichtung kann jedoch ein Nachteil sein. Es kann schwierig sein, Änderungen in einem Teil der Anwendung einzuführen, ohne den Rest der Anwendung zu berühren. Dies macht häufige Updates zu einer Herausforderung, wodurch eingeschränkt wird, wie schnell neue Features hinzugefügt werden können.

Die N-Ebene eignet sich natürlich für die Migration vorhandener Anwendungen, die bereits eine mehrschichtige Architektur verwenden. Aus diesem Grund wird N-Ebene am häufigsten in Infrastruktur as a Service (IaaS)-Lösungen oder Anwendungen gesehen, die eine Mischung aus IaaS und verwalteten Diensten verwenden.

Web-Warteschlange-Worker

Berücksichtigen Sie für eine rein PaaS-Lösung eine Web-Queue-Worker-Architektur . In diesem Stil verfügt die Anwendung über ein Web-Front-End, das HTTP-Anforderungen und einen Back-End-Worker verarbeitet, der CPU-intensive Aufgaben oder lange ausgeführte Vorgänge ausführt. Das Front-End kommuniziert über eine Warteschlange für asynchrone Nachrichten mit dem Worker.

Web-Queue-Worker eignet sich für relativ einfache Domänen mit einigen ressourcenintensiven Aufgaben. Wie die N-Ebene ist die Architektur leicht zu verstehen. Die Verwendung von verwalteten Diensten vereinfacht die Bereitstellung und den Betrieb. Bei komplexen Domänen kann es jedoch schwierig sein, Abhängigkeiten zu verwalten. Das Front-End und der Arbeiter können leicht zu großen, monolithischen Komponenten werden, die schwer zu warten und zu aktualisieren sind. Wie bei N-Ebenen kann dies die Häufigkeit von Updates reduzieren und Innovationen einschränken.

Microservices

Wenn Ihre Anwendung über eine komplexere Domäne verfügt, sollten Sie die Umstellung auf eine Microservices-Architektur in Betracht ziehen. Eine Microservices-Anwendung besteht aus vielen kleinen, unabhängigen Diensten. Jeder Dienst implementiert eine einzelne Geschäftsfunktion. Dienste sind lose gekoppelt und kommunizieren über API-Verträge.

Jeder Dienst kann von einem kleinen, fokussierten Entwicklungsteam erstellt werden. Einzelne Dienste können ohne viel Koordination zwischen Teams bereitgestellt werden, was häufige Updates fördert. Eine Microservice-Architektur ist komplexer zu erstellen und zu verwalten als die N-Tier-Architektur oder den Web-Queue-Worker. Es erfordert eine reife Entwicklung und DevOps-Kultur. Aber richtig gemacht, kann dieser Stil zu einer höheren Freigabegeschwindigkeit, schnelleren Innovation und einer stabileren Architektur führen.

Ereignisgesteuerte Architektur

Event-Driven Architekturen verwenden ein Veröffentlichungsabonnentmodell (pub-sub), bei dem Produzenten Ereignisse veröffentlichen und Verbraucher sie abonnieren. Die Hersteller sind unabhängig von den Verbrauchern, und die Verbraucher sind voneinander unabhängig.

Betrachten Sie eine ereignisgesteuerte Architektur für Anwendungen, die ein großes Datenvolumen mit sehr geringer Latenz aufnehmen und verarbeiten, z. B. IoT-Lösungen. Die Formatvorlage ist auch nützlich, wenn verschiedene Subsysteme unterschiedliche Verarbeitungstypen für dieselben Ereignisdaten ausführen müssen.

Big Data, Hochleistungsrechnen

Big Data und Big Compute sind spezielle Architekturstile für Workloads, die bestimmten profilen entsprechen. Big Data unterteilt ein sehr großes Dataset in Blöcke, die parallele Verarbeitung über den gesamten Satz hinweg durchführen, zur Analyse und Berichterstellung. Big Compute, auch als High-Performance Computing (HPC) bezeichnet, macht parallele Berechnungen über eine große Zahl (Tausende) von Kernen. Zu den Domänen gehören Simulationen, Modellierung und 3D-Rendering.

Architekturstile als Einschränkungen

Ein Architekturstil platziert Einschränkungen für den Entwurf, einschließlich der Elemente, die angezeigt werden können, und die zulässigen Beziehungen zwischen diesen Elementen. Einschränkungen leiten die "Form" einer Architektur, indem sie die Auswahlmöglichkeiten einschränken. Wenn eine Architektur den Einschränkungen eines bestimmten Stils entspricht, entstehen bestimmte wünschenswerte Eigenschaften.

Zu den Einschränkungen in Microservices gehören beispielsweise:

• Ein Dienst stellt eine einzige Verantwortung dar.
• Jeder Dienst ist unabhängig von den anderen.
• Daten sind privat für den Dienst, der sie besitzt. Dienste teilen keine Daten.

Durch die Einhaltung dieser Einschränkungen entsteht ein System, in dem Dienste unabhängig bereitgestellt werden können, Fehler isoliert sind, häufige Updates möglich sind und es einfach ist, neue Technologien in die Anwendung einzuführen.

Jeder Architekturstil verfügt über eigene Kompromisse. Stellen Sie daher vor der Auswahl eines Architekturstils sicher, dass Sie die zugrunde liegenden Prinzipien und Einschränkungen dieses Stils verstehen. Andernfalls können Sie mit einem Design enden, das dem Stil auf oberflächlicher Ebene entspricht, aber nicht das volle Potenzial dieses Stils erreicht. Sie müssen mehr darauf achten, warum Sie einen bestimmten Architekturstil auswählen, als darauf, wie Sie ihn umsetzen. Es ist auch wichtig, pragmatisch zu sein. Manchmal ist es besser, eine Einschränkung zu entspannen, anstatt auf architektonischer Reinheit zu bestehen.

Die Auswahl eines geeigneten Architekturstils sollte idealerweise im Konsens mit informierten Stakeholdern erfolgen, die an der Arbeitslast beteiligt sind. Das Workloadteam sollte zunächst die Art des Problems identifizieren, das sie lösen möchten. Anschließend sollten sie Geschäftstreiber und entsprechende Architekturmerkmale (auch als nicht funktionale Anforderungen bezeichnet) identifizieren und dann priorisieren. Wenn sie z. B. kürzere Zeit für den Markt benötigen, können sie die Aufrechterhaltung, Testbarkeit und Zuverlässigkeit durch schnelle Bereitstellungsfunktionen priorisieren. Oder wenn das Team, das für die Arbeitsauslastung verantwortlich ist, unter einem eingeschränkten Budget steht, könnten sie die Machbarkeit und Einfachheit bevorzugen. Die Wahl und Pflege eines Architekturstils ist keine einmalige Aktivität, sondern ein kontinuierlicher Ansatz: Die Architektur sollte im Laufe der Zeit kontinuierlich gemessen, validiert und optimiert werden. Es gibt in der Regel erhebliche Kosten für den Wechsel des Architekturstils, sodass mehr Aufwand im Vorfeld für eine langfristige Teameffizienz und Risikominderung gerechtfertigt werden kann.

In der folgenden Tabelle wird zusammengefasst, wie jeder Stil Abhängigkeiten verwaltet, und die Typen von Domäne, die am besten zu jedem Stil passen.

Architekturstil	Abhängigkeitsverwaltung	Domänentyp
N-Ebene	Horizontale Ebenen dividiert durch Subnetz	Traditionelle Geschäftsdomäne. Die Häufigkeit der Updates ist niedrig.
Web-Warteschlange-Worker	Frontend- und Backend-Aufgaben, entkoppelt durch asynchrone Nachrichtenübermittlung.	Relativ einfache Domäne mit einigen ressourcenintensiven Vorgängen.
Microservices	Vertikal (funktionell) dekompilierte Dienste, die sich über APIs gegenseitig aufrufen.	Komplizierte Domäne. Häufige Updates.
Ereignisgesteuerte Architektur	Produzent/Verbraucher. Unabhängige Ansicht pro Untersystem.	IoT- und Echtzeitsysteme.
Big Data	Teilen Sie ein riesiges Dataset in kleine Blöcke auf. Parallele Verarbeitung für lokale Datasets.	Batch- und Echtzeit-Datenanalyse. Prädiktive Analyse mit maschinellem Lernen.
Big Compute	Datenzuweisung an Tausende von Kernen.	Berechnungsintensive Domänen wie Simulation.

Berücksichtigen von Herausforderungen und Vorteilen

Einschränkungen schaffen auch Herausforderungen, daher ist es wichtig, die Nachteile bei der Übernahme dieser Stile zu verstehen. Die Vorteile des Architekturstils überwiegen die Herausforderungen für diese Unterdomäne und den gebundenen Kontext.

Im Folgenden sind einige der Herausforderungen aufgeführt, die beim Auswählen eines Architekturstils zu berücksichtigen sind:

• Komplexität. Ist die Komplexität der Architektur für Ihre Domäne gerechtfertigt? Umgekehrt ist der Stil für Ihre Domäne zu einfach? In diesem Fall riskieren Sie, dass sie mit einer "großen Schlammkugel" enden, da die Architektur Ihnen nicht hilft, Abhängigkeiten sauber zu verwalten.

• Asynchrones Messaging und letztendliche Konsistenz. Asynchrones Messaging kann verwendet werden, um Dienste zu entkoppeln und die Zuverlässigkeit zu erhöhen (da Nachrichten wiederholt werden können) und Skalierbarkeit. Dies führt jedoch auch zu Herausforderungen bei der Behandlung der späteren Konsistenz sowie der Möglichkeit doppelter Nachrichten.

• Dienstübergreifende Kommunikation. Wenn Sie eine Anwendung in separate Dienste dekompilieren, besteht das Risiko, dass die Kommunikation zwischen Diensten zu einer inakzeptablen Latenz führt oder Netzwerküberlastungen (z. B. in einer Microservices-Architektur) verursacht.

• Verwaltbarkeit. Wie schwierig ist es, die Anwendung zu verwalten, zu überwachen, Updates bereitzustellen usw.

Verwandte Ressourcen

• Zehn Designprinzipien für Azure-Anwendungen
• Erstellen von Anwendungen in der Microsoft Cloud
• Bewährte Methoden in Cloudanwendungen
• Cloud-Design-Muster
• Leistungstests und Antipattern für Cloudanwendungen
• Multitenant-Lösungen in Azure entwerfen
• Unternehmenskritische Workloadarchitektur in Azure
• Architektur für Startups