Akka ou Reactor [fermé]

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

Je souhaite donc que les processus métier communiquent entre eux, soient interopérables, mais aussi indépendants.

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

• Akka ( http://akka.io )
• Réacteur ( https://github.com/reactor/reactor )

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

Pour autant que je sache jusqu'à présent, Akka est toujours en quelque sorte couplé (d'une manière que je dois «choisir» l'acteur auquel je veux envoyer les messages), mais très résilient. Alors que Reactor est lâche (comme cela est basé sur la publication d'événements).

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

METTRE À JOUR

Après avoir mieux examiné le bus d'événements d'Akka, je crois d'une certaine manière que les fonctionnalités exprimées par Reactor sont déjà incluses dans Akka.

Par exemple, l'abonnement et la publication d'événements, documentés sur https://github.com/reactor/reactor#events-selectors-and-consumers , peuvent être exprimés en 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");

Par conséquent, il me semble maintenant que les principales différences entre les deux sont:

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

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

C'est difficile à dire à ce stade, car Reactor est toujours un croquis et je (responsable technique d'Akka) ne sais pas où il ira. Il sera intéressant de voir si Reactor devient un concurrent d'Akka, nous attendons cela avec impatience.

Autant que je puisse voir, dans votre liste d'exigences, Reactor manque de résilience (c'est-à-dire ce que la supervision vous donne dans Akka) et de transparence de localisation (c'est-à-dire se référant à des entités actives d'une manière qui vous permet d'abstraction sur la messagerie locale ou distante; c'est ce que vous impliquer par «distribué»). Pour «modulaire», je ne connais pas assez Reactor, en particulier comment rechercher des composants actifs et les gérer.

Si vous démarrez un vrai projet maintenant et avez besoin de quelque chose qui satisfait 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 .

Reactor n'est pas lié à Spring, c'est un module optionnel. Nous voulons que Reactor soit portable, une base comme Jon l'a souligné.

Je ne serai pas sûr de pousser la production car nous ne sommes même pas Milestone (1.0.0.SNAPSHOT), à cet égard, j'aurais un regard plus approfondi sur Akka qui est un fantastique cadre asynchrone IMO. Pensez également à Vert.x et Finagle qui pourraient être adaptés si vous recherchez une plateforme (la première) ou des futurs composables (la dernière). Si vous vous occupez d' un large éventail de modèles asynchrones, peut-être que GPars vous fournira une solution plus complète.

En fin de compte, nous pourrions certainement avoir des chevauchements, en fait nous nous orientons vers une approche mixte (eventing composable flexible, distribué et non lié à une stratégie de distribution) où vous pouvez facilement trouver des bits de RxJava , Vert.x , Akka, etc. Nous ne sommes même pas avisés par le choix de la langue, même si nous sommes fermement attachés à Groovy, les gens ont déjà lancé les ports de Clojure et Kotlin . Ajoutez à cela le fait que certaines exigences sont dictées par Spring XD et Grails .

Merci beaucoup pour votre intérêt, j'espère que vous aurez plus de points de comparaison dans quelques mois :)

C'est une excellente question et la réponse changera au cours des semaines à venir. Nous ne pouvons faire aucune promesse sur ce à quoi ressemblera la communication inter-nœuds en ce moment simplement parce qu'il est trop tôt. Nous avons encore quelques éléments à assembler avant de pouvoir démontrer le clustering dans Reactor.

Cela dit, ce n'est pas parce que Reactor ne fait pas de communications inter-nœuds OOTB qu'il ne le peut pas . :) On n'aurait besoin que d'une couche réseau assez fine pour coordonner entre les réacteurs en utilisant quelque chose comme Redis ou AMQP pour lui donner une intelligence en cluster.

Nous parlons et prévoyons définitivement des scénarios distribués dans Reactor. Il est trop tôt pour dire exactement comment cela fonctionnera.

Si vous avez besoin de quelque chose qui effectue le clustering en ce moment, vous serez plus sûr de choisir Akka.