Drei-Schichten-Architektur als Diagramm: Präsentation, Anwendung und Daten

Die Drei-Schichten-Architektur ist die Form, die die meisten Webanwendungen unter der Haube immer noch haben: etwas, das die Benutzeroberfläche ausliefert, etwas, das die Geschäftslogik ausführt, und etwas, das die Daten speichert. Sie ist alt, sie ist langweilig, und sie ist für die meisten Systeme der richtige Ausgangspunkt, weil jede Schicht für sich skaliert und abgesichert werden kann.

Dieser Artikel erklärt die drei Schichten, zeigt, wie sie sich mit Subnetzen und Security Groups auf ein Cloud-Netzwerk abbilden, und zeichnet ein typisches AWS-Deployment über zwei Availability Zones. Dieselbe Struktur funktioniert in jeder Cloud.

Die drei Schichten

Die Regel, die daraus eine Architektur und nicht nur drei Kästen macht: Jede Schicht spricht nur mit ihrem Nachbarn. Der Browser erreicht nie die Datenbank, und die Präsentationsschicht führt nie SQL aus.

AWS beschreibt das Muster in seinem Überblick über die Drei-Schichten-Architektur, einschließlich Serverless-Varianten, in denen Funktionen die Anwendungsserver ersetzen.

Schichten auf das Netzwerk abbilden

Schichten werden zu echten Grenzen, wenn sie in verschiedenen Subnetzen mit verschiedenen Routen leben:

• Öffentliche Subnetze enthalten nur, was aus dem Internet erreichbar sein muss: den Load Balancer und NAT-Gateways.
• Private Anwendungssubnetze enthalten die App-Server. Sie können über NAT ausgehend ins Internet, etwa für Updates und APIs, aber von außen erreicht sie nichts außer über den Load Balancer.
• Private Datensubnetze enthalten Datenbanken und Caches, ganz ohne Route ins Internet.

Security Groups erlauben dann nur den Traffic des Nachbarn: Die Datenbank akzeptiert Port 5432 nur von der Security Group der Anwendungsschicht, nicht von einem IP-Bereich. Gruppen statt Adressen zu referenzieren hält die Regeln korrekt, während Instanzen kommen und gehen.

Hochverfügbarkeit über Zonen

Betreibe jede Schicht in mindestens zwei Availability Zones:

• Der Load Balancer erstreckt sich von Haus aus über Zonen.
• App-Server laufen in einer Autoscaling-Gruppe mit Instanzen in jeder Zone. Fällt eine Zone aus, übernehmen die anderen den Traffic, und die Gruppe ersetzt die Kapazität.
• Die Datenbank läuft mit einem synchronen Standby in einer anderen Zone. Mit Amazon RDS Multi-AZ erfolgt das Failover auf den Standby automatisch, und der Endpunktname bleibt gleich.

Halte die Anwendungsschicht zustandslos, damit jede Instanz jede Anfrage bedienen kann: Sessions gehen in einen gemeinsamen Cache oder die Datenbank, Uploads in den Objektspeicher, und nichts Wichtiges liegt auf der Platte einer Instanz. Teste es, indem du während der Geschäftszeiten einen zufälligen App-Server beendest; merken es die Nutzer, versteckt sich noch Zustand auf den Instanzen.

Jede Schicht skalieren

Die Schichten skalieren unterschiedlich, und genau deshalb hält man sie getrennt:

• Präsentation: Ein CDN fängt den Großteil des statischen Traffics ab. Cache-Header entscheiden, wie viel.
• Anwendung: Instanzen hinzufügen. Nach Anfragezahl oder CPU skalieren und den Instanzstart schnell halten.
• Daten: die schwierigste. Erst vertikal skalieren, für leselastige Last Read Replicas hinzufügen, für heiße Keys einen Cache und Sharding als letztes Mittel betrachten.

Eine Anfrage durch die Schichten

Folge einem Nutzer, der seine Bestellhistorie lädt:

1. DNS liefert die Adresse des CDN. Der Browser fordert die Seite an; HTML, Skripte und Bilder kommen aus dem Cache des CDN oder aus dem statischen Bucket dahinter.
2. Die Seite ruft GET /api/orders auf. Das CDN leitet dynamische Pfade an den Load Balancer weiter, der TLS terminiert und einen gesunden App-Server in einer der beiden Zonen wählt.
3. Der App-Server liest die Session aus dem Cache, prüft, ob der Nutzer angemeldet ist, und fragt die primäre Datenbank nach den Bestellungen.
4. Die Antwort läuft zurück über Load Balancer und CDN, das sie nicht cacht, weil die Antwort privat ist.

Jeder Hop überquert genau eine Schichtgrenze, und jede Grenze hat genau einen erlaubten Eingang. Das macht das Design leicht nachvollziehbar und leicht abzusichern.

Kosten und die richtige Größe

Die Datenschicht dominiert meist die Rechnung und lässt sich später am schwersten verkleinern, also dimensioniere sie nach Messungen, nicht nach Vermutungen. Die Anwendungsschicht lässt sich am leichtesten abstimmen: klein anfangen, nach echter Last skalieren und Spitzen dem Autoscaling überlassen. NAT-Gateways und zonenübergreifender Traffic sind die Posten, die Leute überraschen; halte gesprächigen Traffic, wo es geht, in einer Zone, und nutze VPC-Endpunkte für den Objektspeicher, damit App-Server nicht für jeden Upload NAT-Gebühren zahlen.

Das Architekturdiagramm

So liest du es:

• Oben: Nutzer lösen DNS auf und verbinden sich mit dem CDN, das statische Dateien aus einem Bucket ausliefert und dynamische Anfragen weiterleitet.
• Präsentationsschicht: Der Application Load Balancer ist die einzige Komponente in öffentlichen Subnetzen.
• Anwendungsschicht: App-Server in den Zonen A und B liegen in privaten Subnetzen und bekommen Traffic nur vom Load Balancer.
• Datenschicht: Die primäre Datenbank in Zone A repliziert synchron auf einen Standby in Zone B; die App-Server nutzen außerdem einen Session-Cache. Diese Schicht hat keine Route ins Internet.
• Der Markdown-Block listet die Security-Group-Regeln, die die Schichten tatsächlich durchsetzen.

Typische Fehler

• Datenbanken in öffentlichen Subnetzen, „vorübergehend“, für eine schnelle Abfrage vom Laptop. Nutze stattdessen einen Bastion-Host oder ein verwaltetes Session-Tool.
• Security Groups, die einen ganzen CIDR-Bereich erlauben, zwischen Schichten, statt die Gruppe des Nachbarn zu referenzieren.
• Zustand auf App-Servern: Sessions im Speicher, Uploads auf der lokalen Platte. Autoscaling und Failover verlieren dann Daten.
• Eine einzige Availability Zone für die Datenbank, um Geld zu sparen, während die Anwendungsschicht über drei verteilt ist.
• Das CDN weglassen und jedes Bild von den App-Servern ausliefern.
• Kein Health-Check-Pfad auf den App-Servern, sodass der Load Balancer weiter Traffic an Instanzen schickt, die die Datenbank nicht erreichen.

Wenn drei Schichten nicht reichen

Drei Schichten beschreiben eine Anwendung. Wächst ein System zu mehreren Services, behält oft jeder Service seine eigene Drei-Schichten-Form, und das Diagramm wandert eine Ebene nach oben, um zu zeigen, wie die Services miteinander sprechen. Das Microservices-Architekturdiagramm behandelt diesen Schritt. Für die Netzwerkdetails siehe das AWS-VPC-Diagramm und für mehr als eine Region das AWS-Multi-Region-Architekturdiagramm.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge eine Person aus dem C4-Modell-Pack hinzu, einen DNS aus dem Netzwerk-Pack sowie ein CDN und einen Objektspeicher-Node aus dem Cloud-Pack.
3. Füge eine VPC aus dem Netzwerk-Pack hinzu und darin drei Rahmen-Nodes aus dem Basis-Pack, einen pro Schicht.
4. Füge einen Cloud-Lastverteiler zur Präsentationsschicht hinzu, zwei Recheninstanz-Nodes zur Anwendungsschicht und zwei Verwaltete Datenbank-Nodes plus Redis aus dem Daten-Pack zur Datenschicht.
5. Verbinde jede Schicht nur mit ihrem Nachbarn und füge einen Markdown-Block aus dem Basis-Pack mit den Security-Group-Regeln hinzu. Wenn dein Setup schon als Terraform existiert, liefert dir das Terraform-zu-Diagramm-Tool einen ersten Entwurf.

Das Beispiel nutzt 15 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was sind die drei Schichten einer Drei-Schichten-Architektur? Präsentation (die Benutzeroberfläche und der Einstiegspunkt), Anwendung (Geschäftslogik und APIs) und Daten (Datenbanken, Caches und Speicher).

Ist die Drei-Schichten-Architektur veraltet? Nein. Sie ist die Standardform für Webanwendungen. Microservices und Serverless-Systeme enthalten dieselben drei Verantwortlichkeiten, oft pro Service.

Was ist der Unterschied zwischen Tiers und Layers? Layers sind eine logische Aufteilung im Code; Tiers sind eine physische Aufteilung auf getrennte Maschinen oder Services mit Netzwerkgrenzen dazwischen.

Sollte die Datenbank in einem öffentlichen Subnetz liegen? Nein. Halte sie in privaten Subnetzen ohne Internetroute, erreichbar nur aus der Security Group der Anwendungsschicht.

Wie mache ich eine dreischichtige Anwendung hochverfügbar? Betreibe jede Schicht in mindestens zwei Availability Zones, halte die App-Server zustandslos und nutze eine Datenbank mit automatischem Standby in einer anderen Zone.

Kostenlos starten — ein Seat, keine Kreditkarte.