Was ist RabbitMQ?
In jeder cloudnativen App müssen Microservices kommunizieren, um alle Informationen zu erhalten, die sie für die Antwort für Benutzer benötigen. Sie sollten sicherstellen, dass dieses Messaging stabil ist, auch wenn Netzwerkprobleme oder Fehler zwischen den Integrationen auftreten. RabbitMQ ist ein Tool, mit dem Sie die Zuverlässigkeit des Messagings erhöhen können.
Bei Ihrem Einzelhändler für Outdoorausrüstung machen Sie mit Ihren Microservices rasche Fortschritte. Beim Testen von Anwendungen gehen jedoch einige Aufrufe von einem Microservice zu einem anderen scheinbar verloren. Sie möchten sicherstellen, dass dieses Problem nicht in Ihrer Produktionsumgebung auftritt, in der der Ruf Ihres Unternehmens auf dem Spiel steht.
In dieser Einheit sehen Sie, wie RabbitMQ eine flexible und resiliente Kommunikationsplattform für Microservices erstellen kann.
Gründe für die Verwendung eines Nachrichtenbrokers in einer cloudnativen App
Cloudnative Apps bestehen aus unabhängigen Microservices, die häufig von separaten Teams erstellt werden und verschiedene Technologien und Sprachen verwenden. Jedes Team verfügt über eigene Entwicklungssprints und Upgradezeitpläne und kann kontinuierlich Fixes und neue Features bereitstellen. Wenn jedoch eine Anforderung von einem Benutzer eingeht, muss der Microservice, der sie empfängt, fast immer andere Microservices und Sicherungsdienste aufrufen und Antworten von ihnen erhalten, um die vollständige Antwort zu formulieren.
Das Format und das Schema dieser dienstübergreifenden Anfragen und Antworten müssen natürlich zwischen den Entwicklungsteams abgestimmt werden. Sie ändern sich nur selten. Sie werden in der Regel als REST-APIs implementiert. Sie sollten bevorzugt neue Features jeder Schnittstelle implementieren, ohne vorhandene Methoden und Parameter zu ändern. Wenn Sie sich jedoch für die direkte Kommunikation zwischen Microservices entscheiden, können mehrere Probleme auftreten:
- Was geschieht mit an einen Zielmicroservice gesendete Nachrichten, wenn dieser Microservice offline oder ausgelastet ist? Welche Folgen hat der Nachrichtenverlust?
- Wie können Sie dieselbe Nachricht an mehrere Ziele senden?
- An welchen Container sollten Sie Nachrichten senden, wenn ein Microservice in mehr als einem Container ausgeführt wird?
Ein Nachrichtenbroker ist Middleware, die diese Probleme behandelt. Dienste senden Nachrichten an den Nachrichtenbroker statt direkt an ein Ziel. Der Broker speichert sie in der Reihenfolge, in der sie eingehen, in Warteschlangen. Zieldienste abonnieren diese Warteschlangen und nehmen Nachrichten einzeln zur Verarbeitung auf.
Wenn der Zieldienst nicht verfügbar ist, kann der sendende Microservice weiterhin Nachrichten in der Warteschlange platzieren. Wenn das Ziel neu gestartet wird, nimmt es weiterhin Nachrichten aus der Warteschlange ab demselben Punkt auf. Es gehen keine Nachrichten verloren, obwohl der Absender länger warten muss.
Da mehrere Ziele eine Warteschlange abonnieren können, kann eine einzelne Nachricht von mehr als einem Microservice empfangen werden. Wenn mehrere Container Instanzen eines einzelnen Microservice hosten, nimmt darüber hinaus die erste Instanz, die verfügbar wird, die Nachricht auf. Der Broker verteilt Nachrichten automatisch an Instanzen, um die Last zu verteilen.
Was ist RabbitMQ?
RabbitMQ ist einer der beliebtesten Nachrichtenbroker und verfügt über viele Funktionen, die ihn zu einem idealen Kandidaten für die Behandlung der Kommunikation in einer cloudnativen App machen. Sie hat folgenden Inhalt:
- Der RabbitMQ-Server, der die Warteschlangen hostet. Der Server unterstützt Clustering und Failover zum Ermöglichen von Hochverfügbarkeit und kann in Containern ausgeführt werden.
- Implementierungen von AMQP (Advanced Message Queuing Protocol), STOMP (Simple Text Oriented Message Protocol) und MQTT (Message Queuing Telemetry Transport).
- AMQP-Clientbibliotheken, die Sie in .NET, Java und Erlang verwenden können.
RabbitMQ-Konzepte
Im Zusammenhang mit RabbitMQ sind Ihre Microservices, die Nachrichten senden und empfangen, Clients. Clients, die Nachrichten senden, werden als Nachrichtenproducer bezeichnet. Clients, die Nachrichten empfangen, sind Nachrichtenconsumer. Der RabbitMQ-Dienst ist der Nachrichtenbroker.
Senden von Nachrichten
RabbitMQ ist vielseitig und in der Lage, viele verschiedene Warteschlangenmodelle zu implementieren. Sehen wir uns einige beliebte Muster an.
Wenn Sie über einen einzelnen Producer und einen einzelnen Consumer verfügen, verwenden Sie eine einzelne Warteschlange, und alle Nachrichten erreichen dasselbe Ziel. Selbst in dieser einfachen Konfiguration erstellen Sie ein stabiles Messagingsystem, das Ausfälle problemlos bewältigt:
Senden von Nachrichten an konkurrierende Consumer
Im Modell konkurrierender Consumer sendet ein Producer Nachrichten an eine einzelne Arbeitswarteschlange. Mindestens zwei Consumer rufen Nachrichten aus der Warteschlange ab. Die Consumer konkurrieren beim Abrufen von Nachrichten, da jede Nachricht nur von einem einzelnen Consumer abgerufen werden kann.
Dieses Muster ist bei cloudnativen Apps nützlich, wenn Sie einen Consumer-Microservice haben, der auf mehreren Containern gehostet wird, um die Kapazität zu steigern. Jede Nachricht erreicht nur eine Instanz des Consumers und wird also nur einmal verarbeitet. Die Arbeit wird nicht dupliziert.
Veröffentlichen und Abonnieren
Wenn Sie eine einzelne Nachricht von einem Producer an mehrere Consumer senden möchten, verwenden Sie das Modell Veröffentlichen/Abonnieren. Der Producer sendet Nachrichten an eine Austauschinstanz. Jeder Consumer abonniert Nachrichten von diesem Austausch. Beim Abonnieren erstellt RabbitMQ eine neue Arbeitswarteschlange für dieses Abonnement. Jede Nachricht wird in jede Warteschlange für diesen Austausch kopiert und von jedem Consumer empfangen, der ihn abonniert hat. Consumer konkurrieren nicht um jede Nachricht. Stattdessen erhalten sie alle eine Kopie jeder Nachricht.
Das Modell „Veröffentlichen/Abonnieren“ verwendet einen Auffächerungsaustausch, der jede Nachricht in jede Arbeitswarteschlange kopiert.
Dieses Muster ist nützlich, wenn jede Nachricht von mehreren Microservices verarbeitet werden soll. Wenn ein Kunde beispielsweise einen Warenkorb auscheckt, möchten Sie vielleicht eine Nachricht über die Anzahl der gekauften Produkte senden. Diese Nachricht sollte sowohl den Microservice für den Versand erreichen, um das Lager mit dem Verpacken des Pakets zu beauftragen, als auch den Microservice für den Bestand, um die Bestandszahlen zu verringern und möglicherweise Bestellungen bei Lieferanten auszulösen.
Routing von Nachrichten und Themen
Manchmal möchten Sie einzelne Nachrichten an mehrere Consumer verteilen, aber für jeden Consumer einen Filter anwenden. Dieses Muster wird als Nachrichtenrouting bezeichnet. Wie beim Modell „Veröffentlichen/Abonnieren“ abonnieren Consumer den Austausch, um mehrere Arbeitswarteschlangen zu erstellen. Anstelle eines Auffächerungsaustauschs verwendet das Modell jedoch einen direkten Austausch. Bei diesem Austausch verfügt jedes Abonnement über einen Bindungsschlüssel. Nur Nachrichten, deren Routingschlüssel dem Bindungsschlüssel entspricht, werden an dieses Abonnement gesendet. Andere werden herausgefiltert.
Dieses Muster ist nützlich, wenn einige Consumer nur eine Teilmenge des Nachrichtenstreams verarbeiten sollen Angenommen, Sie haben einen Microservice, der Nachrichten sendet, wenn Fehler auftreten. Alle Fehler sollen an den Microservice für die Protokollierung gesendet werden. Kritische Fehler sollen an den Microservice für die Verwaltung gesendet werden, der Techniker benachrichtigt, das Problem zu beheben.
Beim direkten Austausch werden Nachrichten basierend auf einem einzigen Kriterium weitergeleitet. Um die Umgebung noch flexibler zu gestalten, können Sie einen Themenaustausch verwenden. Für jede Nachricht können Sie einen Routingschlüssel mit mehreren Begriffen verwenden, die durch Punkte getrennt sind. Im Bindungsschlüssel können Sie den Platzhalter * verwenden, um genau ein Wort zu ersetzen, oder den Platzhalter #, um null oder mehr Wörter zu ersetzen.
Hinweis
Alternativen zu RabbitMQ sind Apache Kafka und Azure Service Bus. Beide Nachrichtenbroker werden von dedizierten Integrationen in .NET Aspire unterstützt. Sie erfahren in einem späteren Modul in diesem Lernpfad mehr über Azure Service Bus.