Kann jemand erklären, für was Message Broker verwendet werden?

7

In meiner Arbeit ist es schwer, fünf Minuten zu gehen, ohne dass jemand die Vorzüge der MQ-Serie oder MSMQ oder Ähnliches preist, und ich frage mich immer wieder, ob nach dem Funkeln der Schlagworte tatsächlich Beispiele

Was ich suche, ist etwas, das mich dazu inspirieren könnte, einen Nutzen für einen von diesen zu finden oder mir eine Art Metrik zu geben, die ich verwenden kann, um einen Nachrichtenbus / Nachrichtenbroker / Nachrichtenwarteschlange auszuwerten - Hölle, sogar etwas das wird erklären, was die Unterschiede zwischen den oben genannten Nachrichten * Dinge sind.

    
Chris R 08.04.2009, 14:45
quelle

6 Antworten

11

Message Queuing-Lösungen wie MQ Series oder MSMQ werden häufig zur Integration verteilter Unternehmensanwendungen eingesetzt, insbesondere auf verschiedenen Plattformen. Richtig gemacht (mit persistenten Warteschlangen, asynchronem Design anstatt "RPC über MQ" und Beachtung der betrieblichen Anforderungen), bietet dies eine hohe Verfügbarkeit im Vergleich zu synchronen Request / Reply-Integrationen wie RPC oder Standard-Webservices ( deren Verfügbarkeit ist das Produkt der jeweiligen Verfügbarkeiten: die gleichzeitige Integration von zehn Systemen mit 99% Verfügbarkeit gibt Ihnen eine kombinierte Verfügbarkeit von nicht mehr als 90% - oder schlechter, wenn es nur eine schwache Verbindung gibt. Beachten Sie jedoch, dass die Nachrichtenwarteschlangen in sich selbst eine hohe Verfügbarkeit aufweisen müssen: Wir verwenden unseren Mainframe für diesen Zweck (nehmen Sie an, welches Produkt wir verwenden!).

Message (oder Integration) Broker und "Busse" sind ein komplexerer Kessel Fisch. Sie können

hinzufügen
  • Übersetzung zwischen verschiedenen Inhaltsdarstellungen (Textkodierungen und Codepages)
  • Überwachung , die erkennt, wenn ein Zielsystem Nachrichten in der Warteschlange nicht aufnimmt und Alarme auslöst oder automatisch neu startet
  • Transformation , wenn Systeme nicht dieselbe Sprache sprechen und z. Kunden- oder Produktdatensätze anders: Dies kann Ihnen im Prinzip helfen, neue Versionen mit unterschiedlichen Raten bereitzustellen.
  • Routing (bis einschließlich Publish / Subscribe), um ein sendendes System von der Kenntnis der Details der Empfänger zu entkoppeln und so die Auswirkungen von Änderungen in Zielsystemen zu reduzieren
  • Orchestrierung , in der Sie Nachrichten zwischen einer Reihe von Systemen koordinieren können, um einen längeren Geschäftsprozess im realen Leben nachzuverfolgen (z. B. von der Kundenbestellung über die Zustellung bis zur Rechnungsstellung).

Ich habe diese Funktionen in ungefähr zunehmender Reihenfolge der Schwierigkeit (und mögliche Belohnung) aufgelistet. Je höher Sie sind, desto reifer muss Ihre Organisation (einschließlich der Geschäftsseite) sein, um die Vorteile zu erhalten.

    
Pontus Gagge 08.04.2009, 15:09
quelle
4

Ohne auf bestimmte Produkte eingehen zu müssen, kann ich Ihnen einige Vorteile bei der Verwendung eines typischen Nachrichtenwarteschlangensystems nennen.

Sie sind typischerweise eine gute Infrastruktur zum Simulieren des Publisher / Subscriber-Musters. Stellen Sie sich ein großes Event-System vor, bei dem Sie nicht auf eine ausführbare Datei oder einen einzigen Computer beschränkt sind. Sie legen Informationen in diese Warteschlangen, so dass die Daten von jeder Anwendung, die darauf wartet, abgerufen werden können.

Die meisten Nachrichtenwarteschlangensysteme ermöglichen persistente Warteschlangen. Denken Sie an ein typisches Ereignissystem. Wenn der Listener zum Zeitpunkt des Ereignisses nicht verbunden ist oder nicht mehr reagiert, wird das Ereignis verpasst. Bei einer persistenten Nachrichtenwarteschlange verbleibt die Nachricht in der Warteschlange, bis der Listener wieder verbunden wird. Auf diese Weise gehen keine Daten / Ereignisse verloren.

Ich weiß nichts über die Produkte, die Sie aufgelistet haben, aber ich weiß, dass Sie mit JMS eine fein abgestimmte Kontrolle über das Threading haben können, wenn Nachrichten aus der Warteschlange ausgegeben werden. Theoretisch könnten Sie einen Thread pro Warteschlange haben, der Aktionen in diesem Thread durchführt, in den Nachrichten, wenn diese abgerufen werden. Alternativ können Sie Nachrichten aus mehreren Warteschlangen abrufen und Aktionen für sie ausführen, und zwar innerhalb eines gemeinsamen Threads.

    
Brad Barker 08.04.2009 14:56
quelle
4

Obwohl ich eine bittere Erfahrung mit der MQ-Serie hatte, zum Teil aufgrund der Tatsache, dass sie von der Partnerfirma an uns (einen Microsoft-Shop) weitergegeben wurde, war die Verwendung der MQ-Serie (oder eines beliebigen Messaging-Systems) ein integraler Bestandteil zur Anwendung.

Im Wesentlichen bauten wir einen Prozess auf, der die Lieferkettenabwicklung für Rückstandsartikel abwickelte. Wenn unser Partner einen Vertriebshändler nicht über die Artikel verfügt, die seine Kunden wünschen, sendet er eine Nachricht an eine B2B-Website, die potenzielle Unternehmen adressiert, die die Bestellung ausführen können.

Wir hatten zwei verschiedene Integrationsvarianten entwickelt. Der erste war ein FTP-Ansatz, bei dem Dateien mit fester Breite in regelmäßigen Abständen hin- und hergeschickt wurden und wir alle möglichen Regeln hinzugefügt hatten, um sicherzustellen, dass wir keine Daten verloren haben.

Bei der zweiten wurde die MQ-Serie verwendet, bei der die Nachrichten mit garantierter Zustellung in eine Warteschlange gestellt wurden. Dann würden wir die Warteschlange öffnen und die Nachrichten verarbeiten. Das Warteschlangensystem war ein großer Vorteil, da es uns eine zuverlässige Möglichkeit bot, kritische Nachrichten zu übertragen, die dazu führten, dass echtes Geld bewegt wurde.

Auf der anderen Seite mit der gleichen MQ-Serie mussten wir eine synchrone Abfrage implementieren, um Informationen zu erhalten. Wir wollten, dass es synchron ist, weil unsere Benutzer, die darauf über das Web zugreifen, warten würden, um die Information zu erhalten. Dies über die MQ-Serie zu tun, war eine sehr interessante und schmerzhafte Herausforderung. Der einzige Grund, warum MQ hier verwendet wurde, war, dass es eine bestehende Kommunikationslinie war und die Abfragefunktionalität bereits existierte.

Ein zweites Beispiel, bei dem MSMQ eine Site war, die Informationen aus Dialhome-Code sammelte, die in Clientanwendungen injiziert wurden. Der Dialhome-Code würde Feature-Nutzungsstatistiken wie Microsoft's SQM-Programm sammeln. Wenn die Nachrichten in den Web-Service eintraten, würden wir sie in einer Warteschlange ablegen. Dann könnten wir eine beliebige Anzahl von Anwendungsservern veranlassen, die Nachrichten zu puffen und sie in die Datenbank zu schieben, um sie in das Warehouse einzurollen.

MSMQ stellte hier sicher, dass wir Nachrichtenbündel verarbeiten konnten, indem wir sie schnell in die Warteschlange stellten. Dies hilft die Skalierbarkeit und Zuverlässigkeit des Systems.

    
JoshBerke 08.04.2009 15:03
quelle
3

Ein gutes Warteschlangensystem macht es einfacher, verteiltes Rechnen über mehrere Threads, Prozessoren, Maschinen (und sogar Organisationen) durchzuführen.

Vor einiger Zeit (10 Jahre) habe ich eine Metaphern-Nachricht verwendet, um ein Front-Office-Optionspreissystem für einen Interdealer-Broker zu implementieren. Wir hatten Services in C ++, VB6 und Excel / VBA implementiert (sogar mit dem Excel-Solver !!), Datenspeicher als flache Dateien und SQL, Endbenutzer-Anwendungen in Excel und VB6 geschrieben, mit einem komplexen Datenmodell (Marktdaten, Ausbeute Kurven und Vol-Oberflächen). Asynchrones Messaging (mit persistenten / zuverlässigen Nachrichten und Pub / Sub) hat die ganze Sache sehr effektiv und skalierbar funktionieren lassen - wir konnten Büros in Tokio und NY der Londoner Infrastruktur hinzufügen, ohne die entfernte Seite zu besuchen - nur eine Standardinstallation / p>

Ich bin ein großer Fan, obwohl ich überrascht bin, wie weit sie in den letzten zehn Jahren nicht gekommen sind.

    
DangerMouse 02.12.2009 11:52
quelle
2

Eine Nachrichtenwarteschlange ist nützlich, um den Lastenausgleich zu implementieren. Der Server empfängt beispielsweise "Job" -Nachrichten (Aufträge, Statusmeldungen usw.) und verteilt sie an alle Listening-Clients.

Die Nachrichtenwarteschlange garantiert, dass eine Nachricht an genau einen Client gesendet wird.

Wenn die Clients auf verschiedenen Computern laufen, wird die Gesamtlast verteilt und es wird leicht möglich sein, einen weiteren Client zur Nachrichtenladung zu werfen, wenn nötig, der Client muss sich nur mit der Warteschlange verbinden und erhält (teilweise) die Nachrichten.

    
mjn 08.04.2009 15:25
quelle
1

Ein sehr "nah an der Anfrage" Beispiel vom realen Projekt. Wer läuft seit mehreren Jahren. Auf ActiveMQ

1) Handelszentrum für den Schifffahrtsmarkt.

  • Versandunternehmen haben ein System, das weiß, wie viele Pakete sie in Echtzeit versenden können.

  • Jedes System ist anders (Sprache, Design ...)

  • Wir haben für jedes Unternehmen ein "sehr spezielles IT-System für ActiveMQ" entwickelt

  • Jeder Adapter hat eine einfache Aufgabe: posten, wenn die Firma freien Speicherplatz hat und zu welchem ​​Preis. (ein "Transportvorschlag")

  • Wir haben einen Kunden geschrieben, der alle "Transportvorschläge" sammelt und sie gut darstellt.

= & gt; Ta-da. Sie haben ein plattformübergreifendes / Sprach- / Prozesssystem für Compagny, die nicht miteinander reden wollen

= & gt; Ta-da 2: Wenn eine neue Firma in Ihr Handelssystem kommen will, muss sie nur den Adapter schreiben.

    
Antoine Claval 02.12.2009 12:01
quelle