Messaging mit RabbitMQ
Neben dem direkten Weg über HTTP kommunizieren die Dienste von buzzle Commerce Core ereignisgetrieben über einen Nachrichtenbus. Als Transport dient RabbitMQ, angesteuert über die .NET-Bibliothek Rebus. Dieser asynchrone Weg entkoppelt die Bausteine der Plattform und macht sie robust und erweiterbar.
Warum ein Nachrichtenbus
Abschnitt betitelt „Warum ein Nachrichtenbus“Manche Vorgänge sollen nicht warten und nicht fest verdrahtet sein. Wenn ein Benutzer angelegt oder ein Auftrag abgeschlossen wird, müssen oft mehrere Dinge geschehen – aber der auslösende Dienst soll sich nicht darum kümmern müssen, wer das ist. Ein Nachrichtenbus löst das:
- Lose Kopplung – Sender und Empfänger kennen einander nicht; sie teilen nur die Nachricht.
- Robustheit – Nachrichten werden zwischengespeichert und bei Bedarf erneut zugestellt; ein kurz nicht erreichbarer Empfänger verliert nichts.
- Erweiterbarkeit – neue Empfänger kommen hinzu, ohne den Sender zu ändern.
- Lastausgleich – Hintergrundarbeit wird entkoppelt von der Antwortzeit einzelner Anfragen verarbeitet.
Zwei Nachrichtenarten
Abschnitt betitelt „Zwei Nachrichtenarten“Die Plattform nutzt zwei Muster, jedes für seinen Zweck:
- Ereignisse (Publish/Subscribe) – „etwas ist passiert”. Ein Dienst veröffentlicht ein Ereignis; beliebig viele interessierte Dienste haben es abonniert und reagieren. Der Sender weiss nicht, wer zuhört. So werden etwa Rollenzuweisungen oder Benutzeränderungen verbreitet.
- Befehle (gerichtete Zustellung) – „tu etwas”. Ein Befehl wird gezielt an eine bestimmte Eingangs-Queue eines Empfängers gesendet. So erhält etwa die ZitadelBridge ihre Aufträge zum Anlegen, Sperren oder Einladen von Benutzern.
Stabile, versionsunabhängige Topic-Namen
Abschnitt betitelt „Stabile, versionsunabhängige Topic-Namen“Damit Publisher und Subscriber zuverlässig zueinanderfinden, verwendet die Plattform kurze,
deterministische Topic-Namen, die bewusst keine Assembly-Version enthalten. Ein
Herausgeber und ein Abonnent spielen so zusammen, unabhängig davon, gegen welche Programmversion
sie gebaut wurden. Möglich wird das durch eine einheitliche Namenskonvention, die auf allen
Beteiligten – Service Platform wie ZitadelBridge – identisch umgesetzt ist. Die beschreibenden,
versionierten Nachrichtennamen (etwa mit Suffix V1) stellen sicher, dass jeder Nachrichtentyp
eindeutig bleibt.
Über Attribute an den Nachrichtentypen lassen sich Domäne und Aggregat für die Topic-Bildung steuern, sodass die Themen sprechend und dennoch stabil bleiben.
Wie Module am Bus teilnehmen
Abschnitt betitelt „Wie Module am Bus teilnehmen“Jedes Modul der Service Platform kann am Bus teilnehmen, ohne die Transportdetails selbst zu kennen. Es meldet über einen Konfigurator an,
- welche Nachrichten es verarbeitet (Handler für Ereignisse oder Befehle) und
- welche Ereignistypen es abonniert.
Die gemeinsame Infrastrukturschicht kümmert sich um Verbindung, Routing, Serialisierung und Zustellung. Zum Veröffentlichen und Senden nutzen die Module eine schlanke, einheitliche Schnittstelle mit den Operationen Publish (Ereignis) und Send (Befehl).
Verlässliche Verarbeitung
Abschnitt betitelt „Verlässliche Verarbeitung“Rebus sorgt für die verlässliche Abarbeitung: Nachrichten werden von mehreren Arbeitern parallel verarbeitet, und die Zustellung ist so ausgelegt, dass vorübergehende Störungen nicht zu Datenverlust führen. In Kombination mit den Health-Checks der Dienste ist der Zustand des Messagings jederzeit überprüfbar.
Einordnung
Abschnitt betitelt „Einordnung“Der Nachrichtenbus ist das Bindegewebe, das die Dienste von buzzle Commerce Core zusammenhält, ohne sie fest zu verknüpfen. Er ist die Grundlage für die ereignisgetriebenen Prozesse der Plattform – von der Benutzer-Provisionierung über die Suchindexierung bis zum Audit-Trail.