私はPlayFramework のフォローアップとしてこれを書いています - 別のローカル ActorSystemでアクターを検索しますが、今回は特に Akka クラウドに質問を向けています。
質問は簡単です: system.actorSelection を介して他のシステムを単純にルックアップする方法がないように見えることを考えると、2 つの ActorSystems を同じホスト (同じホストだけでなく、同じ JVM 上でも) にデプロイすることは理にかなっていますか?ローカルホストにリモートしない限り?
つまり、 system1.actorSelection("akka://system2/user/my-actor") が機能しないため、 system1.actorSelection("akka.tcp://system2@127.0.0.1:2552/user/my -actor") の場合、なぜ 2 つのシステムの導入を検討する必要があるのでしょうか?
ユースケースについて質問されると思われるので、ここに 1 つ挙げておきます。Akka を使用した複雑なリアルタイム システムがあり、このシステムが自律エージェントとして任意の数のマシンにデプロイされているとします。理想的には、このシステムに割り当てるリソースをきめ細かく制御し、ある程度分離したいと考えています。さらに、入力を提供し、リアルタイム システムを監視するという特定の目的で、小さな制御インターフェイス (REST API など) を書きたいとします。当然、その制御システムを、最初のシステムと相互作用する別の ActorSystem にします。それは理にかなっていますよね？リアルタイム処理と同じActorSystemでアクターを実行したくありません（分離、実用性、個別のロギング、リソース監視の非汚染、監督 -- 階層にブランチをもう 1 つ追加する -- など)。そのコントロール ActorSystem は、リアルタイム システムと連携しているため、別のマシンにデプロイされることはありません。ただし、これら 2 つのシステムが通信する唯一の方法は、ループバック tcp を使用することです。
私が提案していることは、物事を行うための適切な/意図した方法ではありませんか? 何か不足していますか？私が考慮していないこれを行う方法はありますか？私のユースケースは Akka を使用する必要がありますか?
ご意見をお寄せいただきありがとうございます。