Nachrichtenwarteschlange vs. Webdienste? [geschlossen]

258

Unter welchen Bedingungen würde man Apps bevorzugen, die über eine Nachrichtenwarteschlange anstatt über Webdienste kommunizieren (ich meine hier nur XML oder JSON oder YAML oder was auch immer über HTTP, keinen bestimmten Typ)?

Ich muss zwischen zwei Apps in einem lokalen Netzwerk sprechen. Eine davon ist eine Web-App und muss Befehle für eine andere App anfordern (die auf einer anderen Hardware ausgeführt wird). Bei den Anforderungen handelt es sich beispielsweise um das Erstellen von Benutzern, das Verschieben von Dateien und das Erstellen von Verzeichnissen. Unter welchen Bedingungen würde ich XML-Webdienste (oder direktes TCP oder ähnliches) der Verwendung einer Nachrichtenwarteschlange vorziehen?

Die Web-App ist Ruby on Rails, aber ich denke, die Frage ist weiter gefasst.

Dan Rosenstark
quelle

Antworten:

315

Wenn Sie einen Webdienst verwenden, haben Sie einen Client und einen Server:

  1. Wenn der Server ausfällt, muss der Client die Verantwortung für die Behandlung des Fehlers übernehmen.
  2. Wenn der Server wieder funktioniert, ist der Client für das erneute Senden verantwortlich.
  3. Wenn der Server eine Antwort auf den Anruf gibt und der Client fehlschlägt, geht der Vorgang verloren.
  4. Sie haben keine Konflikte, das heißt: Wenn Millionen von Clients in einer Sekunde einen Webdienst auf einem Server aufrufen, fällt Ihr Server höchstwahrscheinlich aus.
  5. Sie können eine sofortige Antwort vom Server erwarten, aber Sie können auch asynchrone Anrufe verarbeiten.

Wenn Sie eine Nachrichtenwarteschlange wie RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series und Tuxedo verwenden, erwarten Sie unterschiedliche und fehlertolerantere Ergebnisse:

  1. Wenn der Server ausfällt, bleibt die Nachricht in der Warteschlange erhalten (optional auch, wenn der Computer heruntergefahren wird).
  2. Wenn der Server wieder arbeitet, erhält er die ausstehende Nachricht.
  3. Wenn der Server eine Antwort auf den Anruf gibt und der Client fehlschlägt, bleibt die Nachricht bestehen, wenn der Client die Antwort nicht bestätigt hat.
  4. Wenn Sie Konflikte haben, können Sie entscheiden, wie viele Anforderungen vom Server verarbeitet werden (nennen Sie es stattdessen Worker).
  5. Sie erwarten keine sofortige synchrone Antwort, können jedoch synchrone Anrufe implementieren / simulieren.

Nachrichtenwarteschlangen bieten viel mehr Funktionen. Dies ist jedoch eine Faustregel, um zu entscheiden, ob Sie Fehlerbedingungen selbst behandeln oder in der Nachrichtenwarteschlange belassen möchten.

sw.
quelle
1
Wenn eine SOAP / JMS- Bindung verwendet wird, gewinnt man auch bei Webdiensten eine lose Kopplung.
Koppor
Welcher Webdienst oder welche Warteschlange sollte für mehrere Mikrodienste auf der Serverseite bevorzugt werden?
Shivendra Pratap Singh
Lieber @sw. Kann ich wissen, ob dies bedeutet, dass wir MQ vor normale Websites stellen können? Angenommen, ich habe eine Wordpress-Website (LAMP-Stack). Kann ich MQ vor Apache verwenden, damit Anfragen 1 nach 1 kommen, anstatt dass alle gleichzeitig kommen? In diesem Fall sind Clients (Browser) mit MQ anstelle von Apache verbunden. Stimmt das? Aber halten Browser die HTTP-Verbindung offen und warten darauf, dass Apache antwortet? Bitte helfen Sie mir, dies ein wenig zu verstehen. Schätzen Sie Ihre Freundlichkeit.
劇場 期 劇場
@ 夏 期 劇場 Was ist Ihr Anwendungsfall? Was möchten Sie erreichen, um dem Endbenutzer mit dem Browser zu helfen?
sw.
Sind diese Bedenken bei Client / Server-Setups nicht immer noch zwischen der Warteschlange und dem Server sowie zwischen dem Client und der Warteschlange? Es scheint, dass das Client / Server-Paradigma immer noch existiert und jetzt an zwei Stellen.
ImagineerThat
75

In jüngster Zeit wurde viel darüber nachgedacht, wie REST-HTTP-Aufrufe das Konzept der Nachrichtenwarteschlange ersetzen könnten.

Wenn Sie das Konzept eines Prozesses und einer Aufgabe als Ressource einführen, beginnt der Bedarf an mittlerer Messaging-Schicht zu schwinden.

Ex:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Eine Aufgabe kann mehrere Schritte für die Initialisierung umfassen, und ein Prozess kann den Status bei Abfrage zurückgeben oder nach Abschluss an eine Rückruf-URL senden.

Dies ist denkbar einfach und wird sehr leistungsfähig, wenn Sie feststellen, dass Sie jetzt einen RSS / Atom-Feed aller laufenden Prozesse und Aufgaben ohne mittlere Ebene abonnieren können. Jedes Warteschlangensystem erfordert ohnehin eine Art Web-Frontend, und dieses Konzept hat es ohne eine weitere Ebene von benutzerdefiniertem Code eingebaut.

Ihre Ressourcen sind vorhanden, bis Sie sie löschen. Dies bedeutet, dass Sie historische Informationen lange nach Abschluss des Prozesses und der Aufgabe anzeigen können.

Sie haben die Serviceerkennung selbst für eine Aufgabe mit mehreren Schritten ohne besonders komplizierte Protokolle integriert.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Ihre Serviceerkennung ist ein HTML-Formular - ein universelles und für Menschen lesbares Format.

Der gesamte Fluss kann programmgesteuert oder von einem Menschen unter Verwendung allgemein anerkannter Werkzeuge verwendet werden. Es ist kundenorientiert und daher RESTful. Jedes für das Web erstellte Tool kann Ihre Geschäftsprozesse steuern. Sie haben immer noch alternative Nachrichtenkanäle, indem Sie asynchron auf ein separates Array von Protokollservern POSTEN.

Nachdem Sie eine Weile darüber nachgedacht haben, lehnen Sie sich zurück und stellen fest, dass REST möglicherweise keine Messaging-Warteschlange und keinen ESB mehr benötigt.

http://www.infoq.com/presentations/BPM-with-REST

Tempire
quelle
11
@ Tempire was ist mit Fehlertoleranz und so weiter? REST ist nett, aber der Entwickler baut am Ende selbst Middleware
Dan Rosenstark
10
@Yar Die meisten Fragen zu "Was ist damit?" Können erneut gestellt werden: "Wie wird im Web damit umgegangen?". Die Fehlertoleranz kann über Load Balancer oder sogar die Manipulation von DNS-Datensätzen behandelt werden. Es gibt noch ein paar weitere Probleme zu lösen, wie die horizontale Skalierbarkeit - das Web kann von Natur aus nicht so gut damit umgehen (z. B. DDOS-Angriffe).
Tempire
8
@tempire, es gibt keine garantierte Lieferung im Web, oder? Ich drücke auf "Senden" und bete, dass die Nachricht ihr Ziel erreicht. Mit einem MQ weiß ich, dass ich fertig bin, wenn ich zum MQ komme. Es wird behandelt, um die Nachricht an das Ziel zu bringen.
Dan Rosenstark
10
@Yar überlegen Sie jedoch, was "garantierte Lieferung" bedeutet. Es ist nur so "garantiert" wie die Verfügbarkeit der Nachrichtenwarteschlange. Ersetzen Sie die Nachrichtenwarteschlange durch einen oder mehrere REST-Server, die Aufgaben und Prozesse als Ressourcen behandeln, und Sie haben die gleiche "Garantie" wie alles andere. Im Wesentlichen haben Sie immer noch eine Nachrichtenwarteschlange, jedoch in einem Format, auf das über den Webstandard zugegriffen werden kann und das mit jedem Web-Tool überwacht werden kann.
Tempire
16
@Yar - Ich glaube nicht, dass viele Leute die Problemdefinition verstehen, die MQ zu lösen versucht, um solche Dinge überhaupt in Betracht zu ziehen. Sie verstehen den MQ, aber das unterscheidet sich vom Verständnis des Problemraums. Es ist jedoch ein weit verbreitetes Problem, da ich denke, dass die meisten Programmierer und Manager auf der Welt darin geschult wurden, Teile zu verbinden, anstatt Lösungen zu entwickeln.
Tempire
32

Nachrichtenwarteschlangen sind ideal für Anforderungen, deren Verarbeitung lange dauern kann. Anforderungen werden in die Warteschlange gestellt und können offline verarbeitet werden, ohne den Client zu blockieren. Wenn der Client über den Abschluss informiert werden muss, können Sie dem Client die Möglichkeit geben, den Status der Anforderung regelmäßig zu überprüfen.

Mit Nachrichtenwarteschlangen können Sie auch im Laufe der Zeit besser skalieren. Es verbessert Ihre Fähigkeit, Bursts mit hoher Aktivität zu verarbeiten, da die eigentliche Verarbeitung über die Zeit verteilt werden kann.

Beachten Sie, dass Nachrichtenwarteschlangen und Webdienste orthogonale Konzepte sind, dh sich nicht gegenseitig ausschließen. Sie können beispielsweise einen XML-basierten Webdienst verwenden, der als Schnittstelle zu einer Nachrichtenwarteschlange fungiert. Ich denke, der Unterschied, den Sie suchen, ist Nachrichtenwarteschlangen gegenüber Anfrage / Antwort. Letzteres ist, wenn die Anfrage synchron verarbeitet wird.

DSO
quelle
3
Ja, ich habe nur darüber nachgedacht: Es ist nicht so, ob sie blockieren oder nicht blockieren. Es ist wichtig, ob sie längere und / oder unvorhersehbare Bearbeitungszeiten benötigen ... Da sie orthogonal sind, können Webdienste auch für lange Anfragen verwendet werden (natürlich getrennte Abgabe und Abholung). Wenn Sie jedoch den Luxus einer Nachrichtenwarteschlange haben, könnte dies eine gute Idee sein.
Dan Rosenstark
Meine neue Frage lautet: Was ist, wenn der Prozess synchron, aber bei Zeitüberschreitung asynchron sein soll? Dann passen Webdienste vielleicht besser.
Dan Rosenstark
27

Nachrichtenwarteschlangen sind asynchron und können mehrere Male wiederholt werden, wenn die Zustellung fehlschlägt. Verwenden Sie eine Nachrichtenwarteschlange, wenn der Anforderer nicht auf eine Antwort warten muss.

Der Ausdruck "Webdienste" lässt mich an synchrone Aufrufe einer verteilten Komponente über HTTP denken. Verwenden Sie Webdienste, wenn der Anforderer eine Antwort benötigt.

Duffymo
quelle
1
Danke dafür, ja "garantierte Lieferung", ich muss darüber nachdenken, ob das wichtig ist. Ich meine, Sync vs. Async ist in gewissem Sinne eine Art Geschmackssache. Während es eindeutig schwarz-weiße Hüllen gibt, gibt es auch eine riesige graue Mitte.
Dan Rosenstark
22

Ich denke, im Allgemeinen möchten Sie einen Webdienst für eine Blockierungsaufgabe (diese Aufgaben müssen abgeschlossen sein, bevor wir mehr Code ausführen) und eine Nachrichtenwarteschlange für eine nicht blockierende Aufgabe (kann eine Weile dauern, aber wir tun es nicht muss nicht darauf warten).

Tobias Cohen
quelle
Webdienste bieten auch Einwegmethoden ( @Oneway ). Um die Antwort zu erhalten, muss der Kunde einen Webdienst anbieten.
Koppor