Systemverwaltung
Enterprise Integration Patterns · Gruppe 8 von 8
Ein Integrationssystem ist erst dann fertig, wenn man es auch betreiben kann. Gerade die lose Kopplung, die Messaging so wertvoll macht, erschwert den Überblick: Niemand sieht auf einen Blick, wo eine Nachricht gerade ist, wie lange etwas dauert oder warum etwas schiefgeht. Die letzte Gruppe beschreibt Muster zum Steuern, Beobachten, Testen und Aufräumen eines laufenden Messaging-Systems.
- Anwendung
- Integrationskomponente
- Kanal
- Nachricht
- Datenbank / Speicher
- 58. Control Bus
- 59. Detour
- 60. Wire Tap
- 61. Message History
- 62. Message Store
- 63. Smart Proxy
- 64. Test Message
- 65. Channel Purger
58. Control Bus · Steuerbus
Die Idee
Ein Messaging-System besteht aus vielen verteilten Komponenten: Translatoren, Routern, Filtern, Endpunkten. Um sie zu überwachen und zu steuern, nutzt man dasselbe Werkzeug, das sie ohnehin beherrschen: Nachrichten. Der Control Bus ist ein eigener Kanal nur für Verwaltungsnachrichten. Über ihn melden Komponenten ihren Zustand und empfangen Befehle, getrennt vom eigentlichen Datenverkehr.
Beispiel
Ein Leitstand fragt über den Control Bus jede Minute alle Komponenten nach Durchsatz und Fehlern. Fällt die Fehlerquote eines Translators auf, schickt der Administrator den Befehl „Stopp“, damit keine fehlerhaften Daten mehr weitergehen. Ändert sich eine Routing-Regel, wird sie per Control Bus an den Router verteilt, ohne Neustart.
Worauf achten
Steuer- und Datenverkehr müssen getrennt bleiben, damit Verwaltungsbefehle nicht hinter tausenden Geschäftsnachrichten in der Warteschlange hängen. Der Control Bus braucht eigene Zugriffsrechte, denn wer ihn bedienen kann, kann das ganze System anhalten. Typische Nachrichten sind Konfigurationsänderungen, Lebenszeichen (Heartbeats), Statistiken, Ausnahmemeldungen und Befehle zum Starten und Stoppen.
In der Praxis
Das controlbus-Element in Spring Integration, die controlbus:-Komponente in Camel zum Starten und Stoppen von Routen, JMX für die Verwaltung von Java-Komponenten, und im modernen Betrieb Metriken über Prometheus mit Steuerung über Kubernetes.
59. Detour · Umleitung
Die Idee
Ein Detour ist eine umschaltbare Umleitung. An einer Stelle im Nachrichtenfluss steht ein Router, eine Weiche, der normalerweise den direkten Weg nimmt. Über den Control Bus lässt er sich umschalten, sodass die Nachrichten vorübergehend durch zusätzliche Schritte laufen, etwa eine Prüfung, eine Protokollierung oder einen Test, bevor sie ihr Ziel erreichen.
Beispiel
Das Lager beschwert sich über fehlerhafte Bestellungen. Der Administrator schaltet über den Control Bus die Umleitung ein. Ab sofort läuft jede Bestellung zusätzlich durch eine Validierung und wird vollständig protokolliert. Ist der Fehler gefunden, wird die Umleitung wieder abgeschaltet, und die Nachrichten nehmen wieder den schnellen, direkten Weg.
Worauf achten
Der Vorteil liegt darin, dass die zusätzlichen Schritte im Normalbetrieb keine Zeit kosten und trotzdem jederzeit bereitstehen, ohne dass etwas neu ausgeliefert werden muss. Die Umleitung muss sich zuverlässig wieder abschalten lassen. Wer sie vergisst, bezahlt dauerhaft mit langsamerer Verarbeitung und vollen Protokollen. Die Schritte im Umweg dürfen die Nachricht nicht verändern, sonst verhält sich das System mit und ohne Umleitung unterschiedlich.
In der Praxis
Ein Content-Based Router, der eine Konfiguration auswertet, etwa in Camel eine choice() anhand einer Eigenschaft, die zur Laufzeit gesetzt wird. Moderne Verwandte sind Feature Flags, mit denen sich zusätzliche Verarbeitungsschritte ohne Neuauslieferung zu- und abschalten lassen.
60. Wire Tap · Abhörstelle
Die Idee
Ein Wire Tap ist ein Filter mit einem Eingang und zwei Ausgängen: Er reicht jede Nachricht unverändert weiter und schickt zusätzlich eine Kopie in einen zweiten Kanal. So kann man den Nachrichtenfluss beobachten, ohne ihn zu verändern. Der Name stammt vom Abhören einer Telefonleitung.
Beispiel
Für eine Prüfung soll nachvollziehbar sein, welche Bestellungen an das Lager gegangen sind. Ein Wire Tap zwischen Shop und Lager kopiert jede Bestellung in einen Protokollkanal, aus dem ein Archivdienst liest. Shop und Lager merken davon nichts.
Worauf achten
Der Wire Tap ist eine einfache Form der Recipient List mit festem Zweitempfänger. In einem Point-to-Point Channel ist er das Mittel der Wahl, um mitzulesen, denn ein zweiter normaler Empfänger würde dem eigentlichen die Nachrichten wegnehmen. Er sollte den Hauptweg nicht verlangsamen. Ist der Protokollkanal voll oder langsam, darf das die Zustellung an das Lager nicht behindern. Und Vorsicht mit sensiblen Daten: Jede Kopie ist ein weiterer Ort, an dem sie liegen.
In der Praxis
wireTap() in Camel und Spring Integration, Interceptoren in Kafka-Clients, Mirroring in Netzwerken. Auch Logging-Mechanismen, die jede ein- und ausgehende Nachricht mitschreiben, sind im Kern Wire Taps.
61. Message History · Nachrichtenverlauf
Die Idee
In einem lose gekoppelten System weiß niemand genau, welchen Weg eine Nachricht genommen hat. Bei der Message History trägt sich jede Station in eine Liste im Header der Nachricht ein. Am Ziel kann man ablesen, wo die Nachricht überall war. Wie ein Reisepass, in den an jeder Grenze ein Stempel kommt.
Beispiel
Im Lager kommt eine Bestellung mit falschem Lieferland an. Ein Blick in die Message History zeigt: Sie kam vom Shop, lief durch den Translator und dann durch den Router. Damit ist klar, wo man suchen muss, nämlich beim Translator, der die Ländercodes umsetzt.
Worauf achten
Die History hilft bei der Fehlersuche und kann Endlosschleifen erkennen: Taucht eine Station zum zweiten Mal auf, läuft die Nachricht im Kreis. Sie wächst mit jeder Station und vergrößert die Nachricht. Bei langen Wegen trägt man deshalb nur Kennungen und Zeitstempel ein. Wird eine Nachricht von einem Aggregator mit anderen zusammengeführt, muss er entscheiden, welche Historien er übernimmt.
In der Praxis
MessageHistory in Spring Integration (per @EnableMessageHistory), messageHistory in Camel. Heute übernimmt diese Aufgabe oft verteiltes Tracing mit OpenTelemetry: Statt einer Liste in der Nachricht wird eine Trace-ID weitergereicht, und jede Station meldet ihren Abschnitt an ein zentrales System wie Jaeger oder Zipkin.
62. Message Store · Nachrichtenspeicher
Die Idee
Ein Message Store speichert Nachrichten zentral, damit man sie später auswerten kann, ohne den eigentlichen Fluss zu verändern. Meist wird er über Wire Taps gefüllt. Weil Nachrichten flüchtig sind und nach der Zustellung verschwinden, ist der Store die einzige Stelle, an der man im Nachhinein sieht, was wann durch das System gelaufen ist.
Beispiel
Alle Nachrichten zu Bestellungen landen im Message Store. Die Auswertung kann damit fragen: Wie lange dauert es im Schnitt von „Bestellung eingegangen“ bis „Paket versandt“? Wo hängen Bestellungen fest? Was ist mit Bestellung 4711 genau passiert? Und nach einem Fehler lassen sich Nachrichten aus dem Store erneut einspielen.
Worauf achten
Ein Message Store ist ein Datenspeicher wie jeder andere und braucht eine Antwort auf die Fragen: Wie lange werden Daten aufbewahrt? Wer darf darauf zugreifen? Personenbezogene Daten unterliegen dem Datenschutz, oft muss man sie nach einer Frist löschen oder schon beim Speichern verkürzen. Gespeichert wird meist der Header vollständig und der Body nur, wenn er wirklich gebraucht wird.
In der Praxis
MessageStore-Implementierungen in Spring Integration (JDBC, MongoDB, Redis), Kafka selbst, das Nachrichten ohnehin für eine einstellbare Zeit speichert und erneutes Lesen erlaubt, Log-Plattformen wie Elasticsearch oder Splunk. Event Sourcing treibt den Gedanken auf die Spitze: Dort ist der gespeicherte Nachrichtenstrom selbst die maßgebliche Datenquelle.
63. Smart Proxy · Intelligenter Stellvertreter
Die Idee
Bei Request-Reply mit Return Address antwortet ein Dienst direkt an den Anfragenden. Ein normaler Wire Tap sieht deshalb nur die Hälfte des Austauschs. Ein Smart Proxy schaltet sich in beide Richtungen ein: Er ersetzt in der Anfrage die Rücksendeadresse durch seine eigene, merkt sich die ursprüngliche, empfängt die Antwort selbst und leitet sie an den eigentlichen Empfänger weiter. Dazwischen kann er messen, protokollieren oder prüfen.
Beispiel
Der Shop fragt den Lagerdienst nach Beständen. Es gibt Beschwerden über langsame Antworten. Ein Smart Proxy zwischen Shop und Lagerdienst misst für jede Anfrage die Zeit bis zur Antwort und meldet die Werte an den Control Bus. Shop und Lagerdienst bleiben unverändert.
Worauf achten
Der Proxy muss sich für jede offene Anfrage die ursprüngliche Rücksendeadresse merken, über den Correlation Identifier. Er ist zustandsbehaftet und muss mit Anfragen umgehen, deren Antwort nie kommt. Fällt er aus, sind alle laufenden Anfragen verloren. Er ist die Messaging-Variante des Proxy-Musters der GoF.
In der Praxis
Service-Mesh-Sidecars wie Envoy in Istio sind heute die verbreitetste Form: Sie stehen vor jedem Dienst, fangen jeden Aufruf in beide Richtungen ab und messen Latenzen und Fehlerraten, ohne dass die Dienste davon wissen. API-Gateways übernehmen eine ähnliche Rolle für Aufrufe von außen.
64. Test Message · Testnachricht
Die Idee
Eine Komponente kann laufen, Nachrichten annehmen und trotzdem falsche Ergebnisse liefern. Um das im laufenden Betrieb zu bemerken, werden regelmäßig Testnachrichten mit bekanntem Ergebnis in den echten Nachrichtenstrom eingespeist. Am Ende werden sie anhand einer Kennzeichnung wieder herausgefiltert, und ein Prüfer vergleicht das Ergebnis mit dem erwarteten.
Beispiel
Alle zehn Minuten speist ein Testdienst eine Bestellung mit der Kennung TEST ein: zwei Exemplare von Artikel 4711 nach Hamburg. Sie durchläuft Translator, Router und Preisberechnung wie jede echte Bestellung. Vor dem Lager wird sie abgezweigt, und der Prüfer kontrolliert, ob Preis und Lager stimmen. Liefert die Preisberechnung nach einem Update falsche Werte, schlägt der Prüfer Alarm, bevor Kunden es merken.
Worauf achten
Testnachrichten müssen eindeutig erkennbar sein und dürfen nie echte Wirkung entfalten: keine Pakete, keine Rechnungen, keine Abbuchungen. Am sichersten ist es, sie vor jedem System mit Außenwirkung abzuzweigen. Jede Komponente auf dem Weg muss mit ihnen umgehen können, ohne Statistiken oder Bestände zu verfälschen. Anders als bei Tests vor der Auslieferung prüfen Testnachrichten das echte System mit echter Konfiguration.
In der Praxis
Synthetisches Monitoring, das regelmäßig typische Vorgänge im Produktivsystem durchspielt, Health Checks, die einen vollständigen Weg durch das System prüfen, Kanarienvögel-Bestellungen im Onlinehandel. Werkzeuge wie Datadog Synthetics oder Checkly arbeiten nach diesem Prinzip.
65. Channel Purger · Kanalreiniger
Die Idee
Manchmal liegen Nachrichten in einem Kanal, die dort nicht mehr hingehören: Reste eines abgebrochenen Tests, veraltete Daten nach einer Störung, fehlerhafte Nachrichten, die immer wieder zugestellt werden. Ein Channel Purger leert einen Kanal ganz oder entfernt gezielt bestimmte Nachrichten, damit das System wieder in einem bekannten, sauberen Zustand ist.
Beispiel
Ein automatischer Test verschickt 100 Testbestellungen und prüft, ob 100 Bestätigungen ankommen. Beim letzten Lauf ist der Test abgebrochen, und im Kanal liegen noch 37 alte Nachrichten. Ohne Bereinigung würde der neue Test 137 Nachrichten zählen und fehlschlagen. Ein Channel Purger leert den Kanal vor jedem Testlauf.
Worauf achten
Ein Channel Purger ist ein Werkzeug mit Sprengkraft: Gelöschte Nachrichten sind unwiederbringlich verloren. In Produktivsystemen sollte er deshalb nur mit Bedacht und mit Berechtigungsprüfung eingesetzt werden. Statt zu löschen ist es oft besser, Nachrichten in einen Store oder Dead Letter Channel zu verschieben, damit man sie notfalls noch untersuchen kann. In Testumgebungen dagegen gehört das Leeren der Kanäle zur selbstverständlichen Vorbereitung jedes Tests.
In der Praxis
„Purge“ in der Verwaltungsoberfläche und per rabbitmqctl purge_queue bei RabbitMQ, PurgeQueue in Amazon SQS, die Funktion „Delete all messages“ in der ActiveMQ-Konsole, das Zurücksetzen der Offsets bzw. Löschen von Topics in Kafka, und in Tests die Werkzeuge von Testcontainers, die für jeden Test einen frischen Broker starten.
Die Verwaltungsmuster im Überblick
| Aufgabe | Muster | Kurz gesagt |
|---|---|---|
| Steuern | Control Bus | eigener Kanal für Befehle und Kennzahlen |
| Detour | zuschaltbarer Umweg über Zusatzschritte | |
| Beobachten | Wire Tap | Kopie jeder Nachricht abzweigen |
| Message History | Nachricht notiert ihren Weg | |
| Message Store | Nachrichten zentral speichern und auswerten | |
| Smart Proxy | Anfrage und Antwort gemeinsam überwachen | |
| Testen | Test Message | markierte Testnachrichten im laufenden Betrieb |
| Aufräumen | Channel Purger | Kanal in einen sauberen Zustand bringen |
Damit sind alle 65 Muster beschrieben. Eine Gesamtübersicht mit allen Mustern und Links zu den einzelnen Kapiteln steht auf der Übersichtsseite.