web-dev-qa-db-fra.com

Akka ou Réacteur

Je suis en train de démarrer un nouveau projet (basé sur Java). Je dois le construire comme une architecture modulaire, distribuée et résiliente.

Par conséquent, j'aimerais que les processus opérationnels puissent communiquer entre eux, être interopérables, mais également indépendants.

Je regarde actuellement deux cadres qui, outre leur différence d'âge, expriment deux points de vue différents:

Que dois-je considérer lors du choix de l'un des cadres ci-dessus?

Autant que je sache jusqu'à présent, Akka est toujours en quelque sorte couplé (d'une manière qui me oblige à "choisir" l'acteur auquel je souhaite envoyer les messages), mais très résistant. Alors que Reactor est lâche (comme basé sur la publication d'événement).

Quelqu'un peut-il m'aider à comprendre comment prendre une bonne décision?

[~ # ~] met à jour [~ # ~]

Après avoir mieux examiné le Event Bus de Akka, je crois que, d'une certaine manière, les fonctionnalités exprimées par Reactor sont déjà inclus dans Akka.

Par exemple, la publication d'abonnements et d'événements, documentée sur https://github.com/reactor/reactor#events-selectors-and-consumers , peut être exprimée dans Akka comme suit:

final ActorSystem system = ActorSystem.create("system");
final ActorRef actor = system.actorOf(new Props(
    new UntypedActorFactory() {

        @Override
        public Actor create() throws Exception {

            return new UntypedActor() {
                final LoggingAdapter log = Logging.getLogger(
                        getContext().system(), this);

                @Override
                public void onReceive(Object message)
                        throws Exception {
                    if (message instanceof String)
                        log.info("Received String message: {}",
                                message);
                    else
                        unhandled(message);
                }
            };
        }
    }), "actor");

system.eventStream().subscribe(actor, String.class);
system.eventStream().publish("testing 1 2 3");

Il me semble donc que les principales différences entre les deux sont les suivantes:

  • Akka, plus mature, lié à Typesafe
  • Réacteur précoce, lié au printemps

Mon interprétation est-elle correcte? Mais quelle est la différence conceptuelle entre l’acteur de Akka et le consommateur de Reactor ?

javaspringakkareactorproject-reactor
87
David Riccitelli

Il est difficile de dire à ce stade, car Reactor n’est encore qu’une esquisse et je (le responsable technique d’Akka) n’ai pas la moindre idée de l’avenir. Il sera intéressant de voir si Reactor devient un concurrent d’Akka, nous l’attendons avec impatience.

Autant que je sache, Reactor manque de résilience (c'est-à-dire de ce que la supervision vous donne dans Akka) et de transparence d'emplacement (c'est-à-dire qu'il fait référence aux entités actives de manière à vous permettre d'abréger la messagerie locale ou distante. impliquer par "distribué"). Pour "modulaire", je ne connais pas suffisamment Reactor, en particulier pour savoir comment rechercher et gérer les composants actifs.

Si vous démarrez un vrai projet maintenant et avez besoin de quelque chose qui satisfasse votre première phrase, alors je ne pense pas qu’il serait controversé de recommander Akka à ce stade (comme Jon l’a également noté). N'hésitez pas à poser des questions plus concrètes sur SO ou sur la liste de diffusion akka-user) .

45
Roland Kuhn

Reactor n'est pas lié à Spring, c'est un module optionnel. Nous voulons que Reactor soit portable, une fondation telle que décrite par Jon.

Je ne serai pas confiant en ce qui concerne la production, car nous ne sommes même pas Milestone (1.0.0.SNAPSHOT). À cet égard, j'examinerais de plus près Akka qui est un fantastique cadre asynchrone IMO. Considérez également Vert.x et Finagle qui pourraient être adaptés si vous regardez soit pour une plate-forme (la première), soit pour des contrats à terme composables (la dernière). Si vous prenez en charge une large gamme de modèles asynchrones, peut-être que GPars vous fourniront une solution plus complète.

À la fin, nous pourrions certainement avoir des chevauchements, en fait, nous nous orientons vers une approche mixte (événements composables flexibles, distribuée et non liée à une stratégie de dispatching) dans laquelle vous pouvez facilement trouver des extraits RxJava , Vert.x , Akka etc. Nous n'avons même pas d'opinion sur le choix de langue, même si nous sommes fortement attachés à Groovy, les gens ont déjà commencé Clojure et Kotlin ports. Ajoutez à cela que certaines exigences sont dictées par Spring XD et Grails .

Merci beaucoup pour votre intérêt vu, espérons que vous aurez plus de points de comparaison dans quelques mois :)

36
Stephane Maldini

C'est une excellente question et la réponse changera dans les semaines à venir. Nous ne pouvons faire aucune promesse quant à l'apparence actuelle de la communication inter-nœud, simplement parce que c'est trop tôt. Nous avons encore quelques pièces à assembler avant de pouvoir démontrer la mise en cluster dans Reactor.

Cela dit, ce n'est pas parce que Reactor ne fait pas de communications inter-noeuds que OOTB ne signifie pas ne peut pas. :)). couche réseau pour coordonner les réacteurs en utilisant quelque chose comme Redis ou AMQP pour lui donner des connaissances en cluster.

Il est clair que nous parlons de planification de scénarios distribués dans Reactor. Il est trop tôt pour dire exactement comment cela va fonctionner.

Si vous avez besoin de quelque chose qui fonctionne en cluster en ce moment, vous serez plus en sécurité en choisissant Akka.

31
Jon Brisbin