Akka lub Reactor [zamknięte]

94

Jestem w trakcie rozpoczynania nowego projektu (opartego na Javie). Muszę go zbudować jako architekturę modułową, rozproszoną i odporną.

Dlatego chciałbym, aby procesy biznesowe komunikowały się między sobą, były interoperacyjne, ale także niezależne.

Patrzę teraz na dwa frameworki, które oprócz różnicy wieku wyrażają 2 różne poglądy:

Co powinienem wziąć pod uwagę przy wyborze jednego z powyższych frameworków?

O ile do tej pory rozumiem, Akka jest nadal w jakiś sposób sprzężona (w taki sposób, że muszę „wybrać” aktora, do którego chcę wysłać wiadomości), ale bardzo odporna. Gdy Reactor jest luźny (na podstawie publikowania zdarzeń).

Czy ktoś może mi pomóc zrozumieć, jak podjąć właściwą decyzję?

AKTUALIZACJA

Po dokładniejszym przejrzeniu Event Bus of Akka uważam, że w pewien sposób funkcje wyrażone przez Reactor są już zawarte w Akce.

Na przykład subskrypcja i publikowanie wydarzeń, udokumentowane na https://github.com/reactor/reactor#events-selectors-and-consumers , można wyrazić w akce w następujący sposób:

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");

Dlatego teraz wydaje mi się, że główne różnice między nimi to:

  • Akka, bardziej dojrzały, związany z Typesafe
  • Reaktor, wczesny etap, związany ze wiosną

Czy moja interpretacja jest prawidłowa? Ale jaka jest koncepcyjna różnica między aktorem w Akce a konsumentem w reaktorze ?

David Riccitelli
źródło
8
Akka nie musi być używana przez Scalę, w rzeczywistości większość korzysta z niej w Javie.
Viktor Klang
1
David: Coś w stylu: Akka EventBus API na koncercie z Akka Actors implementuje wzorzec Reaktora
Viktor Klang
9
Dla wyjaśnienia: Reactor w ogóle nie jest związany ze Springiem. Celowo unikamy wszelkich zależności Springa, ponieważ jako fundamentalny framework nie ma sensu ograniczać jego użycia tylko do użytkowników Springa. Jeśli chodzi o różnicę między aktorem a konsumentem: jeśli chodzi o firmę Reactor, Twój Konsument może być stanowy lub nie. Zakłada się, że będziesz chciał użyć anonimowej klasy bezstanowej lub lambda Java 8, ale nie jest to wymagane. I jak wspomniałem w mojej odpowiedzi, zestaw narzędzi Reactor jest celowo zwięzły we wczesnych iteracjach. Nie próbujemy tworzyć „następnej Akki”.
Jon Brisbin
8
Upuszczam tylko wzmiankę o vertx.io, ponieważ uważam, że jest to w tej samej dziedzinie napędzanej wydarzeniami, z kilkoma interesującymi koncepcjami w podobnym duchu dla tych, którzy
badają
1
Przechodząc przez kilka lat, jestem również w podobnej sytuacji, moja aplikacja jest głównie oparta na sprężynach i teraz potrzebuję obsługi funkcji sterowanej zdarzeniami. Czy istnieje wyraźny zwycięzca b / w Akka i Spring-reactor? Szukam frameworka z aktywnymi komunikatami użytkowników na wypadek, gdybym dotarł do bardziej skomplikowanych scenariuszy.
tintin

Odpowiedzi:

47

W tym momencie trudno powiedzieć, ponieważ Reactor to nadal szkic, a ja (kierownik ds. Technologii Akka) nie mam wglądu w to, dokąd to pójdzie. Ciekawie będzie zobaczyć, czy Reactor stanie się konkurentem Akki, nie możemy się tego doczekać.

O ile widzę, na liście Twoich wymagań Reactor brakuje odporności (tj. Tego, co daje nadzór w Akka) i przejrzystości lokalizacji (tj. Odwoływania się do aktywnych podmiotów w sposób, który pozwala abstrahować od lokalnych lub zdalnych wiadomości; implikować przez „dystrybuowane”). W przypadku „modularnych” nie wiem wystarczająco dużo o Reaktorze, w szczególności o tym, jak można wyszukiwać aktywne komponenty i zarządzać nimi.

Jeśli zaczynasz prawdziwy projekt teraz i potrzebujesz czegoś, co odpowiada Twojemu pierwszemu zdaniu, to nie sądzę, by było kontrowersyjne polecanie Akki w tym momencie (jak zauważył też Jon). Zapraszam do zadawania bardziej konkretnych pytań na temat SO lub na liście mailingowej akka-user .

Roland Kuhn
źródło
Dzięki Roland, uwielbiam widzieć, że ludzie z obu projektów przyczyniają się do odpowiedzi. Obecnie próbuję Akka. Jak się spodziewałeś, udzielenie ostatecznej odpowiedzi na to pytanie jest dość przedwczesne, z wyjątkiem tego, że reaktor jest wciąż na wczesnym etapie, dlatego nie nadaje się jeszcze do porównania. Poczekajmy więc i zobaczmy, jak wszystko się rozwinie :-) Dzięki, David
David Riccitelli
7
Dzięki za odpowiedź, Roland. Chciałem tylko wyjaśnić, że Reactor nie jest konkurentem Akka. Istnieją podobieństwa ze względu na nakładający się obszar obaw dotyczących aplikacji asynchronicznych. Ale Reactor ma być fundamentem, na którym można budować inne systemy. Te inne systemy mogą pokrywać się nawet bardziej z Akką niż sam Reactor. Jednak w dającej się przewidzieć przyszłości Reactor pozostanie platformą umożliwiającą korzystanie z innych systemów i nie będzie sama w sobie pełnowartościową platformą. Będziesz musiał opóźnić gratyfikację w strzelaninie Reactor / Akka. ;)
Jon Brisbin
Nie martw się, myślę, że poradzisz sobie dobrze i jestem pewien, że zobaczymy zapylenie krzyżowe, gdy więcej bibliotek wejdzie w to pole.
Roland Kuhn
37

Reactor nie jest powiązany ze Springem, jest to opcjonalny moduł. Chcemy, aby Reactor był przenośny, podstawa, jak nakreślił Jon.

Nie będę pewny co do pchania w produkcji, ponieważ nie jesteśmy nawet Milestone (1.0.0.SNAPSHOT), w związku z tym przyjrzałbym się bliżej Akce, która jest fantastycznym asynchronicznym frameworkiem IMO. Również rozważyć Vert.x i finagle które mogą być dostosowane, jeśli spojrzeć zarówno na platformie (były) lub composable futures (te ostatnie). Jeśli dbasz o szeroką gamę wzorców asynchronicznych, być może GPars zapewni ci bardziej kompletne rozwiązanie.

Ostatecznie możemy z pewnością nakładać się na siebie, w rzeczywistości skłaniamy się ku podejściu mieszanemu (elastyczne komponowanie zdarzeń, rozproszone i niezwiązane z żadną strategią wysyłania), w którym można łatwo znaleźć bity z RxJava , Vert.x , Akka itp. Nie jesteśmy nawet przekonani do wyboru języka, nawet jeśli jesteśmy mocno zaangażowani w Groovy, ludzie już uruchomili porty Clojure i Kotlin . Dodajmy do tego fakt, że niektóre wymagania są napędzane przez Spring XD i Grails .

Wielkie dzięki za zainteresowanie, miejmy nadzieję, że za kilka miesięcy będziesz mieć więcej punktów porównawczych :)

Stephane Maldini
źródło
Dzięki Stephane, wierzę, że twoja odpowiedź (i komentarz Jona, stackoverflow.com/questions/16595393/akka-or-reactor/… ) dają dużo jaśniejszą perspektywę. Jeszcze poczekam, zanim oznaczysz pytanie jako odpowiedź, tak jak powiedziałeś, zobaczmy, co wyskoczy w najbliższej przyszłości. Ponownie bardzo doceniam to, że ludzie zaangażowani w oba projekty spędzili czas na dostarczaniu przydatnych informacji.
David Riccitelli
Zgadzam się z Vert.x. Użyłem Vert.x w środowisku produkcyjnym w kilku projektach do komunikacji między komponentami i działa bezproblemowo.
Wygrywa
33

To doskonałe pytanie, na które odpowiedź będzie się zmieniać w nadchodzących tygodniach. Nie możemy obiecać, jak będzie teraz wyglądać komunikacja między węzłami tylko dlatego, że jest za wcześnie. Wciąż mamy kilka elementów do złożenia, zanim będziemy mogli zademonstrować grupowanie w Reaktorze.

To powiedziawszy, tylko dlatego, że Reactor nie wykonuje komunikacji między węzłami OOTB, nie oznacza, że nie może . :) Wystarczyłaby tylko dość cienka warstwa sieci, aby koordynować między reaktorami za pomocą czegoś takiego jak Redis lub AMQP, aby nadać mu kilka inteligentnych klastrów.

Zdecydowanie rozmawiamy o scenariuszach rozproszonych w Reaktorze i planujemy je. Jest za wcześnie, aby dokładnie powiedzieć, jak to będzie działać.

Jeśli potrzebujesz teraz czegoś, co działa w klastrach, będziesz bezpieczniejszy wybierając Akka.

Jon Brisbin
źródło
Dzięki Jon, uważam, że Reactor jest bardzo obiecujący. Muszę jednak zrozumieć, czy istnieje różnica pojęciowa między Reactor i Akka, poza cechami, których brakuje Reactor (oczywiście na wczesnym etapie). Podsumowując, jaka jest koncepcyjna różnica między aktorem w Akce a konsumentem w reaktorze? Zaktualizowałem również moje pytanie przykładowym wydarzeniem w Akka, które moim zdaniem przypomina subskrypcję / wysyłanie wydarzeń na stronie Reactor GitHub. Dzięki.
David Riccitelli
Jon, czytałem twoją odpowiedź tutaj: blog.springsource.org/2013/05/13/… - więc możemy założyć, że na dłuższą metę Akka i Reactor będą podobnymi frameworkami, zarówno wspierającymi wzorzec Reaktora, jak i model aktora.
David Riccitelli
Powyższy komentarz nie jest już poprawny z następujących powodów: stackoverflow.com/questions/16595393/akka-or-reactor/… i stackoverflow.com/a/16674388/565110
David Riccitelli
Nie rozumiem, dlaczego ten komentarz jest teraz niepoprawny? Nic tutaj nie stoi w sprzeczności z wyjaśnieniem strategicznego kierunku Reaktora.
Jon Brisbin
1
Mam cię. Tak, dobrze rozumiesz. Dzięki za zadanie tych pytań! :)
Jon Brisbin