Akka ou Réacteur

Question

Je suis dans le processus de démarrage d'un nouveau projet (java). J'ai besoin de le construire comme un système modulaire, la distribution et la résilience de l'architecture.

Donc je voudrais avoir les processus d'affaires pour communiquer entre eux, être interopérables, mais aussi indépendante.

Je suis à la recherche dès maintenant à deux cadres, en plus de leur différence d'âge, express 2 points de vue différents:

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

Ce que je dois considérer lors du choix d'un de ces cadres?

Autant que je sache, jusqu'à présent, Akka est toujours en quelque sorte couplé (d'une manière que je dois choisir l'acteur je veux envoyer les messages), mais très résistant. Alors que le Réacteur est en vrac (comme c'est basé sur la publication d'événement).

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

Mise à JOUR

Après examen de mieux l' Événement de Bus de Akka, je crois, d'une certaine façon les caractéristiques exprimées par les Réacteurs sont déjà inclus dans Akka.

Par exemple, l'abonnement et de l'événement de l'édition, documenté sur https://github.com/reactor/reactor#events-selectors-and-consumerspeuvent être exprimées à 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 les suivants:

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

Est mon interprétation correcte? Mais qu'est-ce que le plan conceptuel de la différence entre l'Acteur dans Akka et le Consommateur dans le Réacteur?

Answer 1

Il est difficile de dire à ce stade parce que le Réacteur est encore qu'une esquisse et j' (Akka technologie plomb) n'ont pas de savoir où il va aller. Il sera intéressant de voir si le Réacteur devient un concurrent à Akka, nous sommes à la recherche de l'avant.

Aussi loin que je peux voir, à partir de votre liste d'exigences Réacteur est manquant résilience (c'est à dire que la supervision permet d'Akka) et de l'emplacement de la transparence (c'est à dire en se référant à des entités actives dans un mode qui vous permet de résumé sur le local ou à distance de la messagerie; qui est ce que tu le sous-entends par "distribution"). Pour "modulaire" je ne sais pas assez sur le Réacteur, en particulier la façon dont vous pouvez rechercher des composants actifs et de les gérer.

Si vous commencez un réel projet et besoin de quelque chose qui répond à ta première phrase, je ne pense pas qu'il serait controversée de recommander Akka à ce point (comme Jon a également noté). N'hésitez pas à poser plus de questions concrètes sur ou sur la akka-user mailing liste.

Answer 2

Le réacteur n'est pas lié à Ressort, de ses un module optionnel. Nous voulons Réacteur pour être portable, une fondation comme Jon décrites.

Je ne vais pas avoir confiance en les poussant dans la production que nous ne sommes même pas Jalon (1.0.0.INSTANTANÉ), à cet égard, je voudrais avoir un regard plus profond à Akka , qui est un fantastique asynchrone cadre de l'OMI. Également envisager de Vert.x et Récupérer ce qui pourrait être adaptée si vous regardez pour une plate-forme (l'ancien) ou pour composable à terme (le dernier). Si vous regardez après une vaste gamme de modèles asynchrones, peut-être GPars sera de vous fournir une solution plus complète.

En fin de compte, on pourrait certainement avoir des chevauchements, en fait, nous sommes en se penchant vers une approche mixte (flexible composable concours complet, distribué, et n'est lié à aucune expédition de stratégie) d'où vous pouvez facilement trouver des bits à partir de RxJava, Vert.x, Akka etc. Nous ne sommes même pas des opinions tranchées par le choix de la langue, même si nous sommes fermement engagés à Groovy, les gens ont déjà commencé à Clojure et Kotlin ports. Ajouter à ce mélange le fait que certains besoins sont dictés par le Printemps XD et le Graal.

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

Answer 3

C'est une excellente question et la réponse va changer dans les semaines à venir. Nous ne pouvons pas faire de promesses de ce que la communication inter-nœud ressemblera à droite maintenant, juste parce qu'il est trop tôt. Il nous reste encore quelques pièces à assembler, avant que nous puissions démontrer clustering dans le Réacteur.

Avec cela dit, juste parce que le Réacteur n'est pas de faire de l'inter-nœud comms OOTB ne signifie pas qu'il ne peut pas. :) On aurait seulement besoin d'un assez mince couche réseau afin de coordonner entre les Réacteurs utilisant quelque chose comme Redis ou AMQP pour donner du cluster smarts.

Nous sommes certainement en train de parler et de planification pour la distribution de scénarios dans le Réacteur. C'est juste trop tôt pour dire exactement comment ça va fonctionner.

Si vous avez besoin de quelque chose qui ne clustering dès maintenant, vous serez plus sûr de choisir Akka.