AkkaまたはReactor [終了]

私は新しいプロジェクト（javaベース）を始めようとしています。私はそれをモジュール式の分散型の弾力性のあるアーキテクチャとして構築する必要があります。

したがって、私は、ビジネスプロセスが相互に通信し、相互運用可能であると同時に独立していることを望んでいます。

私は現在、年齢の違いに加えて、2つの異なる見解を表現する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");

したがって、この2つの主な違いは次のとおりです。

• Akka、より成熟した、Typesafeにバインド
• 原子炉、初期段階、春にバインド

私の解釈は正しいですか？しかし、概念的にはAkkaのActorとReactorのConsumerの違いは何ですか？

Reactorはまだスケッチであり、私（Akkaの技術リーダー）はそれがどこに行くのかについての洞察を持っていないので、現時点ではわかりにくいです。ReactorがAkkaのライバルになるかどうかは興味深いです。楽しみにしています。

私の知る限り、要件リストから、Reactorには弾力性（つまり、Akkaで提供される監視機能）と場所の透過性（つまり、ローカルまたはリモートのメッセージングを抽象化できる方法でアクティブなエンティティを参照する）がありません。 「分散」を意味します）。「モジュール式」の場合、特にアクティブなコンポーネントを検索して管理する方法について、Reactorについてはよくわかりません。

ここで実際のプロジェクトを開始し、最初の文を満たすものが必要な場合、この時点でAkkaを推奨することは論争の余地がないと思います（Jonも述べたように）。SOまたはakka-userメーリングリストで、より具体的な質問をしてください。

ReactorはSpringにバインドされておらず、オプションのモジュールです。Jonが概説したように、Reactorはポータブルであり、基盤となるものであることが望まれます。

私たちはマイルストーン（1.0.0.SNAPSHOT）でさえないので、本番環境への移行に自信がありません。その点では、素晴らしい非同期フレームワークIMO であるAkkaをより深く見ていきます。また、Vert.xとFinagleも検討してください。プラットフォーム（前者）または合成可能な先物（後者）のどちらかを探す場合は、これらを適応させることができます。広範囲の非同期パターンを検討する場合、GParsがより完全なソリューションを提供するでしょう。

最後に、確かに重複がある可能性があります。実際には、RxJava、Vert.x、Akkaなどからビットを簡単に見つけることができる混合アプローチ（柔軟なコンポーザブルイベント、分散、ディスパッチ戦略にバインドされていない）に傾いています。私たちは言語の選択にさえ意見を述べていません。たとえGroovyに強くコミットしていても、人々はすでにClojureとKotlinの移植を始めています。このミックスに加えて、一部の要件はSpring XDとGrailsによって駆動されるという事実を追加します。

あなたの目撃した関心に感謝します。うまくいけば、2、3か月でより多くの比較ポイントが得られるでしょう:)

これは素晴らしい質問であり、答えは今後数週間で変わります。早すぎるからといって、ノード間通信が今どのように見えるかについては、何も約束できません。Reactorでクラスタリングをデモンストレーションする前に、いくつかのピースをまとめておきます。

そうは言っても、Reactorがノード間通信を実行しないからといって、OOTBが実行できないとは限りません。:) RedisやAMQPなどを使用してReactor間を調整し、クラスター化されたスマートを実現するには、かなり薄いネットワークレイヤーだけが必要です。

私たちは間違いなく、Reactorでの分散シナリオについて話し、計画しています。それがどのように機能するかを正確に述べるのは時期尚早です。

今すぐクラスタリングを行う必要がある場合は、Akkaを選択する方が安全です。