Акка или реактор

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

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

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

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

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

Может кто-нибудь помочь мне понять, как принять правильное решение?

UPDATE

После более качественного обзора Event Bus от 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");

Поэтому мне кажется, что основные различия между ними:

  • Akka, более зрелая, привязанная к Typesafe
  • Реактор, ранний этап, связанный с Spring

Является ли моя интерпретация правильной? Но , что концептуально отличается между Актером в Акке и Потребителем в Реакторе?

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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