Microkernel / Plug-in-Architektur
Der Microkernel-Stil trennt minimale Kernfähigkeiten von austauschbaren Erweiterungen über einen stabilen Vertrag.
- KernStabile Mindestfunktionen und Verträge.
- Plug-inOptionale Fachfunktion am Vertrag.
- IsolationFehler- und Rechtewirkung prüfen.
Einordnung
Warum das wichtig ist
Einen stabilen Anwendungskern mit klaren Erweiterungspunkten gestalten und Plug-in-Kosten bewerten.
Erweiterungsmodell für Systeme, deren Funktionen durch Plug-ins ergänzt oder ausgetauscht werden müssen.
Kern und Plug-ins für Versandregeln
Die Shopvariante ist ausdrücklich hypothetisch: Ein Plug-in-Punkt für Versandregeln ergänzt die bestehende Sieben-Modul-Anwendung.
So liest du das Bild
- Kern Plattformkern
- Plug-in Erweiterung
- Isolation Betriebsgrenze
| Kriterium | Zuständigkeit | Entscheidung |
|---|---|---|
| Kernvertrag | Stabile Version bereitstellen. | Kompatibilität prüfen. |
| Laufzeit | Erweiterungen laden. | Fehlerwirkung begrenzen. |
Nutzen & Grenzen
Hilft, wenn
- Mehrere optionale Erweiterungen folgen demselben stabilen Vertrag.
- Funktionen sollen unabhängig aktiviert oder ersetzt werden.
Grenzen
- Versions- und Kompatibilitätskosten können den Nutzen übersteigen.
- Fehlerhafte Erweiterungen teilen möglicherweise Prozess und Berechtigungen mit dem Kern.
In der Praxis
- Leite aus konkreten Erweiterungsfällen die kleinsten stabilen Kernfähigkeiten ab. Definiere je Plug-in Vertrag, zulässige Abhängigkeiten und den Lebenszyklus, statt abstrakte Erweiterbarkeit vorauszusetzen.
- Lege fest, wie Plug-ins erkannt, aktiviert, versioniert und bei inkompatiblen Verträgen abgelehnt werden. Berücksichtige gemeinsam genutzte Laufzeit, Berechtigungen und mögliche Ressourcenlimits.
- Prüfe Fehler, Rechte und Ausfallfolgen jeder Erweiterung. Wähle stärkere Prozessisolation, wenn ein Plug-in den Kern gefährden kann, und vergleiche den Betriebsaufwand mit einer einfacheren modularen Lösung.
Ausführliche Erklärung lesen
Verträge, Versionsregeln, Registrierung und Fehlermodi gehören zum Entwurf. Plug-ins können im selben Prozess laufen; der Stil verspricht daher keine automatische Fehler- oder Sicherheitsisolation.
Microkernel beschreibt ein Erweiterungsmodell und kann innerhalb eines Monolithen eingesetzt werden. Es verlangt keine getrennten Microservices.
Der Microkernel kann innerhalb eines modularen Monolithen laufen; getrennte Microservices lösen eine andere Betriebsfrage.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was bleibt im Kern des Beispiels?
Lösung mit Begründung ansehen
Minimale Plattformfähigkeiten und der Plug-in-Vertrag.
AnwendenAuf eine neue Lage übertragen
Wie reagierst du auf ein Plug-in mit inkompatibler Vertragsversion?
Lösung mit Begründung ansehen
Version prüfen und die Erweiterung kontrolliert zurückweisen oder migrieren.
BewertenEine Alternative abwägen
Was muss vor dem Plug-in-Einsatz nachgewiesen werden?
Lösung mit Begründung ansehen
Mehrere reale Erweiterungsfälle und beherrschbare Kompatibilitäts-, Fehler- und Sicherheitskosten.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Microsoft · Microkernel architecture style (öffnet in neuem Tab)Dokumentiert Kern, Plug-in-Verträge und Einsatzbedingungen.
- Carnegie Mellon SEI · Architecture Styles (öffnet in neuem Tab)Ordnet Architekturstile und Qualitätsmerkmale ein.
- Buschmann et al. · Pattern-Oriented Software Architecture (öffnet in neuem Tab)Referenzwerk zum Microkernel-Stil.