Architekturstile

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

Wir haben eine Reihe von Architekturstilen identifiziert, die häufig in Cloudanwendungen zu finden sind. Der Artikel für jeden Designstil enthält die folgenden Komponenten:

• Eine Beschreibung und ein logisches Diagramm des Stils
• Empfehlungen zur Wahl dieses Stils
• Vorteile, Herausforderungen und bewährte Methoden
• Eine empfohlene Bereitstellung, die relevante Azure-Dienste verwendet

Eine kurze Tour durch die Stile

Dieser Abschnitt bietet eine kurze Übersicht über die von uns identifizierten Architekturstile sowie einige allgemeine Überlegungen zur Verwendung. Die Liste ist nicht vollständig. Weitere Informationen finden Sie in den verknüpften Artikeln.

N-Ebene

Das Diagramm veranschaulicht die schichtweise Struktur einer N-Ebenen-Architektur mit klarer Trennung zwischen Komponenten. Clientanforderungen durchlaufen eine Webanwendungsfirewall (WAF), die Sicherheitsfilterung bereitstellt, bevor Sie die Webebene erreichen. Die Webebene dient als Präsentationsschicht. Es verarbeitet Benutzerinteraktionen und Routinganforderungen an geeignete Geschäftslogikkomponenten. Zwei unterschiedliche Verarbeitungspfade ergeben sich aus der Webebene: Ein Pfad fließt direkt zur mittleren Ebene 1 für synchrone Vorgänge, während ein anderer Pfad die Messaginginfrastruktur für die Kommunikation mit mittlerer Ebene 2 für die asynchrone Verarbeitung verwendet. Beide mittleren Ebenen stellen Geschäftslogikebenen dar, die Anforderungen verarbeiten und über Zwischenspeicherungsmechanismen mit der Datenebene interagieren, um die Leistung zu optimieren. Die Datenebene dient als Grundlage. Sie speichert und verwaltet Anwendungsdaten, während beide mittlere Ebenen über zwischengespeicherte Datenzugriffsmuster unterstützt werden.

N-Ebene ist eine herkömmliche Architektur für Unternehmensanwendungen, die eine Anwendung in logische Ebenen und physische Ebenen aufteilen. Jede Ebene hat eine bestimmte Verantwortung, und Ebenen verwalten Abhängigkeiten, indem sie nur die darunterliegenden Ebenen aufrufen. Typische Ebenen umfassen Präsentation, Geschäftslogik und Datenzugriff.

N-Tier-Architekturen eignen sich gut für die Migration vorhandener Anwendungen, die bereits eine mehrschichtige Architektur verwenden. Dieser Ansatz erfordert minimale Änderungen beim Wechsel zu Azure und unterstützt gemischte Umgebungen mit lokalen und Cloudkomponenten. Die horizontale Schichtung kann es jedoch schwierig machen, Änderungen einzuführen, ohne dass sich dies auf mehrere Teile der Anwendung auswirkt, was die Flexibilität für häufige Updates begrenzt.

Web-Warteschlange-Worker

Das Diagramm zeigt eine klare Trennung zwischen komponenten für die Benutzer- und Hintergrundverarbeitung. Clientinteraktionen beginnen mit der Authentifizierung über einen Identitätsanbieter, bevor sie das Web-Front-End erreichen, das als primäre Benutzeroberfläche dient. Das Web-Front-End verwaltet drei unterschiedliche operative Beziehungen: Es kann direkt mit Remotediensten für externe Integrationen kommunizieren, auf die Datenbank für sofortige Datenvorgänge zugreifen und Aufgaben für die Hintergrundverarbeitung in die Warteschlange einreihen. Die Warteschlange dient als Entkoppelungsmechanismus. Sie ermöglicht es der Arbeitskomponente, ressourcenintensive oder lang andauernde Aufgaben unabhängig von Benutzeranforderungen zu verarbeiten. Der Worker holt Aufträge aus der Warteschlange und führt Vorgänge an der Datenbank aus, wobei die Caching-Infrastruktur sowohl das Web-Front-End als auch den Worker für den optimierten Datenzugriff unterstützt. Darüber hinaus werden statische Inhalte über ein Content Delivery Network (CDN) verteilt, um die Leistung für Clientanwendungen zu verbessern.

Web-Queue-Worker ist eine Architektur, die aus einem Web-Front-End, einer Nachrichtenwarteschlange und einem Back-End-Worker besteht. Das Web-Front-End verarbeitet HTTP-Anforderungen und Benutzerinteraktionen, während der Worker ressourcenintensive Aufgaben, lange ausgeführte Workflows oder Batchvorgänge ausführt. Die Kommunikation zwischen Front-End und Worker erfolgt über eine asynchrone Nachrichtenwarteschlange.

Diese Architektur eignet sich ideal für Anwendungen mit relativ einfachen Domänen mit ressourcenintensiven Verarbeitungsanforderungen. Es ist einfach zu verstehen und bereitzustellen mit verwalteten Azure-Diensten wie App Service und Azure Functions. Sie können das Front-End und den Mitarbeiter unabhängig skalieren, um Flexibilität bei der Ressourcenzuordnung zu bieten. Aber ohne sorgfältiges Design können beide Komponenten groß und monolithisch werden.

Microservices

Das Diagramm zeigt eine verteilte Microservices-Architektur, die in unterschiedlichen funktionalen Ebenen organisiert ist. Auf der linken Seite initiieren Clientanwendungen und externe Systeme Anforderungen, die über ein zentrales API-Gateway fließen, das als einzelner Einstiegspunkt und Routingmechanismus für das gesamte System dient. Das API-Gateway leitet Anforderungen an die entsprechende Microservices-Ebene weiter, die mehrere Diensttypen enthält: Domänendienste, die bestimmte Geschäftsfunktionen, Kompositionsdienste, die Interaktionen zwischen Domänendiensten koordinieren, und einzelne Dienste, die diskrete Funktionen verarbeiten. Jeder Microservice verwaltet die Datenautonomie über eine eigene dedizierte Datenbank. Das Diagramm zeigt einen Polyglot-Persistenzansatz, der sowohl SQL- als auch NoSQL-Datenbanken verwendet, die auf die spezifischen Datenanforderungen jedes Diensts zugeschnitten sind. Die Microservices kommunizieren asynchron über nachrichtenorientierte Middleware. Dieser Ansatz ermöglicht eine lose Kopplung über Publish-Subscribe-Muster und ereignisgesteuerte Interaktionen. Drei grundlegende Infrastrukturebenen unterstützen diese verteilte Architektur: Observability-Systeme bieten umfassende Überwachung, Protokollierung und verteilte Ablaufverfolgung über Dienstgrenzen hinweg. Verwaltungs- und Orchestrierungsplattformen handhaben die automatisierte Bereitstellung, Skalierung und Dienstentdeckung. DevOps-Toolketten ermöglichen eine kontinuierliche Integration, Tests und Übermittlungspipeline für unabhängige Dienstbereitstellungen.

Die Microservices-Architektur dekompiliert Anwendungen in eine Sammlung kleiner, autonomer Dienste. Jeder Dienst implementiert eine einzelne Geschäftsfunktion innerhalb eines gebundenen Kontexts und ist eigenständig mit seinem eigenen Datenspeicher. Dienste kommunizieren über klar definierte APIs und können unabhängig entwickelt, bereitgestellt und skaliert werden.

Microservices ermöglichen Es Teams, autonom zu arbeiten und häufige Updates mit höherer Veröffentlichungsgeschwindigkeit zu unterstützen. Diese Architektur eignet sich gut für komplexe Domänen, die häufige Änderungen und Innovationen erfordern. Dies führt jedoch zu erheblicher Komplexität in Bereichen wie Dienstermittlung, Datenkonsistenz und verteilter Systemverwaltung. Erfolg erfordert ausgereifte Entwicklungs- und DevOps-Praktiken, wodurch sie für Organisationen mit erweiterten technischen Fähigkeiten besser geeignet ist.

Ereignisgesteuerte Architektur

Das Diagramm veranschaulicht ein entkoppeltes, asynchrones Kommunikationsmuster, das grundlegend für ereignisgesteuerte Architekturen ist. Mehrere Ereignishersteller arbeiten unabhängig. Die generierten Datenströme von Ereignissen basierend auf Geschäftsaktivitäten, Benutzerinteraktionen oder Systemstatusänderungen ohne Kenntnis der nachgeschalteten Verbraucher. Die Produzenten versorgen ihre Ereignisse in ein zentrales Ereigniseinnahmesystem, das als intelligenter Broker dient. Der Broker empfängt, überprüft, speichert und verteilt zuverlässig Ereignisse innerhalb der Architektur. Die Ereignisaufnahmekomponente dient als kritischer Entkopplungspunkt. Es stellt sicher, dass die Hersteller von Verbrauchern isoliert bleiben, während sie Garantien für die Ereignislieferung, Bestellung und Haltbarkeit bietet. Von diesem zentralen Hub werden Ereignisse über ein Fanoutmuster an mehrere unabhängige Ereigniskonsumenten verteilt, die auf der rechten Seite des Diagramms positioniert sind. Jeder Verbraucher stellt eine unterschiedliche Geschäftsfunktion oder einen dienstspezifischen Dienst dar, der bestimmte Ereignistypen abonniert, die für seine Domänenverantwortung relevant sind. Die Verbraucher verarbeiten Ereignisse asynchron und parallel, sodass das System horizontal skaliert werden kann, während die lose Kopplung beibehalten wird. Dieses Architekturmuster entfernt direkte Abhängigkeiten zwischen Produzenten und Verbrauchern. Dadurch kann jede Komponente unabhängig weiterentwickelt, skaliert und bereitgestellt werden, während die Systemresilienz durch die Puffer- und Wiederholungsfunktionen des Ereignisbrokers beibehalten wird.

Ereignisgesteuerte Architekturen verwenden ein Veröffentlichungsabonnentmodell, bei dem Ereignishersteller Datenströme von Ereignissen generieren und Ereigniskonsumenten auf diese Ereignisse in nahezu Echtzeit reagieren. Produzenten und Verbraucher werden miteinander entkoppelt, wobei die Kommunikation über Ereigniskanäle oder Broker erfolgt. Diese Architektur unterstützt sowohl einfache Ereignisverarbeitung als auch komplexe Ereignismusteranalyse.

Ereignisgesteuerte Architekturen zeichnen sich in Szenarien aus, die eine Echtzeitverarbeitung mit minimaler Latenz erfordern. Einige Beispiele sind IoT-Lösungen, Finanzhandelssysteme oder Anwendungen, die hohe Mengen an Streamingdaten verarbeiten müssen. Ereignisgesteuerte Architekturen bieten hervorragende Skalierbarkeit und Fehlerisolation, stellen jedoch Herausforderungen hinsichtlich garantierter Zustellung, Ereignisbestellung und eventueller Konsistenz über verteilte Komponenten hinweg her.

Big Data

Das Diagramm zeigt eine umfassende Big Data-Architektur mit zwei ergänzenden Verarbeitungspipelines, die unterschiedliche Datengeschwindigkeiten und analytische Anforderungen verarbeiten. Die Batchverarbeitungspipeline beginnt mit verschiedenen Datenquellen, die in skalierbare Datenspeichersysteme einspeisen, wobei es sich typischerweise um Datenseen oder verteilte Dateisysteme handelt, die in der Lage sind, massive Mengen an strukturierten, halbstrukturierten und unstrukturierten Daten zu speichern. Die Batchverarbeitungskomponente führt große Transformationen, Aggregationen und analytische Berechnungen für die historischen Daten durch. Sie arbeitet in geplanten Intervallen oder wenn ausreichende Daten gesammelt werden. Ergebnisse aus Batchverarbeitungsprozessen fließen über zwei Wege: direkt an Analyse- und Berichtssysteme zur direkten Nutzung und in analytische Datenspeicher, in denen verarbeitete Daten in optimierten Formaten für komplexe Abfragen und historische Analysen persistiert werden. Gleichzeitig erfasst die Echtzeitverarbeitungspipeline Streamingdaten über Echtzeitnachrichtenaufnahmesysteme, die Datenströme mit hoher Geschwindigkeit von Quellen wie IoT-Geräten, Webanwendungen oder Transaktionssystemen verarbeiten. Streamverarbeitungskomponenten analysieren diese Daten in Bewegung, führen Echtzeitaggregationen, Filterung und Mustererkennung aus, um sofortige Erkenntnisse zu generieren. Die Echtzeitergebnisse folgen auch dualen Pfaden, indem sie sowohl direkt in Analysen und Berichte für Echtzeit-Dashboards und Warnungen als auch in die gleichen analytischen Datenspeicher einspeisen, um eine einheitliche Ansicht zu erstellen, die historische und aktuelle Daten kombiniert. Die Orchestrierungsebene erstreckt sich über beide Pipelines. Es koordiniert komplexe Workflows, verwaltet Abhängigkeiten zwischen Batch- und Streamingaufträgen, plant Verarbeitungsaufgaben und stellt die Datenkonsistenz in der gesamten Architektur sicher. Mit dieser Orchestrierung können Sie Lambda-Architekturen erstellen, bei denen sowohl Batch- als auch Echtzeitverarbeitung auf denselben Datasets ausgeführt werden können und sowohl umfassende historische Analysen als auch sofortige operative Intelligenz bieten.

Big Data-Architekturen verarbeiten die Erfassung, Verarbeitung und Analyse von Daten, die zu groß oder komplex für herkömmliche Datenbanksysteme sind. Diese Architekturen umfassen in der Regel Komponenten für die Datenspeicherung (z. B. Data Lakes), Batchverarbeitung für historische Analysen, Datenstromverarbeitung für Echtzeiterkenntnisse und analytische Datenspeicher für Berichterstellung und Visualisierung.

Big Data-Architekturen sind für Organisationen unerlässlich, die Erkenntnisse aus massiven Datasets extrahieren, Predictive Analytics mithilfe von maschinellem Lernen unterstützen oder Echtzeitstreamingdaten von IoT-Geräten verarbeiten müssen. Moderne Implementierungen verwenden häufig verwaltete Dienste wie Microsoft Fabric, um die Komplexität des Erstellens und Verwaltens von Big Data-Lösungen zu vereinfachen.

Großrechner

Das Diagramm veranschaulicht ein komplexes Auftragsverteilungs- und Betriebssystem, das für Hochleistungs-Computing-Workloads entwickelt wurde. Am Einstiegspunkt übermitteln Clientanwendungen rechenintensive Aufträge über eine Auftragswarteschlangenschnittstelle, die als Puffer- und Aufnahmemechanismus für eingehende Arbeitsanforderungen fungiert. Die Aufträge fließen in eine zentrale Planungs- oder Koordinatorkomponente, die als intelligentes Gehirn des Systems dient, das für die Analyse von Auftragsmerkmalen, Ressourcenanforderungen und Rechenabhängigkeiten verantwortlich ist. Der Scheduler führt kritische Funktionen aus, einschließlich Auftragsaufteilung, Ressourcenzuordnungsplanung und Arbeitsauslastungsoptimierung basierend auf verfügbaren Rechenressourcen und Vorgangsbeziehungen. Von diesem zentralen Koordinierungspunkt aus leitet der Planer intelligent die Arbeit an zwei unterschiedlichen Betriebspfaden basierend auf den berechnungstechnischen Merkmalen jedes Auftrags. Die erste Pfade leiten parallele Aufgabenbehandlungsumgebungen an, die für peinlich parallele Workloads entwickelt wurden, bei denen einzelne Aufgaben unabhängig ausgeführt werden können, ohne dass eine Kommunikation zwischen Verarbeitungseinheiten erforderlich ist. Diese parallelen Aufgaben werden über Hunderte oder Tausende von Kernen gleichzeitig verteilt, wobei jeder Kern diskrete Arbeitseinheiten isoliert verarbeitet. Der zweite Pfad behandelt eng gekoppelte Aufgaben, die häufige Prozesskommunikation, gemeinsam genutzten Speicherzugriff oder synchronisierte Vorgangsmuster erfordern. Diese eng gekoppelten Workloads verwenden in der Regel Hochgeschwindigkeitsverbindungen wie InfiniBand- oder Remote-Direct Memory Access (RDMA)-Netzwerke, um einen schnellen Datenaustausch zwischen Verarbeitungsknoten zu ermöglichen. Der Scheduler überwacht kontinuierlich beide Betriebsumgebungen, verwaltet die Ressourcenzuordnung, verarbeitet Fehlertoleranz und optimiert die Leistung, indem die Verteilung der Arbeit basierend auf Systemkapazität, Auftragsprioritäten und Abschlussanforderungen dynamisch angepasst wird. Der bidirektionale Ansatz ermöglicht es der Architektur, verschiedene Rechenarbeitslasten effizient zu verarbeiten und gleichzeitig die Ressourcennutzung in der gesamten Computerinfrastruktur zu maximieren.

Große Computearchitekturen unterstützen große Workloads, die Hunderte oder Tausende von Kernen für rechenintensive Vorgänge erfordern. Die Arbeit kann in diskrete Aufgaben aufgeteilt werden, die gleichzeitig über viele Kerne hinweg ausgeführt werden, wobei jede Aufgabe Eingaben übernimmt, sie verarbeitet und Die Ausgabe erzeugt. Aufgaben können unabhängig (peinlich parallel) oder eng gekoppelt sein, die eine schnelle Kommunikation erfordern.

Big Compute ist für Simulationen, Finanzrisikomodellierung, wissenschaftliches Computing, technische Stressanalyse und 3D-Rendering unerlässlich. Azure bietet Optionen wie Azure Batch für verwaltete große Computearbeitslasten oder HPC Pack für herkömmlichere Clusterverwaltung. Diese Architekturen können bei Bedarf Kapazität schnell erweitern und auf Tausende Kerne skalieren.

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.

Wenn Sie diese Einschränkungen einhalten, erhalten Sie ein System, mit dem Sie die folgenden Aktionen ausführen können:

• Stellen Sie Dienste unabhängig bereit.
• Fehler isolieren.
• Nehmen Sie häufigere Updates vor.
• Neue Technologien einfacher in die Anwendung einführen.

Jeder Architekturstil verfügt über eigene Kompromisse. Bevor Sie einen Architekturstil auswählen, ist es wichtig, die zugrunde liegenden Prinzipien und Einschränkungen zu verstehen. Ohne dieses Verständnis riskieren Sie, ein Design zu erstellen, das oberflächlich dem Stil entspricht, ohne dessen volle Vorteile zu erkennen. Konzentrieren Sie sich mehr darauf, warum Sie einen bestimmten Stil wählen, als darauf, wie Sie ihn umsetzen. Seien Sie praktisch. Manchmal ist es besser, eine Einschränkung zu lockern, als technische Reinheit zu verfolgen.

Im Idealfall sollte die Wahl des Architekturstils mit Beiträgen von informierten Arbeitsauslastungsbeteiligten getroffen werden. Das Workloadteam sollte damit beginnen, die Art des Problems zu identifizieren, das sie lösen. Anschließend sollten sie die wichtigsten Geschäftstreiber und die entsprechenden Architekturmerkmale definieren, auch als nichtfunktionelle Anforderungen bezeichnet und priorisiert werden. Wenn beispielsweise Zeit für den Markt kritisch ist, kann das Team Die Wartbarkeit, Testbarkeit und Zuverlässigkeit priorisieren, um eine schnelle Bereitstellung zu ermöglichen. Wenn das Team enge Budgeteinschränkungen aufweist, kann die Machbarkeit und Einfachheit Vorrang haben. Die Auswahl und Erhaltung eines Architekturstils ist keine einmalige Aufgabe. Sie erfordert fortlaufende Messungen, Validierung und Verfeinerung. Da eine spätere Änderung der Architekturrichtung kostspielig sein kann, lohnt es sich oft, im Vorfeld mehr Aufwand zu investieren, um die langfristige Effizienz zu unterstützen und Risiken zu reduzieren.

In der folgenden Tabelle wird zusammengefasst, wie jede Formatvorlage Abhängigkeiten verwaltet, und die Domänentypen, die für jede Formatvorlage am besten geeignet sind.

Architekturstil	Abhängigkeitsverwaltung	Domänentyp
N-Ebene	Horizontale Ebenen dividiert durch Subnetz	Traditionelle Geschäftsdomäne. Die Häufigkeit der Updates ist niedrig.
Web-Queue-Worker	Front-End- und Back-End-Jobs, 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	Hersteller oder Verbraucher. Unabhängige Ansicht für jedes Subsystem.	Internet of Things (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 durch die Verwendung von 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 zu verstehen, wenn Sie eines dieser Stile übernehmen. Ermitteln Sie, ob die Vorteile des Architekturstils die Herausforderungen für diese Unterdomäne und den gebundenen Kontext überwiegen.

Berücksichtigen Sie beim Auswählen eines Architekturstils die folgenden Arten von Herausforderungen:

• Kompliziertheit: Die Komplexität der Architektur muss mit der Domäne übereinstimmen. Wenn es zu einfach ist, kann es zu einem großen Schlammball führen, in dem Abhängigkeiten nicht gut verwaltet werden und die Struktur zerbricht.

• Asynchrones Messaging und letztendliche Konsistenz: Asynchrones Messaging wird verwendet, um Dienste zu entkoppeln und die Zuverlässigkeit zu verbessern, da Nachrichten wiederholt werden können. Es verbessert auch die Skalierbarkeit. Asynchrone Nachrichtenübermittlung führt jedoch auch zu Herausforderungen bei der Behandlung der eventuellen Konsistenz und der Möglichkeit doppelter Nachrichten.

• Interservice-Kommunikation: Durch das Dekompilieren einer Anwendung in separate Dienste kann der Kommunikationsaufwand erhöht werden. In Microservices-Architekturen führt dieser Overhead häufig zu Latenzproblemen oder Netzwerküberlastungen.

• Fügsamkeit: Die Verwaltung der Anwendung umfasst Aufgaben wie Überwachung, Bereitstellen von Updates und Verwalten des Betriebszustands.

Verwandte Ressourcen

• Zehn Designprinzipien für Azure-Anwendungen

Nächste Schritte

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