Veraltet Akka JMS / AMQP-Nachrichtenbroker? [geschlossen]

Geschlossen . Diese Frage ist meinungsbasiert . Derzeit werden keine Antworten akzeptiert.

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage, damit sie mit Fakten und Zitaten beantwortet werden kann, indem Sie diesen Beitrag bearbeiten .

Geschlossen vor 4 Jahren .

Ich habe die letzte Woche damit verbracht, mich eingehend mit den Akka-Dokumenten zu befassen und endlich zu verstehen, was Darstellersysteme sind und welche Probleme sie lösen.

Mein Verständnis (und meine Erfahrung mit) traditionellen JMS / AMQP-Nachrichtenbrokern ist, dass sie Folgendes bieten:

Asynchrone Verarbeitung zwischen Erzeuger und Verbraucher; und
Garantie für die Zustellung von Nachrichten, einschließlich Persistenz, Wiederholungsversuchen und Ausweichversuchen

Aber bietet Akka dies nicht ohne die gesamte erforderliche Infrastruktur und den operativen Aufwand?

In Akka ist die gesamte Kommunikation der Akteure asynchron und nicht blockierend. und
Bestehen Sie in Akka, SupervisorStrategiesum einen erneuten Versuch, ein Zurückgreifen und eine Eskalation durchzuführen. Akteure können so konfiguriert werden, dass sie für praktisch jede Art von Geschäft bestehen bleiben , wenn dies ebenfalls erforderlich ist.

Ich frage mich also: Wenn meine App Akka verwendet, muss ich jemals JMS / AMQP-Broker (z. B. ActiveMQ, RabbitMQ, Kafka) ins Bild setzen? Mit anderen Worten, gibt es jemals einen Anwendungsfall, bei dem eine neue Akka-basierte App auch die Einführung eines neuen JMS / AMQP-Broker-Clusters rechtfertigen würde ? Warum oder warum nicht?

Das einzige Argument wäre, dass sich meine Akka-App vielleicht in ein anderes System integrieren muss. Aber in diesem Fall ermöglicht das Akka-Camel- Modul Akka, auf die umfassende, fast unendliche Liste der Integrationsmöglichkeiten von Camel zuzugreifen (TCP, FTP, ZeroMQ, die Liste geht weiter und weiter ...).

Gedanken?

— smeeb
quelle

Ist Ihr letzter Absatz nicht ein Grund, warum Akka Nachrichtenvermittler nicht überflüssig macht? Zum Beispiel arbeite ich an einer Java-Anwendung, die über einen JMS-kompatiblen Nachrichtenbroker mit Remote-C ++ - Anwendungen interagiert. Ich könnte meine Java-Anwendung mit Akka-Camel schreiben, aber ich würde den Broker wegen der C ++ - Anwendung immer noch brauchen.

— Thomas Owens

Ahhh danke @ThomasOwens (+1) aber du hast meine Frage (zu Recht) falsch verstanden. Ich werde den Wortlaut in ein paar Minuten ändern, damit er offensichtlicher wird. Was ich wirklich fragen , ist: Wenn ich eine Akka app bin Gebäude, würde ich jemals brauchen werden, um auch eine Einführung neuer JMS / AMQP - Broker? Ich denke, die Antwort ist "nein", weil Akka + Camel (wieder denke ich ) alle Probleme löst, die typischerweise von einem Broker gelöst werden. In Ihrem Beispiel ist der JMS-Broker bereits vorhanden , um mit der C ++ - App zu kommunizieren. Ich füge es nicht zusammen mit meiner neuen Akka-App hinzu. Und so kümmert sich das Akka-Camel-Modul für mich um die Nachrichtenübermittlung.

— Smeeb

Vielleicht habe ich ein Missverständnis, aber Camel ersetzt JMS nicht (zum Beispiel), sondern bietet eine Schnittstelle, über die Nachrichten über JMS gesendet werden können. Sie können JMS durch AMQP, RabbitMQ oder XMPP ersetzen. In meinem Beispiel müsste ich, selbst wenn meine Java + Akka- und C ++ - Anwendungen brandneu wären, eine Art JMS-kompatibler Nachrichtenwarteschlange einrichten, für die ich Akka-Camel verwenden könnte, damit sie über JMS kommunizieren können mit ihm kommunizieren. Camel bietet keinen Broker an, sondern nur die Möglichkeit, innerhalb einer Reihe von Protokollen zu kommunizieren. Akka-Camel bietet eine vertrautere Benutzeroberfläche als die Benutzeroberfläche von Camel.

— Thomas Owens

Nochmals vielen Dank @ThomasOwens (+1) - Ich denke, Sie überdenken dies nur :-). In Ihrem Beispiel gibt es eine vorhandene C ++ - App - möglicherweise ein älteres System - und einen vorhandenen JMS-kompatiblen Broker , den die C ++ - App bereits für die Integration mit der Außenwelt verwendet. In diesem Fall würde meine neue Akka-App - wie Sie bereits sagten - das Akka-Camel-Modul verwenden, um Nachrichten an diesen Broker zu erstellen bzw. von diesem zu lesen. Aber das ist nicht was ich hier frage! Ich frage mich , ob es überhaupt ein Grund ist , dass ich bauen müsste 2 Dinge : (1) meine neue Akka app, und (2) ein JMS / AMQP - Broker, die gleichzeitig ...

— smeeb

Sie erwähnen die unendlichen Integrationsmöglichkeiten von Camel, die sich jedoch nicht in Nothing integrieren lassen. Es muss etwas vorhanden sein, in das es integriert werden kann, andernfalls wird nur eine Reihe von Diensten unterstützt, die Sie nicht ausführen. Starten Sie JMS oder einen HTTP- oder FTP-Server oder etwas anderes, wenn Sie Camel für die Integration in etwas verwenden möchten. Ansonsten ist es einfach wunderbar, unendliche Integrationsmöglichkeiten zu bieten und gleichzeitig mit nichts zu integrieren.

— Jimmy Hoffa

Schauspielermodell

Das Akteurmodell ist eine Informatikstrategie zum Erstellen von Anwendungen, die eine Vielzahl von gleichzeitigen Berechnungen und zustandsbehafteten Verarbeitungen ausführen. Es ist nicht die einzige Strategie, aber es ist ein sehr gut getesteter, einfacher und zuverlässiger Ansatz, der die Berechnung in Akteure überführt , die über Nachrichten kommunizieren, die sie einzeln und in Reihenfolge verarbeiten.

Akka ist ein Framework, das das Darstellermodell implementiert und es Ihnen ermöglicht, Darstellersysteme mit der gesamten Infrastruktur und den bereits erstellten Funktionen zu erstellen (z. B. mit JQuery anstelle von Javascript).

Messaging

Nachrichtensysteme sind Anwendungen, die Nachrichten senden und abrufen können. Es gibt viele Varianten von einfachen Warteschlangen bis zu Software für große Unternehmen mit Themen, Pub / Sub, Persistenz und anderen Funktionen, aber das Endziel ist dasselbe. Speichern Sie einige Bytes irgendwo und rufen Sie sie später mit einer Art Bestellung wieder ab. Der primäre Anwendungsfall besteht heute darin, Systeme zu entkoppeln und eine asynchrone Verarbeitung mit unterschiedlichen Zeitplänen oder Geschwindigkeiten zu ermöglichen. RabbitMQ, NATS, Kafka usw. sind Beispiele für Nachrichtensysteme.

Vergleich

Das Actor-Modell und das Akka-Framework sind einfache Tools, mit denen sich Anwendungen wie Nachrichtenwarteschlangen hervorragend erstellen lassen .

Können Sie Akka anstelle einer Nachrichtenwarteschlange verwenden? Sicher. Wenn Sie eine Software erstellen, die bereits das Darstellermodell verwendet, benötigen Sie wahrscheinlich keine externe Nachrichtenwarteschlange, insbesondere zum Senden von Nachrichten innerhalb desselben Threads oder derselben Anwendung. Mit den Funktionen von Akka Remoting können Sie sogar Nachrichten an andere Darstellersysteme senden, die auf anderen Computern ausgeführt werden.

Macht dies Messaging-Systeme jedoch überflüssig? Absolut nicht. Nur weil Sie all diese Dinge selbst codieren können, bedeutet dies nicht, dass Sie dies tun müssen, insbesondere wenn ein Darstellermodell für Ihr Problem nicht geeignet ist oder Sie verschiedene Sprachen, Anwendungen, externe APIs, Betriebssysteme, Datenbanken usw. für die Kommunikation benötigen miteinander (ob es sich um Akteurensysteme handelt oder nicht).

Wenn Sie nur einige Nachrichten zwischen zwei Systemen übertragen müssen, verwenden Sie eine Nachrichtenwarteschlange. Wenn Sie eine skalierbare statusabhängige Verarbeitung und Nachrichten mit geringer Latenz in derselben Anwendung benötigen, verwenden Sie das Akteurmodell. Beide existieren auf völlig unterschiedlichen Ebenen und wie Sie sie verwenden, hängt von der Lösung ab, die Sie erstellen.

Es gibt eine großartige Antwort auf SO zu diesem Akteurmodell im Vergleich zu Messaging: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- oder-tibco

— Mani Gandham
quelle