Я нахожусь в процессе запуска нового проекта (на основе java). Мне нужно построить его как модульную, распределенную и отказоустойчивую архитектуру.
Поэтому я хотел бы, чтобы бизнес-процессы взаимодействовали между собой, были совместимы, но при этом независимы.
Я сейчас смотрю на две структуры, которые, помимо разницы в возрасте, выражают 2 разных взгляда:
- Акка ( http://akka.io )
- Реактор ( https://github.com/reactor/reactor )
Что мне следует учитывать при выборе одного из вышеперечисленных фреймворков?
Насколько я понимаю до сих пор, Akka все еще каким-то образом связан (таким образом, что я должен «выбирать» актера, которому я хочу отправить сообщения), но очень устойчив. Пока Reactor свободен (судя по публикации событий).
Может ли кто-нибудь помочь мне понять, как принять правильное решение?
ОБНОВИТЬ
После более тщательного изучения шины событий Akka, я считаю, что в некотором смысле функции, реализованные в Reactor , уже включены в Akka.
Например, подписка и публикация событий, задокументированные на https://github.com/reactor/reactor#events-selectors-and-consumers , могут быть выражены в Akka следующим образом:
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");
Поэтому сейчас мне кажется, что основные различия между ними следующие:
- Акка, более зрелый, привязанный к Typesafe
- Реактор, ранний этап, привязан к весне
Моя интерпретация верна? Но в чем концептуально разница между Актером в Akka и Потребителем в Reactor ?
Ответы:
На данный момент трудно сказать, потому что Reactor все еще является наброском, и я (технический руководитель Akka) не знаю, куда он пойдет. Будет интересно посмотреть, станет ли Reactor конкурентом Akka, мы с нетерпением ждем этого.
Насколько я понимаю, в вашем списке требований Reactor не хватает устойчивости (то есть того, что дает вам контроль в Akka) и прозрачности местоположения (то есть ссылки на активные объекты таким образом, который позволяет вам абстрагироваться от локального или удаленного обмена сообщениями; это то, что вы подразумевается под «распределенным»). Что касается «модульного», я не знаю достаточно о Reactor, в частности о том, как искать активные компоненты и управлять ими.
Если начать реальный проект сейчас и нужно что - то , которое удовлетворяет ваше первое предложение, то я не думаю , что было бы спорным рекомендовать Акка в этот момент (как Джон также отметил). Не стесняйтесь задавать более конкретные вопросы в SO или в списке рассылки akka-user .
источник
Reactor не привязан к Spring, это дополнительный модуль. Как сказал Джон, мы хотим, чтобы Reactor был портативным.
Я не буду уверен в продвижении в продакшене, поскольку мы даже не являемся Milestone (1.0.0.SNAPSHOT), в этом отношении я хотел бы более глубоко взглянуть на Akka, которая является фантастической асинхронной структурой IMO. Также рассмотрите Vert.x и Finagle, которые могут быть адаптированы, если вы ищете платформу (первое) или составные фьючерсы (второе). Если вы следите за широким спектром асинхронных шаблонов, возможно, GPars предоставит вам более полное решение.
В конце концов, у нас, безусловно, могут быть совпадения, на самом деле мы склоняемся к смешанному подходу (гибкая составная обработка событий, распределенная и не привязанная к какой-либо стратегии диспетчеризации), где вы можете легко найти биты из RxJava , Vert.x , Akka и т. Д. Мы даже не ограничены выбором языка, даже если мы твердо привержены Groovy, люди уже запустили порты Clojure и Kotlin . Добавьте к этому тот факт, что некоторые требования обусловлены Spring XD и Grails .
Большое спасибо за проявленный интерес, надеюсь, через пару месяцев у вас будет больше точек для сравнения :)
источник
Это отличный вопрос, и ответ изменится в ближайшие недели. Мы не можем давать никаких обещаний относительно того, как будет выглядеть межузловая коммуникация прямо сейчас, только потому, что еще слишком рано. Нам еще предстоит собрать некоторые части, прежде чем мы сможем продемонстрировать кластеризацию в Reactor.
С учетом сказанного, то, что Reactor не поддерживает межузловую связь OOTB, не означает, что это невозможно . :) Нужен только довольно тонкий сетевой слой для координации между Reactors, используя что-то вроде Redis или AMQP, чтобы дать ему некоторый кластерный ум.
Мы определенно говорим и планируем распределенные сценарии в Reactor. Пока еще рано говорить, как именно это будет работать.
Если вам нужно что-то, что выполняет кластеризацию прямо сейчас, вам будет безопаснее выбрать Akka.
источник