Akka obsolète-t-il les courtiers de messages JMS / AMQP? [fermé]

19

J'ai passé la semaine dernière à plonger profondément dans les documents Akka et enfin comprendre ce que sont les systèmes d'acteurs et les problèmes qu'ils résolvent.

Ma compréhension (et mon expérience avec) les courtiers de messages JMS / AMQP traditionnels est qu'ils existent pour fournir les éléments suivants:

  • Traitement asynchrone entre producteur et consommateur; et
  • Garantie de livraison des messages, y compris la persistance, les tentatives et les replis

Mais Akka ne fournit-il pas cela, sans toute l'infrastructure et les frais généraux nécessaires?

  • À Akka, toutes les communications des acteurs sont asynchrones et non bloquantes; et
  • À Akka, SupervisorStrategiesexistent pour effectuer une nouvelle tentative, un repli et une escalade. Les acteurs peuvent être configurés pour persister dans pratiquement n'importe quel type de magasin, si cela est également une exigence.

Cela me fait donc me demander: si mon application utilise Akka, ai-je un jour besoin de faire intervenir des courtiers JMS / AMQP (par exemple ActiveMQ, RabbitMQ, Kafka)? En d'autres termes, existe-t-il un cas d'utilisation où une nouvelle application basée sur Akka justifierait également l'introduction d'un nouveau cluster de courtiers JMS / AMQP? Pourquoi ou pourquoi pas?

Le seul argument serait que mon application Akka doit peut-être s'intégrer à un autre système. Mais dans ce cas, le module Akka-Camel permet à Akka de puiser dans la liste exhaustive et presque infinie de capacités d'intégration de Camel (TCP, FTP, ZeroMQ, la liste s'allonge encore et encore ...).

Pensées?

asynchronous-programming message-queue messaging akka smeeb
la source
3
Votre dernier paragraphe n'est-il pas une raison pour laquelle Akka ne rend pas les courtiers de messages obsolètes? Par exemple, je travaille sur une application Java qui interagit avec des applications C ++ distantes via un courtier de messages compatible JMS. Je pourrais écrire mon application Java en utilisant Akka-Camel, mais j'aurais toujours besoin du courtier à cause de l'application C ++.
Thomas Owens
Ahhh merci @ThomasOwens (+1) mais vous avez (à juste titre) mal compris ma question. Je vais changer le libellé dans quelques minutes pour que ce soit plus évident. Ce que je demande vraiment, c'est: si je crée une application Akka, aurais-je besoin d' introduire également un nouveau courtier JMS / AMQP? Je pense que la réponse est "non", car Akka + Camel (encore une fois je pense ) résout tous les problèmes généralement résolus par un courtier. Dans votre exemple, le courtier JMS existe déjà comme moyen de communiquer avec l'application C ++; Je ne l'ajoute pas avec ma nouvelle application Akka. Et donc le module Akka-Camel s'occupera de la messagerie pour moi.
smeeb
2
Peut-être que je me méprends, mais Camel ne remplace pas JMS (par exemple), mais il fournit une interface qui peut être utilisée pour envoyer des messages via JMS. Vous pouvez remplacer JMS par AMQP, RabbitMQ ou XMPP. Dans mon exemple, même si mes applications Java + Akka et C ++ étaient flambant neuves, pour qu'elles puissent communiquer via JMS, je devrais toujours introduire une sorte de file d'attente de messages compatible JMS et ensuite je pourrais utiliser Akka-Camel pour communiquer avec elle. Camel ne fournit pas de courtier, juste un moyen de communiquer avec un certain nombre de protocoles. Akka-Camel fournit une interface plus familière sur l'interface de Camel.
Thomas Owens
Merci encore @ThomasOwens (+1) - Je pense que vous y pensez trop :-). Dans votre exemple, il existe une application C ++ existante - peut-être un système hérité, et il existe un courtier compatible JMS existant que l'application C ++ utilise déjà pour s'intégrer au monde extérieur. Dans ce cas, ma nouvelle application Akka utiliserait - comme vous l'avez dit - le module Akka-Camel pour produire / consommer des messages vers / depuis ce courtier. Mais ce n'est pas ce que je demande ici! Je me demande s'il y a jamais une raison pour laquelle je devrais construire 2 choses : (1) ma nouvelle application Akka, et (2) un courtier JMS / AMQP, en même temps ...
smeeb
3
Vous mentionnez les capacités d'intégration infinies de Camel, mais il ne peut pas s'intégrer à Nothing. Il doit y avoir quelque chose à intégrer, sinon vous profitez simplement du support pour un tas de services que vous n'exécutez pas. Lancez JMS, ou un serveur HTTP ou FTP ou quelque chose si vous voulez utiliser Camel pour intégrer quelque chose. Sinon, il fournit simplement des capacités d'intégration infinies tout en s'intégrant à rien.
Jimmy Hoffa

Réponses:

12

Modèle d'acteur

Le modèle d'acteur est une stratégie informatique pour créer des applications qui gèrent de nombreux calculs simultanés et traitements avec état. Ce n'est pas la seule stratégie mais c'est une approche très bien testée, simple et fiable qui transfère le calcul dans les acteurs , qui communiquent à travers des messages qu'ils traitent un à la fois et dans l'ordre.

Akka est un framework qui implémente le modèle d'acteur et vous permet de construire des systèmes d'acteurs avec toutes les infrastructures et fonctionnalités déjà construites (comme utiliser JQuery au lieu de javascript).

Messagerie

Les systèmes de messagerie sont des applications qui peuvent envoyer et récupérer des messages. Il existe de nombreuses variétés, des files d'attente de base aux logiciels de grande entreprise, avec des sujets, pub / sub, persistance et autres fonctionnalités, mais l'objectif final est le même. Enregistrez quelques octets quelque part et récupérez-les plus tard, avec une sorte de commande. Aujourd'hui, le principal cas d'utilisation est de découpler les systèmes et de permettre un traitement asynchrone à différents horaires ou à différentes vitesses. RabbitMQ, NATS, Kafka, etc. sont tous des exemples de systèmes de messagerie.

Comparaison

Le modèle Actor et le cadre Akka sont des outils de bas niveau qui sont un excellent moyen de créer des applications , comme les files d'attente de messages.

Pouvez-vous utiliser Akka au lieu d'une file d'attente de messages? Sûr. Si vous créez un logiciel qui utilise déjà le modèle d'acteur, vous n'avez probablement pas besoin d'une file d'attente de messages externe, en particulier pour envoyer des messages dans le même thread ou la même application. Vous pouvez utiliser les capacités d'Akka Remoting pour même envoyer des messages à d'autres systèmes d'acteurs fonctionnant sur d'autres machines.

Cependant, cela rend-il les systèmes de messagerie obsolètes? Absolument pas. Ce n'est pas parce que vous pouvez coder tout cela vous-même que vous en avez besoin, en particulier lorsqu'un modèle d'acteur n'est pas adapté à votre problème ou que vous avez besoin de différentes langues, applications, API externes, systèmes d'exploitation, bases de données, etc. pour communiquer les uns avec les autres (qu'il s'agisse de systèmes d'acteurs ou non).

Si vous avez juste besoin de passer des messages entre deux systèmes, utilisez une file d'attente de messages. Si vous avez besoin d'un traitement évolutif avec état et d'une messagerie à faible latence dans la même application, utilisez le modèle d'acteur. Ils existent tous les deux à des niveaux complètement différents et la façon dont vous les utilisez dépend de la solution que vous construisez.

Il y a une excellente réponse sur SO à propos de ce même modèle d'acteur contre la messagerie: /programming/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq- or-tibco

Mani Gandham
la source