Акка або реактор [закрито]


94

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

Тому я хотів би, щоб бізнес-процеси спілкувались між собою, були сумісними, але й незалежними.

Зараз я розглядаю дві основи, які, крім різниці у віці, висловлюють 2 різні погляди:

Що я повинен врахувати, вибираючи одну з вищезазначених платформ?

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

Хтось може допомогти мені зрозуміти, як прийняти правильне рішення?

ОНОВЛЕННЯ

Після кращого огляду шини подій 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
  • Реактор, рання стадія, прив’язаний до весни

Чи правильне моє тлумачення? Але в чому концептуально різниця між актором в Акці та споживачем у реакторі ?


8
Скала не зобов’язана використовувати Akka, насправді більшість використовує її з Java.
Віктор Кланг,

1
Девід: Щось на зразок: API Akka EventBus спільно з Akka Actors реалізує шаблон реактора
Віктор Кланг,

9
Тільки для уточнення: реактор взагалі не пов’язаний із Spring. Ми навмисно уникаємо будь-яких залежностей Spring, оскільки, як основоположний фреймворк, немає сенсу обмежувати його використання лише користувачами Spring. Що стосується різниці між актором та споживачем: що стосується реактора, то ваш споживач може бути прихильним чи ні. Передбачається, що ви захочете використовувати анонімний клас без стану або лямбду Java 8, але це не є вимогою. І, як я вже згадував у своїй відповіді, набір інструментів Reactor є для ранніх ітерацій навмисно стислим. Ми не намагаємось створити "наступну Акку".
Джон Брісбін,

8
Просто відкинувши згадку про vertx.io, оскільки я вважаю, що він знаходиться в одному і тому ж полі, керованому подіями, з деякими цікавими поняттями в подібному ключі для тих, хто займається дослідженнями.
Відкрито

1
Протягом декількох років, я теж потрапив у подібну ситуацію. Моя програма в основному весняна, і мені зараз потрібно обробити функцію, керовану подіями. Чи є чіткий переможець ч / б Акка та Spring-реактор? Я шукаю фреймворк з активними комунікантами користувачів на випадок, якщо досягну складніших сценаріїв.
tintin

Відповіді:


47

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

Наскільки я бачу, у вашому списку вимог Reactor відсутня стійкість (тобто те, що нагляд надає вам в Akka) та прозорість розташування (тобто посилання на активні сутності таким чином, що дозволяє вам абстрагуватися від локальних або віддалених повідомлень; саме це ви мають на увазі "розподілений"). Щодо “модульного”, я недостатньо знаю про Reactor, зокрема, як можна шукати активні компоненти та керувати ними.

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


Дякую Роланду, я люблю бачити, що люди з обох проектів вносять свій внесок у відповідь. Зараз я випробовую Akka. Як ви передбачали, остаточно дати остаточну відповідь на питання, за винятком того, що Reactor все ще перебуває на початковій стадії, тому ще не підходить для порівняння. Отже, давайте почекаємо і подивимось, як все розвиватиметься :-) Дякую, Девід
Девід Річітеллі

7
Дякую за вашу відповідь, Роланде. Я просто хотів пояснити, що Reactor не є конкурентом Akka. Існує схожість через перекриваючу область занепокоєння щодо асинхронних програм. Але Reactor має бути основою, на якій можуть будуватися інші системи. Ці інші системи можуть накладатись ще більше на Akka, ніж сам Reactor. Але в найближчому майбутньому Reactor залишатиметься рамкою, яка забезпечує інші системи, і сам по собі не буде повнофункціональною структурою. Вам доведеться відкласти задоволення під час перестрілки «Реактор / Акка». ;)
Джон Брісбін,

Не хвилюйтеся, я думаю, що у вас все буде добре, і я впевнений, що ми побачимо перехресне запилення, коли все більше бібліотек входить у це поле.
Роланд Кун,

37

Реактор не прив'язаний до Spring, це додатковий модуль. Ми хочемо, щоб Reactor був портативним, фундаментом, як зазначив Джон.

Я не буду впевнений у просуванні виробництва, оскільки ми навіть не є Milestone (1.0.0.SNAPSHOT), у зв'язку з цим я б глибше розглянув Akka, який є фантастичним асинхронним фреймворком IMO. Також розглянемо Vert.x і надувати , які можуть бути адаптовані , якщо ви дивитеся або на платформі (колишній) або компонованих ф'ючерси (остання). Якщо ви доглядаєте за широким спектром асинхронних моделей, можливо, 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, не означає, що не може . :) Для координації між реакторами потрібно лише досить тонкий мережевий шар, використовуючи щось на зразок Redis або AMQP, щоб надати йому кілька кластерних розумних результатів.

Ми однозначно говоримо про та плануємо розподілені сценарії в Reactor. Поки що рано говорити, як саме це буде працювати.

Якщо вам потрібно щось, що займається кластеризацією прямо зараз, вам буде безпечніше вибрати Akka.


Дякую, Джон, я вважаю Reactor дуже перспективним. Однак мені потрібно зрозуміти, чи існує концептуальна різниця між Reactor та Akka, крім функцій, яких Reactor бракує (звичайно, на початковій стадії). Підсумовуючи, у чому полягає концептуальна різниця між актором в Акці та споживачем у реакторі? Я також оновив своє запитання зразком події в Akka, який, на мою думку, нагадує підписку / диспетчеризацію подій на сторінці Reactor GitHub. Дякую.
Девід Річчітеллі,

Джон, я читав твою відповідь тут: blog.springsource.org/2013/05/13/… - тому ми можемо припустити, що в довгостроковій перспективі Akka та Reactor будуть схожими рамками, підтримуючи шаблон Reactor та модель Actor.
Девід Річчітеллі,

Вище коментар не більше коректний з - за наступний: stackoverflow.com/questions/16595393/akka-or-reactor / ... і stackoverflow.com/a/16674388/565110
Девід Річсітеллі

Я не розумію, як цей коментар зараз неправильний? Тут ніщо не суперечить поясненню стратегічного напрямку реактора.
Джон Брісбін,

1
Маю Так, ви правильно розумієте. Дякуємо за запитання! :)
Джон Брісбін,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.