複雑なバックエンド サービスでアクターをどのように使用できるか最終結果を計算するまで、応答などに基づいて続行しますか?
このようなサービスを実装するためにアクターを使用しようとすると、このワークフローのどの部分をアクターによって実装する必要があり、どの部分を実装すべきでないのかという疑問が生じます。
アクター インスタンスは、達成しようとしているタスクが完了するまで使用しているスレッドを解放しません (Future に委譲しない限り)。 N 層の子は、アクターの概念に基づく理想的な設計ですが、一方では最大 N-1 スレッド (最初の要求ごと) を保持します。完了する階層内のアクター。具体的には、階層の最上位のアクターはほとんどの時間アイドル状態になります。
この階層設計は、エラー カーネルパターンにも一致します。
しかし、これは並行性にとって非常に悪いように思えます。
そして、このアクターの階層を維持しようとしても、Future で各アクターへの呼び出しをラップする (伝えるのではなく、子アクターに尋ねることによって) 場合でも、ロックははるかに短くなります (まだ存在しますが) - それでも機能します。非常に多くの Future を使用すると、ステートフルなアクター、またはシステムの状態を自分自身で同期されない方法で変更するアクター (つまり、データベースを変更するだけではなく、少なくとも単純な要求の場合、データベースを介して自動的に行われる) と連携することができなくなります。トランザクションではなく、アプリケーション内の一部のグローバル変数を変更します)。
では、アクターはワークフローの下位レベルでのみ使用する必要がありますか?
または、大部分が階層的である (そしてほとんどがそうである) ワークフローをよりシリアルな方法で書き直す必要があるため、それほど多くのレベルの子アクターは必要ありません (しかし、それは非常に難しく、不自然であり、実装フレームワークも提供するように思われます)。デザインに大きな影響を与えます）。
つまり、アクターは非常に限られていること、耐障害性は主に従来の例外処理によって処理する必要があること、いずれにせよ、耐障害性アプリケーションを必要としても、アプリケーションの設計にそれほど影響を与えるべきではないことを認識していることを意味します。応用。その場合、なぜ役者を悩ませるのですか？複雑なスパゲッティのようなメッセージの結び目のワークフローを理解するためにすべてのアクターの実装を読み取る必要があるフレームワークで作業することは、階層構造に基づくフレームワークで作業するよりもはるかに簡単ではありません。必ずしも実装を覗き込むことなく、メソッドのシグネチャを調べます。
簡単なスケールアウトなど、アクターの利点の多くは、アクターによってアプリケーションのごく一部しか実装されていない場合、関連性が低く実用的ではないように思われます。