Shared Nothing Architektur
Ein Architekturansatz, der Daten-, Netzwerk- und Speicherressourcen für jede Instanz isoliert.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeReif
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Potenzielle Dateninkonsistenzen.
- Komplexität der Fehlersuche.
- Abhängigkeit von Netzwerkverbindungen.
- Regelmäßige Überwachung der Systemleistung
- Sicherstellen von Backup-Lösungen
- Das Team kontinuierlich schulen
I/O & Ressourcen
- Benutzeranfragen
- Datenquellen
- API-Aufrufe
- Antworten
- Aktualisierte Daten
- Protokolle
Beschreibung
Die Shared Nothing Architektur ist ein Designprinzip, bei dem jede Instanz unabhängig operiert, ohne Abhängigkeiten zu anderen Instanzen. Dies ermöglicht hohe Skalierbarkeit und Ausfallsicherheit, da die Systeme unabhängig voneinander arbeiten können.
✔Vorteile
- Nebenläufigkeit und hohe Skalierbarkeit.
- Unabhängigkeit der Komponenten.
- Erhöhte Ausfallsicherheit.
✖Limitationen
- Komplexität der Verwaltung kann hoch sein.
- Erhöhter Netzwerkverkehr zwischen Instanzen.
- Herausforderungen bei der Datenintegrität.
Trade-offs
Metriken
- Systemverfügbarkeit
Misst die Betriebszeit und Erreichbarkeit des Systems.
- Antwortzeiten
Misst die Zeit, die das System benötigt, um auf Anfragen zu reagieren.
- Ressourcenauslastung
Bewertet die Zulassung und Nutzung von Ressourcen im System.
Beispiele & Implementierungen
E-Commerce-Website
Eine erfolgreiche E-Commerce-Plattform, die auf einer Shared Nothing Architektur basiert.
Verteiltes Datenbanksystem
Ein Datenbanksystem, das auf mehrere Knoten verteilt ist, um Hochverfügbarkeit zu gewährleisten.
Online-Lernplattform
Eine bildungsorientierte Plattform, die Mikroservices zur Kursverwaltung nutzt.
Implementierungsschritte
Bewertung der aktuellen Infrastruktur
Definition von Systemanforderungen
Entwicklung von Migrationsplänen
⚠️ Technische Schulden & Engpässe
Tech Debt
- Alte Systemkomponenten
- Mangelnde Modularität
- Unzureichendes Testen
Bekannte Engpässe
Beispiele für Missbrauch
- Konfiguration ohne Performance-Tests
- Unzureichende Beachtung der Sicherheitsaspekte
- Verwendung veralteter Technologien
Typische Fallen
- Fixierung auf Technologie statt auf Bedürfnisse
- Widerstand gegen Änderungen
- Mangelnde Kommunikation im Team
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Einschränkungen in der Datenhaltung
- • Abhängigkeit von stabilen Netzwerkverbindungen
- • Ressourcenintensive Anwendungen