Messaging Bridge-Muster

Dieser Artikel beschreibt das Messaging Bridge-Muster, eine Technik, mit der Sie unterschiedliche Systeme, die auf verschiedenen Messaging-Infrastrukturen aufbauen, integrieren können.

Kontext und Problem

Viele Organisationen und Workloads können unbeabsichtigt über IT-Systeme verfügen, die mehrere Messaginginfrastrukturen wie Microsoft Message Queueing (MSMQ), RabbitMQ, Azure Service Bus und Amazon SQS verwenden. Dieses Problem kann aufgrund von Fusionen oder Übernahmen auftreten, oder aufgrund der Erweiterung der aktuellen lokalen Systeme auf in der Cloud gehostete Komponenten zwecks Kosteneffizienz und Vereinfachung der Wartung.

Entwickler können diese Herausforderung angehen, indem sie die Systeme, die integriert werden, so modifizieren, dass sie über HTTP-basierte Webdienste kommunizieren. Dieser Ansatz hat jedoch Nachteile, einschließlich:

• Die Systeme müssen durch Hinzufügen eines HTTP-Clients auf einer Seite und eines HTTP-Anforderungshandlers auf der anderen Seite modifiziert werden. Die Systeme müssen dann erneut getestet und bereitgestellt werden.
• HTTP-Endpunkte müssen gehostet werden, was Komplexität hinzufügt, wenn Sie Webdienste sicher und hoch verfügbar machen.
• Häufige Netzwerkkonnektivitätsprobleme, die kundenspezifische Wiederholungsmechanismen erfordern.

Lösung

Wenn die Systeme, die integriert werden, aus Komponenten bestehen, die durch den Austausch von Nachrichten kommunizieren, verbessert das Messaging Bridge-Muster die Integration und verringert Nachteile.

In diesem Szenario stellt jedes System eine Verbindung mit einer Messaginginfrastruktur bereit. Für die Integration über verschiedene Messaging-Infrastrukturen hinweg führen Sie eine Bridge-Komponente ein, die eine Verbindung zu zwei oder mehr Messaging-Infrastrukturen gleichzeitig herstellt. Die Brücke pullt Nachrichten von einer Infrastruktur und verschiebt sie in die andere, ohne die Nutzdaten zu ändern.

Die Systeme, die integriert werden, müssen die anderen Systeme oder die Brücke nicht erkennen. Das Sendersystem ist so konfiguriert, dass bestimmte Nachrichten an eine bestimmte Warteschlange in der systemeigenen Messaging-Infrastruktur gesendet werden. Die Bridge holt diese Nachrichten ab und leitet sie an eine andere Warteschlange in einer anderen Messaging-Infrastruktur weiter, wo das Empfängersystem sie abholt.

Vorteile

• Die Systeme, die über die Messaging Bridge integriert werden, müssen nicht geändert werden. Im Idealfall wissen die Endpunkte nicht, dass die Nachrichten über eine Brücke laufen.
• Die Integration ist zuverlässiger im Vergleich zur HTTP-Alternative aufgrund der Garantie für die mindestens einmalige Nachrichtenübermittlung.
• Migrationsszenarien können flexibler sein. Endpunkte können z. B. von einer Messaginginfrastruktur zu einer anderen migriert werden, wenn es der Zeitplan zulässt, anstatt alle gleichzeitig.

Nachteile

• Erweiterte Funktionen für eine oder beide Messagingtechnologien stehen möglicherweise auf der überbrückten Route nicht zur Verfügung.
• Die überbrückte Route muss die Einschränkungen beider Technologien berücksichtigen. Die maximale Nachrichtengröße kann beispielsweise 4 MB in MSMQ sein, aber nur 64 KB in Azure Storage-Warteschlangen.

Probleme und Überlegungen

Berücksichtigen Sie bei der Implementierung des Messaging Bridge-Musters die folgenden Punkte:

• Wenn eines der integrierten Systeme auf verteilte Transaktionen angewiesen ist, z. B. Microsoft Distributed Transaction Coordinator (DTC), müssen Sie einen Deduplizierungsmechanismus in der Brücke implementieren.

• Wenn eines der Systeme, die integriert werden, keine Messaginginfrastruktur verwendet und nicht geändert werden kann, können Sie die Messaging-Brücke zwischen der Infrastruktur, die vom anderen System verwendet wird, und einer SQL Server-emulierten Warteschlange erstellen. Das Legacy-System kann Nachrichten senden, indem das Feature Change Data Capture für SQL Server verwendet wird, um seine Änderungen an eine dedizierte Warteschlangentabelle zu pushen. Die Brücke kann diese Nachrichten an die tatsächliche Messaginginfrastruktur weiterleiten.

• Sie können in jeder Messaginginfrastruktur eine einzelne Warteschlange verwenden, die als Überbrückungswarteschlange festgelegt ist. Konfigurieren Sie in dieser Topologie das sendende System so, dass diese bestimmte Warteschlange als Ziel für Nachrichtentypen verwendet wird, die an das andere System gesendet werden. Sie können auch mehrere Warteschlangenpaare in jeder Messaginginfrastruktur verwenden, sodass der Absender die Brücke nicht kennen muss. Für jede Zielwarteschlange in der Messaginginfrastruktur des Zielsystems wird eine Schattenwarteschlange erstellt. Die Brücke leitet Nachrichten zwischen den Schattenwarteschlangen und ihren Gegenstücken weiter.

• Um die gewünschte Verfügbarkeit gemäß den Service-Level-Vereinbarungen (SLAs) zu erfüllen, müssen Sie die Messaging Bridge möglicherweise mit dem Ansatz Konkurrierende Consumer aufskalieren.

• Normale Komponenten für die Nachrichtenverarbeitung verwenden das Wiederholungsmuster, um vorübergehende Fehler zu behandeln. Der Wiederholungszählergrenzwert ermöglicht es Komponenten, nicht verarbeitbare Nachrichten zu erkennen und aus der Warteschlange zu entfernen, um die Blockierung der Verarbeitung aufzuheben. Die Brücke erfordert möglicherweise eine andere Wiederholungsrichtlinie, um Nachrichten nicht fälschlicherweise als „nicht verarbeitbar“ zu identifizieren, wenn ein Infrastrukturfehler auftritt. Sie können das Muster Leitungsunterbruch verwenden, um die Weiterleitung anzuhalten.

Verwendung dieses Musters

Verwenden Sie das Messaging Bridge-Muster, wenn Sie Folgendes tun müssen:

• Integrieren vorhandener Systeme mit minimalem Bedarf an Änderungen.
• Integrieren von Legacy-Anwendungen, die keine anderen Messagingtechnologien verwenden können.
• Erweitern vorhandener lokaler Anwendungen mit in der Cloud gehosteten Komponenten.
• Verbinden geografisch verteilter Systeme, wenn die Internetverbindung nicht stabil ist.
• Inkrementelles Migrieren eines einzelnen verteilten Systems von einer Messaginginfrastruktur zu einer anderen, ohne dass das gesamte System in einem Zug migriert werden muss.

Dieses Muster ist in folgenden Fällen möglicherweise nicht geeignet:

• Mindestens eines der beteiligten Systeme basiert auf einem Feature einer Messaginginfrastruktur, das in der anderen Infrastruktur nicht vorhanden ist.
• Die Integration erfolgt natürlicherweise synchron, und das initiierende System erfordert eine sofortige Reaktion.
• Die Integration hat bestimmte funktionale oder nicht funktionale Anforderungen, z. B. Sicherheits- oder Datenschutzbedenken.
• Das Datenvolumen für die Integration überschreitet die Kapazität des Messagingsystems oder macht Messaging zu einer teuren Lösung für das Problem.

Workloadentwurf

Ein Architekt sollte evaluieren, wie das Messaging Bridge-Pattern im Design seiner Workloads verwendet werden kann, um die Ziele und Prinzipien zu erreichen, die in den Säulen des Azure Well-Architected Framework behandelt werden. Zum Beispiel:

Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.

Beispiel

Es gibt eine Anwendung, die in einem .NET Framework zum Verwalten der lokal gehosteten Mitarbeiterplanung geschrieben wurde. Die Anwendung ist gut strukturiert mit separaten Komponenten, die über MSMQ kommunizieren. Die Anwendung funktioniert, und das Workloadteam hat keine Absicht, sie neu zu schreiben. Ein neuer Consumer der Terminplanungsdaten muss erstellt werden, um einem Geschäftsbedürfnis gerecht zu werden, und die IT-Strategie fordert die Erstellung neuer Software als Cloud-native Anwendungen, um die Kosten und die Lieferzeit zu optimieren.

Die asynchrone warteschlangenbasierte Architektur hat in der Vergangenheit für das Workloadteam funktioniert, sodass das Team den gleichen architektonischen Ansatz verwenden wird, aber mit der modernen Technologie „Service Bus“. Das Workloadteam möchte keine synchrone Kommunikation zwischen der Cloud und der lokalen Bereitstellung einführen, um die Wartezeit oder Nichtverfügbarkeit des einen Elements auf das andere abzumildern.

Das Team entscheidet, das Messaging Bridge-Muster zu verwenden, um die beiden Systeme zu verbinden. Das Muster besteht aus zwei Teilen. Ein Teil empfängt Nachrichten aus der vorhandenen MSMQ-Warteschlange und leitet sie an den Service Bus weiter. Der andere Teil übernimmt Nachrichten vom Service Bus und leitet sie an die vorhandene MSMQ-Warteschlange weiter.

Wenn das Implementierungsteam diesen Ansatz verwendet, nutzt es vorhandene Infrastruktur in der vorhandenen Anwendung, um in die neuen Komponenten zu integrieren. Die vorhandene Anwendung weiß nicht, dass die neuen Komponenten in Azure gehostet werden. Ebenso kommunizieren die neuen Komponenten mit der Legacy-Anwendung auf die gleiche Weise wie sie zwischen sich selbst kommunizieren, indem sie Service Bus-Nachrichten senden. Die Brücke leitet Nachrichten zwischen den beiden Systemen weiter.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Rob Bagby | Principal Architecture Content Lead
• Kyle Baley | Software-Engineer
• Udi Dahan | Gründer CEO von Particular Software
• Chad Kittel | Principal Software Engineer
• Bryan Lamos | Entwicklerbeziehungen
• Szymon Pobiega | Engineer

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Beschreibung des Messaging Bridge-Musters aus der Community für Unternehmensintegrationsmuster.
• Erfahren Sie, wie Sie eine Messaging Bridge im Java-Spring-Framework implementieren.
• QPid-Brücke kann verwendet werden, um AMQP-fähige Messagingtechnologien zu überbrücken.
• Die NServiceBus-Messaging Bridge ist eine .NET-Implementierung einer Warteschlange-zu-Warteschlange-Brücke, die eine Reihe von Messaginginfrastrukturen unterstützt, einschließlich MSMQ, Service Bus und Azure Queue Storage.
• NServiceBus.Router ist ein Open-Source-Projekt, welches das Messaging Bridge-Muster implementiert. Es ermöglicht auch das Überbrücken von mehr als zwei Technologien in einer einzigen Instanz und verfügt über erweiterte Nachrichtenroutingfunktionen.

Zugehörige Ressourcen

• Das Muster Konkurrierende Consumer stellt sicher, dass die Implementierung der Messaging Bridge die Last verarbeiten kann.
• Das Muster Wiederholen ermöglicht der Messaging Bridge die Behandlung vorübergehender Fehler.
• Das Muster Leitungsunterbruch schützt Ressourcen, wenn auf einer der Seiten der Brücke eine Downtime auftritt.