Microkernel- und Plug-in-Architekturen

Definition und Ursprung

Eine Microkernel-Architektur, auch Plug-in-Architektur genannt, teilt eine Anwendung in zwei Arten von Teilen: ein Kernsystem, das die minimale, allgemeine Funktionalität enthält, die für den Betrieb nötig ist, und Plug-ins, die Verhalten hinzufügen oder ändern, ohne dass der Kern verändert wird. Plug-ins sind nur über veröffentlichte Verträge an den Kern angebunden, und der Kern findet sie über eine Registry. Mark Richards und Neal Ford führen sie in Fundamentals of Software Architecture als einen der klassischen Architekturstile, und sie passt zur Beschreibung eines Architekturstils in Abschnitt 5.1: eine benannte Menge von Einschränkungen für die Elemente (Kern, Plug-ins) und Konnektoren (Verträge) eines Systems.

Die Idee entstand in Produktsoftware: Werkzeugen, die von vielen Kunden installiert werden, von denen jeder etwas leicht anderes möchte. Statt für jeden Kunden eine eigene Version zu pflegen, liefert der Hersteller einen Kern aus und lässt Kunden, Partner oder die eigenen Teams Plug-ins hinzufügen. Integrierte Entwicklungsumgebungen, Webbrowser, Grafikprogramme und Buchhaltungspakete funktionieren alle so. Der Name ist von Betriebssystemen entlehnt, wo ein Microkernel ein sehr kleiner Kernel ist, außerhalb dessen alles andere läuft; die beiden Ideen sind verwandt, sollten aber nicht verwechselt werden, wie weiter unten erklärt.

Eine Microkernel-Anwendung ist normalerweise eine einzige Deployment-Einheit und gehört daher zu den monolithischen Stilen dieses Kapitels: eine Deployment-Einheit, ein Prozess, ein Satz betrieblicher Anliegen. Plug-ins können separat installiert werden, aber zur Laufzeit leben sie im Kern oder direkt daneben.

So funktioniert es: Kern, Plug-ins, Registry und Verträge

Das Kernsystem enthält, was jede Installation braucht: den Hauptablauf, gemeinsame Dienste wie Logging oder Konfiguration und die Erweiterungspunkte, an denen Plug-ins andocken. Richards und Ford beschreiben es als den Happy Path durch die Anwendung, mit wenig oder keiner kundenspezifischen Verarbeitung; im Checkout einer Essenslieferplattform heißt das: einen Warenkorb bepreisen, die Zahlung entgegennehmen und die Bestellung bestätigen. Ein guter Kern ist bewusst langweilig. Jeder Sonderfall, der je nach Kunde, Land oder Produktlinie variiert, ist ein Kandidat dafür, aus ihm herausgelöst zu werden.

Plug-ins sind unabhängige, in sich geschlossene Module mit spezialisierter Verarbeitung. Sie sollten nur vom Vertrag abhängen, nicht voneinander und nicht von den internen Klassen des Kerns. Braucht ein Plug-in etwas, das ein anderes bereitstellt, sollte der Kern diesen Bedarf decken (als Dienst, den er über den Vertrag anbietet), oder die beiden Plug-ins sollten zusammengelegt werden; Abhängigkeiten zwischen Plug-ins verwandeln einen sauberen Stern unbemerkt in ein Knäuel.

Die Registry hält fest, welche Plug-ins verfügbar sind, wie jedes heißt, welche Version es hat, welchen Vertrag es implementiert und wie es erreichbar ist. Sie kann so einfach sein wie ein beim Start gefülltes Dictionary, ein Verzeichnis, das der Kern nach Manifesten durchsucht, Einträge in den Metadaten eines Pakets (wie bei Python-Entry Points), eine Datenbanktabelle oder ein entfernter Dienst, der anderswo deployte Plug-ins auflistet. Die Registry ermöglicht es dem Kern, „Gib mir die Steuerregeln für Deutschland“ zu sagen, ohne zu wissen, dass eine Klasse namens GermanTax existiert.

Verträge legen fest, was ein Plug-in bereitstellen muss und worauf es sich verlassen darf: eine Schnittstelle mit Methodensignaturen, die Datenstrukturen, die sie überqueren, das Fehlerverhalten und eine Version. In Eclipse ist ein Vertrag ein Erweiterungspunkt, der in einem Plug-in-Manifest mit einem Schema deklariert wird; in Visual Studio Code ist es die Extension-API plus die Contribution Points, die in der package.json einer Extension aufgeführt sind; in Ihrem eigenen Code ist es meist eine Schnittstelle (oder ein Python-Protocol) in einem eigenen kleinen Paket. Stammt das Plug-in von einer anderen Organisation und kann es Ihrem Vertrag nicht folgen, übersetzt ein Adapter zwischen beiden, genau wie in der hexagonalen Architektur.

Plug-ins lassen sich auf drei Arten anbinden. Punkt-zu-Punkt-Aufrufe im selben Prozess sind der Normalfall: Der Kern ruft eine Methode des Plug-in-Objekts auf. Plug-ins in getrennten Prozessen laufen in einem eigenen Prozess und sprechen über Interprozessnachrichten mit dem Kern, was den Kern vor Abstürzen schützt. Entfernte Plug-ins sitzen hinter einer HTTP- oder Messaging-Schnittstelle; das erlaubt Plug-ins in anderen Sprachen oder im Besitz anderer Teams, bringt aber Netzwerklatenz und neue Ausfallarten mit sich, und das System ähnelt allmählich den verteilten Stilen aus Kapitel 6.

Echte Beispiele

Eclipse. Die Eclipse-IDE ist das Lehrbuchbeispiel. Ihr Kern ist kaum mehr als eine Workbench und eine Plug-in-Laufzeitumgebung (aufgebaut auf Equinox, einer Implementierung der OSGi-Framework-Spezifikation). Fast alles, was Entwicklungsteams sehen, von den Java-Werkzeugen bis zur Integration der Versionsverwaltung, ist ein Plug-in. Jedes Plug-in hat ein Manifest, das deklariert, was es braucht, welche Erweiterungspunkte es anderen anbietet und in welche Erweiterungen es sich einklinkt. Plug-ins werden verzögert aktiviert, erst wenn tatsächlich etwas sie braucht, damit Hunderte installierter Plug-ins den Start nicht verlangsamen.

Visual Studio Code. Extensions deklarieren Aktivierungsereignisse (eine Markdown-Datei öffnen, einen Befehl ausführen), damit sie nur bei Bedarf geladen werden, und steuern über ihr Manifest Befehle, Sprachen, Themes und Ansichten bei. Extensions laufen in einem separaten Extension-Host-Prozess, sodass eine fehlerhafte Extension die Benutzeroberfläche des Editors nicht einfrieren kann. Das ist ein gutes Beispiel dafür, Prozessisolation für ein Plug-in-Ökosystem mit Tausenden externer Autoren zu wählen.

Webbrowser. Browser-Extensions nutzen einen Standardsatz von Extension-APIs und müssen die benötigten Berechtigungen (welche Websites sie lesen dürfen, ob sie Tabs oder Downloads sehen dürfen) in einem Manifest deklarieren. Der Browser setzt diese Berechtigungen durch, weil man den Autoren von Extensions nicht von vornherein vertrauen kann.

Business-Rules-Engines. Das Schadensystem eines Versicherers kann den Ablauf der Schadenbearbeitung im Kern halten und die Regeln jeder Rechtsordnung (was gedeckt ist, welche Unterlagen nötig sind, gesetzliche Fristen) in Plug-ins auslagern. Steuer-Engines, Lohnabrechnungssysteme und E-Commerce-Plattformen mit Plug-ins für Zahlungsmethoden folgen demselben Muster: ein stabiler Prozess mit Regeln oder Anbietern, die je nach Land, Produkt oder Kunde variieren.

Entwicklerwerkzeuge. Das Test-Framework pytest ist um die Plug-in-Bibliothek pluggy herum gebaut; viele seiner eigenen Funktionen sind als Plug-ins implementiert, mit denselben Hooks, die auch Dritte nutzen. Build-Tools, Linter und Static-Site-Generatoren machen es häufig genauso.

Isolation, Versionierung und Kompatibilität von Plug-ins

Drei Fragen entscheiden, ob eine Plug-in-Architektur über Jahre gesund bleibt: wie isoliert Plug-ins sind, wie sich der Vertrag weiterentwickelt und wie Inkompatibilität erkannt wird.

Isolation. Prozessinterne Plug-ins teilen Speicher, Threads und Berechtigungen des Kerns. Das ist schnell und einfach, aber ein einziges Plug-in mit einer Endlosschleife, einem Speicherleck oder einer Sicherheitslücke betrifft alles. Die Optionen, nach zunehmender Isolation und zunehmenden Kosten geordnet, sind: prozessintern mit defensiven Aufrufen (Timeouts, Abfangen von Exceptions je Plug-in, Ressourcenlimits); ein separater Prozess oder Worker je Plug-in oder Gruppe von Plug-ins; eine Sandbox wie eine WebAssembly-Laufzeitumgebung oder ein eingeschränkter Interpreter, die begrenzt, worauf Plug-in-Code zugreifen kann; und ein entfernter Dienst. Wählen Sie, indem Sie fragen, wer die Plug-ins schreibt. Die Steuerregeln Ihres eigenen Teams können prozessintern laufen; beliebiger Code aus einem öffentlichen Marktplatz sollte das nicht.

Versionierung. Der Vertrag ist eine API, und es gelten die Regeln aus Abschnitt 0.6 zu Breaking Changes. Versionieren Sie den Vertrag getrennt vom Kern, meist mit semantischer Versionierung: eine neue Major-Version für Breaking Changes, eine Minor-Version für abwärtskompatible Ergänzungen. Lassen Sie jedes Plug-in deklarieren, für welche Vertragsversion es gebaut wurde, und den Kern, welche Versionen er unterstützt. Additive Änderungen (neue optionale Felder, neue optionale Hooks) halten alte Plug-ins lauffähig; ist eine Breaking Change unvermeidlich, unterstützen Sie die alte und die neue Major-Version für eine veröffentlichte Deprecation-Frist parallel.

Kompatibilitätsprüfungen. Prüfen Sie die Kompatibilität beim Laden der Plug-ins, nicht erst, wenn ein Kunde sie zum ersten Mal auslöst. Eine Registry, die ein inkompatibles Plug-in beim Start mit einer klaren Log-Meldung ablehnt, macht aus einem Laufzeitfehler einen fehlgeschlagenen Deployment-Schritt. Die Beobachtung von Hyrum Wright, bekannt als Hyrums Gesetz, sollte man hier im Kopf behalten: Bei genügend Nutzern wird sich irgendjemand auf jedes beobachtbare Verhalten einer Schnittstelle verlassen, ganz gleich, was in der Dokumentation steht. Halten Sie den Vertrag klein, halten Sie die Interna des Kerns außer Reichweite (Eclipse kennzeichnet Nicht-API-Pakete aus diesem Grund als internal) und behandeln Sie alles, was für Plug-ins sichtbar ist, als Teil des Vertrags.

Wann man ihn einsetzt und wann nicht

Gute Einsatzfälle. Produktsoftware, die viele Kunden installieren und anpassen. Systeme mit einem stabilen Ablauf, aber vielen Varianten eines Schritts: Steuern und Lohnabrechnung je Land, Versicherungsregeln je Rechtsordnung, Zahlungsmethoden, Importer für Dateiformate, Versanddienstleister. Plattformen, die ein Ökosystem von Drittanbietern wollen. Systeme, in denen eine Aufsichtsbehörde oder ein Kunde häufig Regeln ändert und Sie diese Änderungen als kleine, separat getestete Releases haben wollen. Der Stil funktioniert auch innerhalb eines größeren Systems: Ein Service in einer verteilten Architektur kann selbst ein Microkernel sein.

Schlechte Einsatzfälle. Systeme, bei denen Sie noch nicht wissen, was variiert. Im Voraus für erdachte Bedürfnisse entworfene Erweiterungspunkte sind spekulative Allgemeinheit: Sie fügen Mechanik hinzu, bremsen das Team und sitzen meist an der falschen Stelle, wenn der echte Bedarf kommt (siehe die Diskussion der Umkehrbarkeit in Abschnitt 1.6). Systeme, die sehr hohe Skalierbarkeit oder Fehlerisolation brauchen, da das Ganze als eine Einheit skaliert und ausfällt. Systeme, in denen Plug-ins eng miteinander koordiniert werden müssten, was den Hauptnutzen des Stils zunichtemacht.

Eine praktische Regel: Warten Sie, bis Sie dieselbe Art von Variation zwei- oder dreimal gebaut haben, und leiten Sie den Vertrag dann aus den echten Fällen ab. Ein Vertrag, der aus drei funktionierenden Steuerimplementierungen abgeleitet ist, wird weit besser sein als einer, der vor der ersten geraten wurde.

# package: tax_contract  (version 2.1.0)
from dataclasses import dataclass
from decimal import Decimal
from typing import Protocol

CONTRACT_VERSION = (2, 1)

@dataclass(frozen=True)
class TaxLine:
    sku: str
    category: str      # "hot-food", "cold-food", "alcohol", "delivery-fee"
    net: Decimal       # never float for money

@dataclass(frozen=True)
class TaxResult:
    total_tax: Decimal
    breakdown: dict[str, Decimal]   # label shown on the receipt

class TaxRules(Protocol):
    country: str                    # ISO 3166-1 alpha-2, e.g. "DE"
    requires_contract: tuple[int, int]
    def calculate(self, lines: list[TaxLine], region: str | None) -> TaxResult: ...

from importlib.metadata import entry_points
from tax_contract import CONTRACT_VERSION

class UnsupportedCountry(Exception): pass

class TaxRegistry:
    def __init__(self, log):
        self._by_country = {}
        for ep in entry_points(group="fooddelivery.tax_rules"):
            plugin = ep.load()()
            major, minor = plugin.requires_contract
            if major != CONTRACT_VERSION[0] or minor > CONTRACT_VERSION[1]:
                log.warning("skipping %s: needs contract %s", ep.name, plugin.requires_contract)
                continue
            self._by_country[plugin.country] = plugin

    def for_country(self, country):
        if country not in self._by_country:
            raise UnsupportedCountry(country)   # fail loudly, never guess a rate
        return self._by_country[country]

Den Stil im Code durchsetzen

Eine Plug-in-Architektur bleibt nur dann eine, wenn ihre Regeln automatisch geprüft werden. Die Struktur, die in den meisten Sprachen funktioniert, hat drei Arten von Paketen: ein kleines Vertragspaket nur mit Schnittstellen und Datentypen; den Kern, der vom Vertrag abhängt; und ein Paket pro Plug-in, das jeweils vom Vertrag abhängt und von nichts anderem aus Ihrem Code.

Setzen Sie die Abhängigkeitsregeln dann mit Werkzeugen der Art durch, die Abschnitt 3.4 behandelt: In Python kann import-linter dem Kern verbieten, irgendein Plug-in-Paket zu importieren, und Plug-ins verbieten, einander oder den Kern zu importieren; in Java leisten ArchUnit-Tests oder Modulsysteme (JPMS, OSGi) dasselbe. Lassen Sie den Build fehlschlagen, wenn eine Regel verletzt wird.

Ergänzen Sie eine Contract-Test-Suite: eine Reihe von Tests, die einmal gegen den Vertrag geschrieben werden und gegen jedes Plug-in in dessen eigener Pipeline laufen. Sie prüft das Verhalten, das der Vertrag zusagt (Rundung, leere Eingaben, Fehlertypen), nicht das Steuerrecht jedes Landes, das die eigenen Tests des Plug-ins abdecken. Fügen Sie schließlich eine Startprüfung oder einen Smoke-Test beim Deployment hinzu, der jedes installierte Plug-in lädt und seine Vertragsversion verifiziert, damit Inkompatibilitäten auffallen, bevor Nutzer sie finden.