Bearbeiten

Freigeben über

Architekturstil für n-schichtige Anwendungen

Azure Storage
Azure Cloud Services
Azure Virtual Machines

Eine n-schichtige Architektur unterteilt eine Anwendung in logische Ebenen und physische Schichten.

Logisches Diagramm einer n-schichtigen Architektur

Ebenen sind eine Möglichkeit, Zuständigkeiten zu trennen und Abhängigkeiten zu verwalten. Jede Ebene ist mit einer bestimmten Zuständigkeit verknüpft. Eine höhere Ebene kann Dienste in einer niedrigeren Ebene verwenden, nicht jedoch umgekehrt.

Schichten sind physisch getrennt und befinden sich auf verschiedenen Computern. Vertraglich kann die Stufe ihre Kommunikationsmodelle streng oder entspannt haben. Im strikten Modell muss eine Anforderung benachbarte Ebenen nacheinander durchlaufen und zwischen diesen kann keine Ebene dazwischen übersprungen werden. Beispielsweise von der Webanwendungsfirewall zur Webebene, dann zur mittleren Ebene 1 usw. Im Gegensatz dazu kann die Anforderung im entspannten Ansatz einige Ebenen überspringen, wenn dies erforderlich ist. Der strenge Ansatz hat mehr Latenz und Mehraufwand, und der entspannte Ansatz hat mehr Kopplungen und ist anschließend schwieriger zu ändern. Ein System kann einen Hybridansatz verwenden: bei Bedarf sowohl entspannte als auch strenge Ebenen.

Eine Schicht kann eine andere Schicht direkt aufrufen oder über eine Nachrichtenwarteschlange asynchrone Messagingmuster verwenden. Jede Ebene kann auf einer eigenen Schicht gehostet werden, dies ist jedoch nicht erforderlich. Verschiedene Ebenen können auf der gleichen Schicht gehostet werden. Die physische Trennung der Schichten verbessert die Skalierbarkeit und Resilienz, erhöht jedoch aufgrund der zusätzlichen Netzwerkkommunikation die Latenz.

Eine herkömmliche dreischichtige Anwendung besteht aus einer Präsentationsschicht, einer Logikschicht und einer Datenschicht. Die Logikschicht ist optional. Komplexere Anwendungen können mehr als drei Schichten aufweisen. Das Diagramm oben zeigt eine Anwendung mit zwei Logikschichten, die verschiedene Funktionalitätsbereiche kapseln.

Eine n-schichtige Anwendung kann auf einer Architektur mit geschlossenen Ebenen oder einer Architektur mit offenen Ebenen basieren:

  • In einer Architektur mit geschlossenen Ebenen kann eine Ebene nur die direkt darunter liegende Ebene aufrufen.
  • In einer Architektur mit offenen Ebenen kann eine Ebene jede darunter liegende Ebene aufrufen.

Eine Architektur mit geschlossenen Ebenen begrenzt die Abhängigkeiten zwischen den Ebenen. Sie kann jedoch unnötigen Netzwerkdatenverkehr verursachen, wenn eine Ebene Anforderungen einfach nur an die nächste Ebene übergibt.

Einsatzmöglichkeiten für diese Architektur

N-schichtige Architekturen werden in der Regel als IaaS-Anwendungen (Infrastructure-as-a-Service) implementiert, und jede Schicht wird auf einem separaten Satz virtueller Computer ausgeführt. Eine n-schichtige Anwendung muss jedoch nicht ausschließlich auf IaaS basieren. Häufig ist es von Vorteil, für einige Teile der Architektur verwaltete Dienste zu verwenden – dies gilt insbesondere für Caching, Messaging und Datenspeicherung.

Eine n-schichtige Architektur eignet sich gut für folgende Zwecke:

  • Einfache Webanwendungen
  • Ein guter Ausgangspunkt, wenn architekturliche Anforderungen noch nicht klar sind.
  • Migrieren einer lokalen Anwendung zu Azure mit minimalem Umgestaltungsaufwand
  • Einheitliche Entwicklung lokaler und cloudbasierter Anwendungen

N-schichtige Architekturen sind bei herkömmlichen lokalen Anwendungen sehr häufig anzutreffen und eignen sich daher ideal für die Migration vorhandener Workloads zu Azure.

Vorteile

  • Portierbarkeit zwischen cloudbasierten und lokalen Umgebungen sowie zwischen Cloudplattformen
  • Geringer Lernaufwand für die meisten Entwickler
  • Relativ niedrige Kosten, indem die Lösung nicht neu erstellt wird
  • Natürliche Weiterentwicklung des herkömmlichen Anwendungsmodells
  • Offen für heterogene Umgebungen (Windows/Linux)

Herausforderungen

  • Es passiert nur allzu leicht, dass eine Logikschicht verwendet wird, die nur CRUD-Vorgänge in der Datenbank ausführt und damit die Latenz erhöht, ohne wirklich nützliche Aufgaben zu erledigen.
  • Das monolithische Design verhindert die unabhängige Bereitstellung von Features.
  • Die Verwaltung einer IaaS-Anwendung verursacht mehr Arbeit als eine Anwendung, die nur verwaltete Dienste verwendet.
  • Die Verwaltung der Netzwerksicherheit in einem umfangreichen System kann schwierig sein.
  • Benutzer- und Datenflüsse erstrecken sich in der Regel über mehrere Ebenen und fügen Komplexität zu Bedenken wie Tests und Einblicke hinzu.

Bewährte Methoden

  • Verwenden Sie die automatische Skalierung, um Änderungen der Last zu verarbeiten. Weitere Informationen finden Sie unter Bewährte Methoden bei der automatischen Skalierung.
  • Verwenden Sie asynchrones Messaging, um Schichten zu entkoppeln.
  • Speichern Sie halbstatische Daten zwischen. Weitere Informationen finden Sie unter Bewährte Methoden beim Caching.
  • Konfigurieren Sie die Datenbankschicht mithilfe einer Lösung wie SQL Server-Always On-Verfügbarkeitsgruppen für die Hochverfügbarkeit.
  • Platzieren Sie eine Web Application Firewall (WAF) zwischen Front-End und Internet.
  • Platzieren Sie jede Schicht in einem eigenen Subnetz, und verwenden Sie das Subnetz als Sicherheitsgrenze.
  • Beschränken Sie den Zugriff auf die Datenschicht, indem Sie Anforderungen nur aus den Logikschichten zulassen.

N-schichtige Architektur auf virtuellen Computern

In diesem Abschnitt wird eine empfohlene n-schichtige Architektur beschrieben, die auf virtuellen Computern ausgeführt wird.

Physisches Diagramm einer n-schichtigen Architektur

Jede Schicht besteht aus mindestens zwei virtuellen Computern, die sich in einer Verfügbarkeitsgruppe oder einer VM-Skalierungsgruppe befinden. Mehrere virtuelle Computer sorgen für Resilienz, falls ein virtueller Computer ausfällt. Für die Verteilung von Anforderungen auf die virtuellen Computer in einer Schicht werden Lastenausgleichsmodule verwendet. Eine Schicht kann durch Hinzufügen weiterer virtueller Computer zum Pool horizontal skaliert werden.

Jede Schicht wurde zudem in einem eigenen Subnetz platziert, sodass sich die internen IP-Adressen innerhalb des gleichen Adressbereichs befinden. So lassen sich Regeln und Routingtabellen für Netzwerksicherheitsgruppen problemlos auf einzelne Schichten anwenden.

Die Web- und die Businessschicht sind zustandslos. Jeder virtuelle Computer kann jede Anforderung für diese Schicht verarbeitet. Die Datenschicht sollte aus einer replizierten Datenbank bestehen. Unter Windows empfiehlt sich SQL Server sowie die Verwendung von Always On-Verfügbarkeitsgruppen, um Hochverfügbarkeit zu erzielen. Unter Linux wählen Sie eine Datenbank aus, die Replikation unterstützt, z.B. Apache Cassandra.

Netzwerksicherheitsgruppen beschränken den Zugriff auf die einzelnen Schichten. Die Datenbankschicht z.B. gestattet nur den Zugriff aus der Businessschicht.

Hinweis

Die als „Geschäftsebene“ bezeichnete Ebene im Referenzdiagramm ist ein Moniker für die Geschäftslogikebene. Ebenso wird die Darstellungsebene als „Webebene“ bezeichnet. Im vorliegenden Beispiel handelt es sich um eine Webanwendung. Architekturen mit mehreren Ebenen können jedoch auch für andere Topologien verwendet werden, z. B. für Desktop-Apps. Wählen Sie für Ihre Ebenen Namen, mit denen Ihr Team gut arbeiten kann und die die Absicht der jeweiligen logischen und/oder physischen Ebene in Ihrer Anwendung deutlich kommunizieren. Sie könnten dies auch bereits bei den Namen für die Ressourcen umsetzen, die die jeweiligen Ebenen darstellen sollen, z. B. vmss-appName-business-layer (vmss-NameDerApp-geschäftsebene).

Weitere Überlegungen

  • N-schichtige Architekturen sind nicht auf drei Schichten beschränkt. Bei komplexeren Anwendungen ist es üblich, mehrere Schichten zu verwenden. Ziehen Sie in diesem Fall ein Layer-7-Routing in Betracht, um Anforderungen an eine bestimmte Schicht weiterzuleiten.

  • Schichten sind die Grenzen für Skalierbarkeit, Resilienz und Sicherheit. Ziehen Sie in Betracht, separate Schichten für Dienste mit unterschiedlichen Anforderungen in diesen Bereichen einzurichten.

  • Verwenden Sie VM-Skalierungsgruppen für die automatische Skalierung.

  • Suchen Sie nach Stellen in der Architektur, an denen Sie ohne größere Umgestaltung einen verwalteten Dienst verwenden können. Untersuchen Sie in diesem Zusammenhang insbesondere die Bereiche Caching, Messaging, Speicher und Datenbanken.

  • Um die Sicherheit zu erhöhen, platzieren Sie eine Netzwerk-DMU vor der Anwendung. Die DMZ umfasst virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs), die Sicherheitsfunktionen wie z.B. Firewalls und Paketüberprüfung implementieren. Weitere Informationen finden Sie in der Referenzarchitektur für Netzwerk-DMZs.

  • Um Hochverfügbarkeit zu erreichen, platzieren Sie mindestens zwei NVAs in einer Verfügbarkeitsgruppe, und richten Sie ein externes Lastenausgleichsmodul ein, um Internetanforderungen auf die Instanzen zu verteilen. Weitere Informationen finden Sie unter Bereitstellen hochverfügbarer virtueller Netzwerkgeräte.

  • Lassen Sie keinen direkten RDP- oder SSH-Zugriff auf virtuelle Computer zu, die Anwendungscode ausführen. Operatoren sollten sich stattdessen bei einer Jumpbox anmelden, die auch als „Bastion Host“ bezeichnet wird. Dies ist ein virtueller Computer im Netzwerk, über den Administratoren eine Verbindung mit anderen virtuellen Computern herstellen. Die Jumpbox verfügt über eine Netzwerksicherheitsgruppe, die RDP- oder SSH-Zugriff nur von zugelassenen öffentlichen IP-Adressen gestattet.

  • Sie können das virtuelle Azure-Netzwerk auf Ihr lokales Netzwerk ausweiten. Verwenden Sie hierfür ein Site-to-Site-VPN (Virtual Private Network) oder Azure ExpressRoute. Weitere Informationen finden Sie in der Referenzarchitektur für hybride Netzwerke.

  • Wenn Ihre Organisation Active Directory für die Identitätsverwaltung verwendet, empfiehlt es sich möglicherweise, die Active Directory-Umgebung auf das Azure-VNET auszuweiten. Weitere Informationen finden Sie in der Referenzarchitektur zur Identitätsverwaltung.

  • Wenn Sie eine höhere Verfügbarkeit benötigen, als die Azure-SLA für virtuelle Computer bietet, replizieren Sie die Anwendung in zwei Regionen, und verwenden Sie für das Failover den Azure Traffic Manager. Weitere Informationen finden Sie unter Ausführen von Windows-VMs in mehreren Regionen oder Ausführen von Linux-VMs in mehreren Regionen.