Messaging
Entkoppelte Kommunikation über Nachrichten
Die Idee und ihr Nutzen
Nach einem Sturm melden bei einer Versicherung innerhalb einer Stunde 20.000 Kunden ihre Schäden über das Schadenportal. Der Regulierungsdienst, der die Meldungen prüft, schafft aber nur etwa 5.000 pro Stunde. Statt jede Meldung direkt an den Regulierungsdienst zu schicken und auf dessen Antwort zu warten, legt das Schadenportal jede Meldung als Nachricht in eine Warteschlange, einen Zwischenspeicher, in dem die Nachrichten der Reihe nach auf ihre Abholung warten. Der Regulierungsdienst holt die Meldungen dort nach und nach ab. So kann das Schadenportal jedem Kunden sofort den Eingang bestätigen, auch wenn der Regulierungsdienst mit der Prüfung stundenlang im Rückstand ist. Diese Art der Zusammenarbeit über zwischengespeicherte Nachrichten heißt Messaging.
Wie funktioniert es?
Nach dem Sturm gehen im Schadenportal innerhalb einer Stunde 20.000 Meldungen der Kunden ein. Das Schadenportal legt jede Meldung in die Warteschlange schadenmeldungen und wartet nur, bis die Nachrichtenplattform, die die Warteschlange verwaltet, „angenommen“ bestätigt. Danach antwortet das Schadenportal dem Kunden „Ihre Meldung ist eingegangen“. Der Kunde muss nicht warten, bis sein Schaden geprüft ist. Der Regulierungsdienst holt die nächste Meldung aus der Warteschlange, sobald er wieder eine bearbeiten kann. Bei etwa 5.000 Meldungen pro Stunde braucht er für 20.000 Meldungen mindestens vier Stunden reine Bearbeitungszeit; neue Meldungen, Pausen oder Fehler verlängern den Rückstand. Nach jeder bearbeiteten Meldung bestätigt der Regulierungsdienst der Nachrichtenplattform „verarbeitet“. Erst dann entfernt die Nachrichtenplattform die Meldung aus der Warteschlange. Stürzt der Regulierungsdienst vorher ab, stellt die Nachrichtenplattform die Meldung erneut zu. Muss der Regulierungsdienst zwischendurch für eine Wartung angehalten werden, bleiben die Meldungen so lange in der Warteschlange liegen, sofern die Nachrichtenplattform erreichbar ist und genug Platz hat.
Eine Nachricht ist ein in sich abgeschlossenes Datenpaket, das ein Programm an ein anderes schickt. Die Nachrichtenplattform ist ein eigenes Programm, das Nachrichten annimmt, aufbewahrt und zustellt. Die Nachrichten liegen dort in benannten Ablagen, den Kanälen. Es gibt zwei verbreitete Grundformen von Kanälen. Beim Point to Point Channel geht jede Nachricht an genau einen Empfänger. Ein solcher Kanal heißt meist Warteschlange, so wie schadenmeldungen. Bei Publish Subscribe erhält jeder angemeldete Empfänger eine eigene Kopie der Nachricht.
Das Schadenportal ist hier der Absender, der Regulierungsdienst der Empfänger. Absender und Empfänger müssen nicht gleichzeitig laufen und nicht gleich schnell sein. Sie kennen einander nicht, sondern nur den Kanal: Das Schadenportal kennt nur die Warteschlange schadenmeldungen und muss nicht wissen, wo der Regulierungsdienst zu finden ist.
Die Nachrichtenplattform bewahrt jede Nachricht nach den Regeln auf, die für den Kanal eingestellt sind, etwa wie viele Nachrichten der Kanal höchstens aufnimmt. Damit Nachrichten auch einen Absturz der Nachrichtenplattform überstehen, muss die Nachrichtenplattform jede Nachricht auf die Festplatte schreiben, statt sie nur im Arbeitsspeicher zu halten. Diese dauerhafte Speicherung muss ausdrücklich eingestellt sein. Außerdem muss die Nachrichtenplattform auf mehreren Servern laufen, damit der Ausfall eines Servers die Warteschlange nicht anhält. Messaging sorgt nur dafür, dass eine Nachricht aufbewahrt wird, bis der Empfänger sie abholt. Dass eine Meldung schnell bearbeitet wird, garantiert Messaging nicht. Auch die Bestätigung „angenommen“ sagt nichts über das fachliche Ergebnis beim Regulierungsdienst. Das Schadenportal darf deshalb nur den Eingang bestätigen und nicht anzeigen, der Schaden sei schon geprüft. Ob der Schaden gedeckt ist, erfährt der Kunde erst, wenn der Regulierungsdienst die Meldung des Kunden bearbeitet hat.
Hat der Regulierungsdienst eine Meldung vor einem Absturz schon geprüft, aber noch nicht bestätigt, erhält er dieselbe Meldung nach dem Neustart ein zweites Mal. Der Regulierungsdienst muss deshalb erkennen können, dass er die Meldung schon bearbeitet hat, zum Beispiel an der Meldungsnummer. Bleibt die Bestätigung „angenommen“ beim Schadenportal aus, weiß das Schadenportal nicht, ob die Meldung angekommen ist. Das Schadenportal darf dem Kunden dann keinen Eingang bestätigen, sondern muss die Meldung erneut ablegen oder einen Fehler anzeigen.
Messaging: 20.000 Meldungen warten in der Warteschlange
Wann ist es sinnvoll und wann nicht?
Messaging lohnt sich
- Der Absender muss nicht auf das Ergebnis warten. Kunden erwarten im Schadenportal sofort eine Rückmeldung, die fachliche Prüfung ihres Schadens darf aber Stunden dauern. Bei einem direkten Aufruf müsste der Kunde warten, bis der Regulierungsdienst seinen Schaden geprüft hat.
- Die Zahl der Meldungen schwankt stark. An normalen Tagen schafft der Regulierungsdienst alle Meldungen ohne Rückstand, nach einem Sturm kommen viermal so viele, wie er verarbeiten kann. Bei einem direkten Aufruf müsste der Regulierungsdienst alle Meldungen sofort bewältigen oder abweisen.
- Der Regulierungsdienst soll unabhängig vom Schadenportal zur Wartung angehalten werden können. Bei einem direkten Aufruf scheitert in dieser Zeit jede Schadenmeldung, und Kunden sehen eine Fehlermeldung.
- Programme, die zu unterschiedlichen Zeiten verfügbar sind, sollen verbunden werden. Ein Beispiel ist ein Altsystem, das nachts für Wartungsarbeiten abgeschaltet wird. Bei einem direkten Aufruf scheitert in dieser Zeit jede Übergabe an das Altsystem.
- Schadenportal und Regulierungsdienst werden von verschiedenen Teams betrieben. Bei einem direkten Aufruf muss das Schadenportal bei jeder Änderung der Adresse des Regulierungsdienstes angepasst werden, und jede Störung im Regulierungsdienst wird sofort zu einer Störung im Schadenportal.
Messaging ist nicht das Richtige
- Der Absender braucht die Antwort sofort. Ein Beispiel: Ein Kunde wartet auf die Berechnung seines Beitrags. Mit Messaging läge die Anfrage in einer Warteschlange, bis das Programm für die Beitragsberechnung sie abholt, und niemand weiß vorher, wie lange das dauert. Dann ruft das Programm, in dem der Kunde wartet, das Programm für die Beitragsberechnung direkt auf und wartet auf die Antwort, etwa über REST oder einen Remote Procedure Call. Eine Nachrichtenplattform entfällt, und ein Entwickler sieht im Code, welches Programm die Beitragsberechnung aufruft. Beide Programme müssen dafür aber gleichzeitig laufen.
- Absender und Empfänger sind zwei Teile desselben Programms, und die Zahl der Anfragen schwankt kaum. Es gibt dann keinen Rückstand, den eine Warteschlange auffangen müsste, und beide Teile laufen ohnehin gleichzeitig. Dann ruft der eine Programmteil den anderen direkt auf. Eine Nachrichtenplattform, die betrieben, abgesichert und überwacht werden muss, entfällt.
- Der Empfänger kann doppelt oder in anderer Reihenfolge ankommende Nachrichten nicht erkennen, und ein doppelt ausgeführter Vorgang wäre nicht hinnehmbar. Ein Beispiel ist eine zweite Auszahlung für denselben Schaden. Dann ruft der Absender den Empfänger direkt auf und wartet auf die Antwort. So stellt keine Nachrichtenplattform einen Auftrag nach einem Absturz von selbst ein zweites Mal zu. Der Absender schickt die Aufträge zu einem Schaden nacheinander, jeden erst nach der Antwort auf den vorigen. Bleibt eine Antwort aus, schickt der Absender den Auftrag nicht einfach erneut, sondern ein Sachbearbeiter prüft zuerst, ob die Auszahlung schon erfolgt ist.
- Die Meldungen müssen erst am nächsten Morgen bearbeitet sein. Dass der Regulierungsdienst jede Meldung sofort abholen kann, bringt dann nichts. Dann sammelt das Schadenportal die Meldungen in seiner Datenbank und übergibt sie nachts gesammelt an den Regulierungsdienst. Dieses Vorgehen heißt Batch Processing. Eine Nachrichtenplattform, die rund um die Uhr läuft und überwacht werden muss, entfällt.
Nachteile und typische Fehler
Die Nachrichtenplattform ist ein zusätzliches Programm, das betrieben, abgesichert und überwacht werden muss. Für jeden Kanal muss eingestellt werden, ob Nachrichten dauerhaft gespeichert werden, wie viele Nachrichten der Kanal höchstens aufnimmt und was mit Nachrichten geschieht, die sich nicht verarbeiten lassen. Weil Nachrichten doppelt oder in anderer Reihenfolge ankommen können, braucht der Regulierungsdienst zusätzlichen Code, der doppelte und vertauschte Nachrichten erkennt. Abläufe über viele Nachrichten sind schwerer nachzuvollziehen als direkte Aufrufe. Bei einem direkten Aufruf sieht ein Entwickler im Code des Schadenportals, welches Programm aufgerufen wird. Bei Messaging sieht er dort nur die Warteschlange schadenmeldungen und muss erst herausfinden, welches Programm die Meldungen abholt. Die Abhängigkeit zwischen beiden Programmen verlagert sich vom Aufruf auf den Inhalt der Nachricht: Ändert das Schadenportal den Aufbau einer Schadenmeldung, muss der Regulierungsdienst den neuen Aufbau verstehen.
Typische Fehler und woran man sie erkennt:
- Unbemerkte Störung: Eine Störung zeigt sich nicht als sofortige Fehlermeldung, sondern als Warteschlange, die stetig länger wird. Der Regulierungsdienst hängt zum Beispiel nach einem Fehler und holt keine Meldungen mehr ab. Das Schadenportal legt weiter Meldungen ab und bestätigt den Kunden den Eingang. Ohne Überwachung der Länge der Warteschlange bemerkt das niemand. Erkennbar ist das an einer Warteschlange
schadenmeldungen, die auch nach dem Sturm nicht kürzer wird, und an Kunden, die nach Tagen noch keine Rückmeldung zu ihrem Schaden haben. - Doppelt bearbeitet: Der Regulierungsdienst prüft eine Meldung und legt dafür einen Schadenvorgang an. Vor der Bestätigung „verarbeitet“ stürzt der Regulierungsdienst ab. Nach dem Neustart stellt die Nachrichtenplattform dieselbe Meldung erneut zu. Der Regulierungsdienst erkennt die Meldungsnummer nicht wieder und legt für denselben Schaden einen zweiten Vorgang an. Erkennbar ist das an Schadenvorgängen mit derselben Meldungsnummer.
- Falsche Reihenfolge: Ein Kunde schickt wenige Sekunden nach seiner Schadenmeldung eine Ergänzung nach. Der Regulierungsdienst stürzt bei der Schadenmeldung ab, bevor er „verarbeitet“ bestätigt. Die Nachrichtenplattform stellt die unbestätigte Schadenmeldung erst nach einer Wartezeit erneut zu. Nach dem Neustart erhält der Regulierungsdienst deshalb zuerst die Ergänzung. Der Regulierungsdienst findet keinen passenden Schaden und verwirft die Ergänzung. Erkennbar ist das an Fehlermeldungen über unbekannte Schäden, die sich kurz darauf als vorhanden herausstellen.
- Bestätigung zu früh: Das Schadenportal bestätigt dem Kunden den Eingang, bevor die Nachrichtenplattform die Annahme bestätigt hat. Fällt die Nachrichtenplattform in diesem Moment aus, ist die Meldung verloren, obwohl der Kunde eine Bestätigung erhalten hat. Erkennbar ist das an Kunden mit Eingangsbestätigung, deren Meldung beim Regulierungsdienst nie angekommen ist.
- Volle Warteschlange: Die Warteschlange erreicht ihre eingestellte Höchstgröße, und die Nachrichtenplattform nimmt keine neuen Meldungen mehr an. Die Höchstgröße liegt zum Beispiel bei 10.000 Meldungen. Nach dem Sturm kommen 20.000 Meldungen in einer Stunde, und der Regulierungsdienst holt in dieser Stunde etwa 5.000 ab. Die Warteschlange wächst so um 15.000 Meldungen pro Stunde und ist nach 40 Minuten voll. Danach weist die Nachrichtenplattform jede neue Meldung ab, und das Schadenportal zeigt den Kunden eine Fehlermeldung. Erkennbar ist das an Fehlermeldungen im Schadenportal, sobald die Warteschlange voll ist.
Weiterführend
Verwandte Ansätze
- Sync vs Async: wägt ab zwischen direktem Aufruf mit Warten und Nachricht ohne Warten.
- Delivery Semantics: unterscheidet, was Nachrichtenplattformen darüber zusagen, wie oft eine Nachricht ankommt.
- Dead Letter Queue: eine Ablage für Nachrichten, die sich nicht verarbeiten lassen.
- Outbox Pattern und Inbox Pattern: sorgen dafür, dass ein Programm eine Nachricht nur dann sendet oder als empfangen vermerkt, wenn auch die zugehörige Änderung in seiner eigenen Datenbank gespeichert ist.
Werkzeuge und Umsetzungen
- RabbitMQ: verbreitete Nachrichtenplattform mit Warteschlangen und einstellbaren Weiterleitungsregeln.
- Apache Kafka: Nachrichtenplattform, die Nachrichten als dauerhaftes, geordnetes Protokoll speichert, aus dem die Empfänger lesen.
- Apache ActiveMQ Artemis: Nachrichtenplattform, die unter anderem JMS unterstützt, den Java-Standard für Nachrichten.
- NATS: Nachrichtenplattform, die Nachrichten in ihrer Grundform nur weiterreicht und nicht speichert; dauerhaftes Speichern ergänzt der Zusatz JetStream.
- Apache Pulsar: Nachrichtenplattform für Warteschlangen und Publish Subscribe, die die Speicherung auf eigene Server auslagert.
Quellen
- Gregor Hohpe, Bobby Woolf: Enterprise Integration Patterns, Messaging: beschreibt Messaging als zuverlässige, nicht wartende Übertragung von Datenpaketen, bei der Absender und Empfänger nicht gleichzeitig laufen müssen und voneinander gelöst sind.
- RabbitMQ: Consumer Acknowledgements and Publisher Confirms: Dokumentation einer verbreiteten Nachrichtenplattform zur Annahmebestätigung an den Absender, zur Bestätigung durch den Empfänger und zur erneuten Zustellung unbestätigter Nachrichten; sie hält fest, dass Empfänger mit doppelt zugestellten Nachrichten rechnen müssen.