Message-Oriented Middleware (MOM)
Middleware-Prinzip zur asynchronen, entkoppelten Kommunikation verteilter Systeme über Nachrichten, Broker, Queues und Topics.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Single-Point-of-Failure bei unzureichend skalierter Broker-Architektur
- Dateninkonsistenzen bei schlechtem Error-Handling
- Kosten für Betrieb und Speicher bei hoher Persistenzanforderung
- Nachrichten klein und idempotent gestalten
- Dead-Letter-Queues und Retries konsistent handhaben
- Schemaversionierung und Kompatibilitätsregeln einführen
I/O & Ressourcen
- Definition von Nachrichtenformaten und Schemata
- Broker-Software und Infrastruktur
- Monitoring- und Alerting-Konfiguration
- Entkoppelte Nachrichtenflüsse
- Operationalisierte Broker-Cluster
- Metriken zu Durchsatz und Latenz
Beschreibung
Message-Oriented Middleware (MOM) ist ein Architekturkonzept zur entkoppelten Kommunikation zwischen verteilten Anwendungen über asynchrone Nachrichtenkanäle. Es ermöglicht Zuverlässigkeit, Skalierbarkeit und unterschiedliche QoS-Level durch Broker, Queues und Topics. Implementierungen variieren in Persistenz, Routing und Transaktionsunterstützung.
✔Vorteile
- Verbesserte Resilienz durch Pufferung und Wiederholung
- Skalierbarkeit durch asynchrone Verarbeitung
- Geringere Kopplung und einfachere Evolution einzelner Komponenten
✖Limitationen
- Einführung operationaler Infrastruktur (Broker, Storage)
- Komplexität bei Reihenfolge- und Transaktionsgarantien
- Potenzielle Latenz durch Persistenz und Wiederholungen
Trade-offs
Metriken
- Nachrichten-Durchsatz
Anzahl verarbeiteter Nachrichten pro Sekunde als Maß für Kapazität.
- End-to-End-Latenz
Zeit vom Senden einer Nachricht bis zur Verarbeitung durch den Consumer.
- Dead-Letter-Rate
Anteil der Nachrichten, die in Dead-Letter-Queues landen, als Indikator für Fehler.
Beispiele & Implementierungen
RabbitMQ in Bestell- und Lieferketten
RabbitMQ als Broker zur Entkopplung von Bestellaufnahme, Zahlungs- und Lieferdiensten in einer Microservice-Architektur.
ActiveMQ für Legacy-Messaging
Apache ActiveMQ wird genutzt, um JMS-basierte Legacy-Systeme an moderne Event-Processing-Pipelines anzubinden.
MQTT für IoT-Telemetrie
Leichtgewichtige Broker-Architektur mit MQTT für mobile und eingebettete Geräte zur Telemetrie-Übertragung.
Implementierungsschritte
Anforderungen analysieren: Zuverlässigkeit, Durchsatz, Ordering.
Nachrichtenformate und Schemata definieren sowie Versionierungsstrategie festlegen.
Geeignete Broker-Software auswählen, konfigurieren und in Cluster betreiben.
Consumers/Producers implementieren, Tests für Fehler- und Lastszenarien durchführen.
Monitoring, Alerting und Recovery-Prozesse etablieren.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Fehlende Schemadokumentation und Versionierung
- Monolithische Broker-Konfiguration ohne Automatisierung
- Unzureichende Monitoring- und Alerting-Regeln
Bekannte Engpässe
Beispiele für Missbrauch
- Verwendung von MOM als Ersatz für eine einfache API ohne Bedarf an Entkopplung
- Persistenz für alle Nachrichten erzwingen, obwohl flüchtige Events ausreichen
- Fehlende Beobachtbarkeit, sodass Fehler unentdeckt bleiben
Typische Fallen
- Versteckte Abhängigkeiten durch implizite Topics oder Queues
- Falsche Annahmen zur Nachrichtenreihenfolge über mehrere Partitionen
- Nicht getestete Recovery-Szenarien nach Broker-Ausfall
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Netzwerkzuverlässigkeit und Bandbreite
- • Anforderungen an Nachrichtenpersistenz
- • Kompatibilität mit vorhandenen Protokollen (JMS, AMQP, MQTT)