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:
- Akka ( http://akka.io )
- Reactor ( https://github.com/reactor/reactor )
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 ?
Odpowiedzi:
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 .
źródło
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 :)
źródło
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.
źródło