Grundlagen der Nachrichtenübermittlung

Asynchrones Messaging ermöglicht die Kommunikation zwischen Diensten, ohne dass diese sich direkt aufrufen. Ein Producer legt eine Nachricht ab, und ein Consumer holt sie später ab. Dadurch werden Dienste entkoppelt, Lastspitzen geglättet und Systeme bleiben robust, wenn ein Consumer vorübergehend nicht verfügbar ist.

MassTransit ist ein .NET-Framework, das auf Message Brokern wie RabbitMQ oder Azure Service Bus aufsetzt. Es übernimmt Serialisierung, Routing, Wiederholungsversuche und mehr, sodass Sie sich auf Nachrichten und Handler konzentrieren können statt auf die Infrastruktur des Brokers.

Zwei Nachrichtenabsichten sind wichtig. Ein Command weist einen bestimmten Dienst an, etwas zu tun ("ChargePayment"). Ein Event kündigt an, dass etwas geschehen ist ("OrderPlaced"), und richtet sich an alle Interessierten. Commands haben einen Handler, Events können viele haben.

Ein Command ist ein einfacher Nachrichtentyp mit einem imperativen Namen. Senden Sie ihn an genau einen Consumer.

Ein Event wird in der Vergangenheitsform benannt und an alle interessierten Abonnenten veröffentlicht.

Eine Queue hält Nachrichten, bis ein Consumer sie verarbeitet. Sie arbeitet nach dem Punkt-zu-Punkt-Prinzip: Jede Nachricht wird genau einem Consumer zugestellt. So wird die Last auf mehrere Consumer-Instanzen verteilt (konkurrierende Consumer).

Brokers wie RabbitMQ leiten Nachrichten über Exchanges weiter. Ein Producer veröffentlicht eine Nachricht an einen Exchange, der sie an alle gebundenen Queues verteilt. So erreicht ein Event viele Abonnenten.

MassTransit ordnet Ihre Nachrichtentypen automatisch Exchanges und Queues zu. Send richtet sich an eine Queue (Command); Publish richtet sich an einen Exchange, sodass die Queue jedes abonnierten Consumers eine Kopie erhält (Event).

Der Bestelldienst veröffentlicht OrderPlaced und fährt fort. Unabhängig davon verarbeiten ein E-Mail-Dienst und ein Analysedienst das Event jeweils als Consumer. Einen neuen Abonnenten hinzuzufügen, erfordert keine Änderung am Producer.

Brokers bieten typischerweise eine Zustellung at-least-once: Nach einem Fehler kann eine Nachricht erneut zugestellt werden. Consumer sollten daher idempotent sein, damit die zweimalige Verarbeitung derselben Nachricht sicher ist.

Nutzen Sie Messaging, wenn eine Aufgabe asynchron ausgeführt werden kann, wenn Sie Dienste entkoppeln müssen oder wenn Sie Lastspitzen abfangen möchten. Für eine sofortige Antwort im Request-Response-Verfahren kann ein direkter API-Aufruf dennoch einfacher sein.

Testen Sie die Konzepte des Messaging.

Asynchrones Messaging entkoppelt Dienste über einen Broker. MassTransit abstrahiert Brokers wie RabbitMQ. Commands (imperativ, ein Handler) werden an eine Queue gesendet; Events (Vergangenheitsform, viele Handler) werden an einen Exchange veröffentlicht, der sie an Abonnenten verteilt. Rechnen Sie mit einer Zustellung mindestens einmal, und machen Sie Consumer daher idempotent.