Mehrschichtenarchitekturen

Das Architekturmuster "Layer"

The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.

Jede Schicht ist unabhängig von den darüber liegenden Schichten
Jede Schicht bietet Services für die darüber liegende Schicht
Der Zugriffe auf die darunter liegende Schicht erfolgt über eine Schnittstelle

Man unterscheidet

Strict Layering - Eine Schicht darf nur auf die unmittelbar darunter liegende Schicht zugreifen
Relaxed Layering - Eine Schicht darf auf alle weiter unten liegenden Schichten zugreifen

Schichten

Tier

Tier /tɪə(r)/ (engl. für Ebene, Schicht, Stufe) bezeichnet eine unabhängige Schicht (Prozessraum) innerhalb einer verteilten Anwendung

n-Tier Architekturen (Multi-Tier Architekturen)

Erweiterung des Client-Server Architekturmodells
n legt die Anzahl der unterschiedliche Client- und Server-Prozessräume innerhalb einer verteilten Anwendung fest
Eine Schicht kann (muss aber nicht) einem physikalischen Rechner entsprechen

Schichten in n-Tier

Typischen Schichten in einem Informationssystem

Visualisierung - Darstellung der Präsentation
Präsentation - Schnittstelle zum Anwender
Anwendungslogik - Bearbeitung der Anfragen
Datenhaltung - Speicherung der Daten in einer Datenbank

Visualisierung und Präsentation können auch zu einer Schicht zusammenfallen (User-Interface)

1-Tier-Architektur

1-Tier Architekturen

Keine Verteilung, alles läuft auf dem Client
Wird für größere Informationssysteme nicht eingesetzt
Beispiele:

Office-Programme
Spiele

2-Tier-Architektur

2-Tier Architektur

Erstes und ältestes Verteilungsmodell
Meistens liegt die Business-Logik komplett beim Client
Häufig werden Stored Procedures und 4GL eingesetzt

4GL (Fourth Generation Languages) Sprachelemente zum Zugriff auf eine Datenbank
Stored Procedures SQL-Prozeduren in der Datenbank, die aufgerufen werden können

Vorteile

Einfach und schnell umzusetzen
Teil der Rechenlast wird auf den Client verschoben
Performant (im Rahmen der Skalierbarkeit)

Nachteile

schwer wartbar
nur begrenzt skalierbar
Probleme beim Software-Update (synchrones Update)

3-Tier-Architektur

Klare Aufgabentrennung zwischen den Tiers

Präsentation Client-Tier
Anwendungslogik Middle-Tier
Datenhaltung Server-Tier

Standardmodell für einfache Webanwendungen

Client-Tier = Browser zur Anzeige
Middle-Tier = Webserver mit Servlets / ASP / Anwendung
Server-Tier = Datenbankserver

4-Tier-Architektur

UI wird in Präsentation und Visualisierung getrennt oder
Anwendungslogik wird auf mehrere Tiers verteilt

Motivation

Beherrschung der Komplexität (Divide and Conquer)
Besserer Schutz einzelner Anwendungsteile
Verwendung mehrere Anwendungsprozesse (Webserver, Application Server)

Viele verteilte Informationssysteme liegen auf 4- und mehr-Tier Architekturen verteilt vor

Aufbau einer realen 4-Tier-Anwendung

Skalierbarkeit

Skalierbarkeit ist die Fähigkeit eines Softwaresystems sich an eine wachsende (oder sinkende) Nutzungsrate flexibel anzupassen.

Eine Architektur

Skaliert gut, wenn der Ressourcenbedarf der Anwendung linear mit der Nutzung wächst
Skaliert schlecht, wenn der Ressourcenbedarf über-linear mit der Nutzung wächst wächst

Grundlegende Ansätze zur Skalierung

Vertikale Skalierung (scale up) Hardware wird vergrößert (mehr CPU, mehr Speicher, etc.)
Horizontale Skalierung (scale out) Hardware wird dupliziert und Services werden mehrfach angeboten

Scale-Up vs. Scale-Out

Verfügbarkeit

Ein System ist verfügbar, wenn es den Nutzern im erwarteten und zugesicherten Umfang Dienstleistungen zur Verfügung stellt.

Verfügbarkeit beschreibt das Verhältnis aus der Zeit, die ein System in einem gegebenen Zeitraum verfügbar ist zur Gesamtzeit des Zeitraums.

\[ \begin{align*} \text{Verfügbarkeit} = \frac{\text{verfügbare Zeit}}{\text{Gesamtzeit}} = \frac{\text{verfügbare Zeit}}{\text{verfügbare Zeit} + \text{Ausfallzeit}} \end{align*} \]

Verfügbarkeitsanforderungen

Zeiten der Nichtverfügbarkeit (Ausfallzeiten) können

geplant sein: z. B. Wartungsarbeiten
ungeplant sein: z. B. Auftreten eines Fehlers.

Typische Verfügbarkeitsanforderungen

90% Verfügbarkeit Ausfall maximal für 36 Tage pro Jahr
99% Verfügbarkeit Ausfall maximal für 3,7 Tagen pro Jahr
99,9% Verfügbarkeit Ausfall maximal für 9 Stunden pro Jahr
99,99% Verfügbarkeit Ausfall maximal für 53 Minuten pro Jahr
99,999% Verfügbarkeit Ausfall maximal für 5 Minuten pro Jahr
99,9999% Verfügbarkeit Ausfall maximal für 30 Sekunden pro Jahr

24 * 7-Tage Betrieb Keine Wartungsfenster

Skalierung einer n-Tier Anwendung

Thin-Client- vs. Fat-Client

Thin- und Fat-Client-Architekturen verfeinern die Zuordnung der Anwendungslogik

Ultra-Thin-Client Client dient nur der reinen Anzeige (typisch für 4-Tier), z. B. Webbrowser
Thin-Client Client beschränkt sich auf die Anzeige und die Aufbereitung der Daten zur Anzeige, z. B. Webbrowser mit AJAX-Framework
Fat-Client Teile der Anwendungslogik liegen zusammen mit der Präsentation auf der Client-Tier (typisch für 2-Tier)

Numbers everyone should know

Aktion	Dauer
L1 cache reference	0,5 ns
Branch mispredict	5 ns
L2 cache reference	7 ns
Mutex lock/unlock	100 ns
Main memory reference	100 ns
Compress 1K bytes with Zippy	10.000 ns
Send 2K bytes over 1 Gbps network	20.000 ns
Read 1 MB sequentially from memory	250.000 ns
Round trip within same datacenter	500.000 ns
Disk seek	10.000.000 ns
Read 1 MB sequentially from network	10.000.000 ns
Read 1 MB sequentially from disk	30.000.000 ns
Send packet CA->Netherlands->CA	150.000.000 ns

Quelle: Google, Software Engineering Advice from Building Large-Scale Distributed Systems