Monolithische Architektur · Mindmaps
Monolithische Architektur. Eine bearbeitbare Mindmap mit farbigen Zweigen, Unterthemen und Verbindungen. Geschwungene Linien zeigen Beziehungen; Pfeile stehen nur dort, wo die Richtung wichtig ist.
Ein Monolith ist eine Anwendung, die als eine Einheit gebaut und ausgerollt wird: Oberfläche, Geschäftslogik und Datenzugriff laufen in einem einzigen Prozess gegen eine gemeinsame Datenbank, und Skalieren heißt, das Ganze zu kopieren.
Monolithische Architektur · Mindmaps
Die interaktive MindMap-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.
So lesen Sie diese Mindmap
- Beginnen Sie beim Thema in der Mitte und folgen Sie einem farbigen Zweig zu den zugehörigen Ideen.
- Geschwungene Linien zeigen Beziehungen; Pfeile stehen nur dort, wo die Richtung wichtig ist.
Client request
Dieser Zweig verbindet “Client sends a request”.
One application
Dieser Zweig verbindet “Request enters the single deployable application”, “Business logic module processes it”, “The response returns through the same modules”, “UI module routes and renders”, “Data access module queries the database”.
Shared database
Dieser Zweig verbindet “All modules share a single schema, which keeps joins and transactions simple — the main reason a monolith is so fast to build at first.”.
Scaling tradeoff
Dieser Zweig verbindet “One busy feature forces the entire codebase and database connection pool to be copied to another server — the scaling ceiling that pushes teams toward splitting it.”.
Verbindungen zwischen den Zweigen
Alle Module teilen sich einen Prozess, eine Codebasis und ein Deployment: diese Einfassung ist die Definition.
Die gemeinsame Datenbank koppelt jedes Modul an ein einziges Schema.
Anfragen laufen in einem Durchgang durch jedes Modul: es gibt keinen getrennten Service-Aufruf.
Die Skalierung ist grob: Die ganze Anwendung wird verdoppelt, ob die Funktion ausgelastet ist oder nicht.
Das Entwicklungstempo des Monolithen ist real; die Skalierungsgrenze ist das, was er dafür aufgibt.
Wichtige Zusammenhänge und Erkenntnisse
- Alle Module teilen sich einen Prozess, eine Codebasis und ein Deployment: diese Einfassung ist die Definition.
- Die gemeinsame Datenbank koppelt jedes Modul an ein einziges Schema.
- Anfragen laufen in einem Durchgang durch jedes Modul: es gibt keinen getrennten Service-Aufruf.
- Die Skalierung ist grob: Die ganze Anwendung wird verdoppelt, ob die Funktion ausgelastet ist oder nicht.
- Das Entwicklungstempo des Monolithen ist real; die Skalierungsgrenze ist das, was er dafür aufgibt.
Wann Sie diese Darstellung nutzen
- Erklären, warum sich die Anwendung eines Teams schwer skalieren lässt, obwohl sie sich leicht entwickeln lässt.
- Den Kontrast vermitteln, der Microservices verständlich macht: die Aufteilung ergibt nur vor der Grenze des Monolithen einen Sinn.
- Die Struktur eines Altsystems dokumentieren, bevor die Zerlegung geplant wird.
So funktioniert es
Mittleres Thema anpassen
Benennen Sie das Thema für Ihr Projekt oder Ihren Unterricht um.
Zweige ausbauen
Bearbeiten Sie Ideen und ergänzen Sie Beispiele oder Notizen.
Ideen verbinden
Zeichnen Sie Verbindungen zwischen Zweigen; Pfeile zeigen eine wichtige Richtung an.
Häufig gestellte Fragen
Was ist eine monolithische Architektur?
Ein Monolith ist eine Anwendung, deren Oberfläche, Geschäftslogik und Datenzugriff als eine Einheit gebaut, ausgerollt und skaliert werden: eine Codebasis, die ein einziges ausrollbares Artefakt erzeugt und gegen eine gemeinsame Datenbank läuft. Die Darstellung zeigt die Anfrage, wie sie innerhalb einer einzigen Anwendungsbahn durch alle drei Module wandert, denn diese Einfassung ist die Definition.
Warum beginnen Teams mit einem Monolithen?
Weil ein Monolith für die meisten Teams und über den größten Teil des Lebens einer Anwendung der schnellste Weg zur Auslieferung ist. Zwischen den Modulen liegt kein Netzwerk, das gemeinsame Schema macht Joins und Transaktionen einfach, und das Deployment ist ein Artefakt. Der Kasten zur gemeinsamen Datenbank sagt das in der Darstellung direkt: die Abwägung kippt erst, wenn unabhängige Skalierung oder die Autonomie der Teams zur eigentlichen Engstelle wird.
Was ist das Hauptproblem eines Monolithen?
Die Skalierungsgrenze und die Kopplung. Skalieren heißt, die ganze Anwendung zu kopieren, sodass eine stark genutzte Funktion Kapazität an alles Übrige verschwendet, und jede Änderung berührt eine Codebasis und ein Schema, von denen alle abhängen. Wachsen Team und Codebasis, verlangsamen diese beiden Effekte das Ausrollen und erzwingen Abstimmung: die Bedingungen, unter denen Teams beginnen, Services herauszulösen.
Wie wird aus einem Monolithen eine Microservices-Architektur?
Schrittweise, indem eine Fähigkeit nach der anderen herausgelöst wird. Der erste Schritt ist, ein Modul zu finden, das für sich stehen kann (mit eigenen, abgegrenzten Daten), und ihm dann eine eigene Datenbank, eine API und schließlich ein unabhängiges Deployment zu geben. Der Schritt zu den Kandidaten für die Herauslösung bildet in dieser Darstellung genau das ab: Modul markieren, Kopplung trennen, aufteilen. Der Fehler ist, den ganzen Monolithen auf einmal neu zu schreiben: so scheitern Migrationen.
Diese Mindmap in QueryChart bearbeiten
Öffnen Sie die Mindmap auf einer bearbeitbaren Leinwand. Verschieben Sie Ideen und ergänzen Sie Zweige und Verbindungen.