Akka или Reactor [закрыто]

94

Я нахожусь в процессе запуска нового проекта (на основе java). Мне нужно построить его как модульную, распределенную и отказоустойчивую архитектуру.

Поэтому я хотел бы, чтобы бизнес-процессы взаимодействовали между собой, были совместимы, но при этом независимы.

Я сейчас смотрю на две структуры, которые, помимо разницы в возрасте, выражают 2 разных взгляда:

Что мне следует учитывать при выборе одного из вышеперечисленных фреймворков?

Насколько я понимаю до сих пор, 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 ?

Дэвид Риччителли
источник
8
Akka не обязательно должна использоваться Scala, на самом деле большинство использует ее из Java.
Виктор Кланг
1
Дэвид: Что-то вроде: API Akka EventBus совместно с Akka Actors реализуют шаблон Reactor
Виктор Кланг
9
Просто чтобы уточнить: Reactor вообще не привязан к Spring. Мы намеренно не допускаем никаких зависимостей Spring, потому что в качестве базового фреймворка нет смысла ограничивать его использование только пользователями Spring. Что касается разницы между Актером и Потребителем: что касается Reactor, ваш Потребитель может иметь состояние или нет. Предполагается, что вы захотите использовать анонимный класс без сохранения состояния или лямбду Java 8, но это не является обязательным требованием. И, как я уже упоминал в своем ответе, набор инструментов Reactor для ранних итераций намеренно лаконичен. Мы не пытаемся создать «следующий Акка».
Джон Брисбин
8
Просто сбросив упоминание vertx.io , как я считаю , что это будет в том же событии ведомого поле с некоторыми интересными концепциями в том же духе для тех , кто исследующих ..
Opentuned
1
Спустя пару лет я также оказался в аналогичной ситуации. Мое приложение в основном основано на Spring, и теперь мне нужно обрабатывать функцию, управляемую событиями. Есть явный победитель ч / б Акка и Спринг-реактор? Я ищу фреймворк с активными сообществами пользователей на случай, если я дойду до более сложных сценариев.
tintin

Ответы:

47

На данный момент трудно сказать, потому что Reactor все еще является наброском, и я (технический руководитель Akka) не знаю, куда он пойдет. Будет интересно посмотреть, станет ли Reactor конкурентом Akka, мы с нетерпением ждем этого.

Насколько я понимаю, в вашем списке требований Reactor не хватает устойчивости (то есть того, что дает вам контроль в Akka) и прозрачности местоположения (то есть ссылки на активные объекты таким образом, который позволяет вам абстрагироваться от локального или удаленного обмена сообщениями; это то, что вы подразумевается под «распределенным»). Что касается «модульного», я не знаю достаточно о Reactor, в частности о том, как искать активные компоненты и управлять ими.

Если начать реальный проект сейчас и нужно что - то , которое удовлетворяет ваше первое предложение, то я не думаю , что было бы спорным рекомендовать Акка в этот момент (как Джон также отметил). Не стесняйтесь задавать более конкретные вопросы в SO или в списке рассылки akka-user .

Роланд Кун
источник
Спасибо, Роланд, мне нравится видеть, что люди из обоих проектов вносят свой вклад в ответ. Сейчас я пробую Akka. Как вы и предполагали, давать окончательный ответ на этот вопрос пока преждевременно, за исключением того, что Reactor все еще находится на ранней стадии и поэтому не подходит для сравнения. Итак, давайте подождем и посмотрим, как все будет развиваться :-) Спасибо, Дэвид
Дэвид Риччителли
7
Спасибо за ответ, Роланд. Я просто хотел уточнить, что Reactor не является конкурентом Akka. Есть сходства из-за пересекающихся проблемных областей, касающихся асинхронных приложений. Но Reactor задуман как фундамент, на котором могут быть построены другие системы. Эти другие системы могут пересекаться с Akka даже больше, чем с Reactor. Но в обозримом будущем Reactor останется фреймворком, который поддерживает другие системы, и не будет сам по себе полнофункциональным фреймворком. Вам придется отложить вознаграждение в перестрелке Reactor / Akka. ;)
Джон Брисбин
Не беспокойтесь, я думаю, у вас все будет хорошо, и я совершенно уверен, что мы увидим перекрестное опыление, когда в это поле войдет больше библиотек.
Роланд Кун
37

Reactor не привязан к Spring, это дополнительный модуль. Как сказал Джон, мы хотим, чтобы Reactor был портативным.

Я не буду уверен в продвижении в продакшене, поскольку мы даже не являемся Milestone (1.0.0.SNAPSHOT), в этом отношении я хотел бы более глубоко взглянуть на Akka, которая является фантастической асинхронной структурой IMO. Также рассмотрите Vert.x и Finagle, которые могут быть адаптированы, если вы ищете платформу (первое) или составные фьючерсы (второе). Если вы следите за широким спектром асинхронных шаблонов, возможно, GPars предоставит вам более полное решение.

В конце концов, у нас, безусловно, могут быть совпадения, на самом деле мы склоняемся к смешанному подходу (гибкая составная обработка событий, распределенная и не привязанная к какой-либо стратегии диспетчеризации), где вы можете легко найти биты из RxJava , Vert.x , Akka и т. Д. Мы даже не ограничены выбором языка, даже если мы твердо привержены Groovy, люди уже запустили порты Clojure и Kotlin . Добавьте к этому тот факт, что некоторые требования обусловлены Spring XD и Grails .

Большое спасибо за проявленный интерес, надеюсь, через пару месяцев у вас будет больше точек для сравнения :)

Стефан Мальдини
источник
Спасибо, Стефан, я считаю, что ваш ответ (и комментарий Джона, stackoverflow.com/questions/16595393/akka-or-reactor/… ) дает гораздо более четкую перспективу. Я все еще подожду, прежде чем отмечать ответ на вопрос, как вы сказали, посмотрим, что появится в ближайшем будущем. Опять же, я очень ценю, что люди, участвующие в обоих проектах, потратили время на полезные идеи.
Дэвид Риччителли
Я согласен с Vert.x. Я использовал Vert.x в производственной среде в нескольких проектах для связи между компонентами, и он работает без проблем.
Победы
33

Это отличный вопрос, и ответ изменится в ближайшие недели. Мы не можем давать никаких обещаний относительно того, как будет выглядеть межузловая коммуникация прямо сейчас, только потому, что еще слишком рано. Нам еще предстоит собрать некоторые части, прежде чем мы сможем продемонстрировать кластеризацию в Reactor.

С учетом сказанного, то, что Reactor не поддерживает межузловую связь OOTB, не означает, что это невозможно . :) Нужен только довольно тонкий сетевой слой для координации между Reactors, используя что-то вроде Redis или AMQP, чтобы дать ему некоторый кластерный ум.

Мы определенно говорим и планируем распределенные сценарии в Reactor. Пока еще рано говорить, как именно это будет работать.

Если вам нужно что-то, что выполняет кластеризацию прямо сейчас, вам будет безопаснее выбрать Akka.

Джон Брисбин
источник
Спасибо, Джон, я считаю Reactor очень многообещающим. Тем не менее, мне нужно понять, есть ли концептуальная разница между Reactor и Akka, помимо функций, которые отсутствуют в Reactor (конечно, на ранней стадии). В итоге, в чем концептуальная разница между Актером в Akka и Потребителем в Reactor? Я также обновил свой вопрос образцом события в Akka, которое, как мне кажется, похоже на подписку / отправку событий на странице Reactor GitHub. Спасибо.
Дэвид Риччителли
Джон, я читал ваш ответ здесь: blog.springsource.org/2013/05/13/… - поэтому мы можем предположить, что в долгосрочной перспективе Akka и Reactor будут похожими фреймворками, поддерживающими как шаблон Reactor, так и модель Actor.
Дэвид Риччителли
Приведенный выше комментарий не является более правильным по следующим
причинам
Я не понимаю, почему этот комментарий теперь некорректен? Здесь ничего не противоречит объяснению стратегического направления Reactor.
Джон Брисбин
1
Попался. Да вы правильно поняли. Спасибо, что задали эти вопросы! :)
Джон Брисбин