問題タブ [orleans]

Microsoft Orleans では、以下のコードを使用して、利用可能な作業のリストのようなものを実装しようとしています:

これは機能しますが、このようなコードを使用して多くのタスクを開始すると、正しく動作しません。

これは機能しますが、別のノードがクラスターに参加した場合、その機能は新しいノードに決して移動しないようです。その新しいノードでは、新しくスケジュールされた作業のみが処理されます。

また、Orleans Queue にこの余分な作業が大量にある場合、新しいノードがクラスターに参加できなくなるようです。

IoT データ収集プロジェクトと IoT データ処理プロジェクトがあります。それらは個別に開発および保守されます。ただし、Orleans のサイロ (またはサイロ クラスター) で共通の穀物を共有することは有益です。自己ホスト型のシナリオ (サイロ内の通信用に両方のプロジェクトを参照するモノリシック サイロ、または外部と通信する 2 つの別個のサイロ) では、アーキテクチャはどのように見えるでしょうか? サイロが 1 つの場合、サイロはグレイン .dll を動的に検出できますか?

Grain に依存関係を注入する方法や場所がわかりません。これを行うのに最適な場所はどこですか?

それができない場合は、WorkerRole.Run メソッドでコンテナーを設定し、必要に応じてインスタンスを取得する必要がありますか?

サイロに接続したい Asp.Net vNext サイトがあります。vNext サイトは既に完成しており、運用中ですが、サイロ部分はまだ開始されていません。私はちょうど計画段階にいるので、クレイジーに思えたら、アイデア全体を廃棄するときです。これは実行可能ですか？

仮想ネットワークを作成して Web アプリを Worker ロールに接続できることは知っていますが、これは非常に簡単に思えます。しかし、特に DeploymentIds の使用/検出に関して、サーバーとクライアントの構成がどのように見えるべきかわかりません。

Orlean が提供する AzureClient を vNext サイトで使用しようとすると、例外がスローされます。これは、Azure 関連の型が Serializable とマークされていないことに関するものです。vNext サイトでは、DeploymentId を手動で指定することで、通常の SiloClient を機能させることができます。私の開発環境では、DeploymentId はデバッグのたびに変更されるため、これは明らかに機能しません。

ここで正しい方向に私を向けるためのアドバイスはありますか? さらに情報が必要な場合はお知らせください。喜んで提供させていただきます。

簡単な例を見てみましょう。1,000,000 人のユーザーを持つサービスがあり、各ユーザーにはいくつかのプロファイル情報があります。アクターを使用して、このプロファイル情報に対する CRUD 操作を管理したいと考えています。

Project Orleansでは、ユーザーごとに 1 つのグレインがあり、同じアクター タイプ (使用された場合にのみ作成される) の 1,000,000 の仮想グレインがあり、各グレインは、その中に格納されている単一のユーザーのプロファイル情報を管理します。州。ユーザーが増えるにつれて、グレインの数も増えます。

Service Fabricでは、ドキュメントを正しく解釈すると、動作が少し異なります。すべてのユーザーに対する CRUD 操作を管理するステートフルなアクター タイプを用意し、スケーラビリティのためにアクターをパーティション分割して、各パーティションにユーザー データのサブセットに対する責任を与えます。パーティション オプションを考えると、Project Orleans と同じようにきめ細かく実装する明確な方法がわかりません。

Project Orleans のアプローチがとても気に入っています。アクターは 1 人のユーザーのデータを処理しているだけであり、スケーラビリティは明らかです (ユーザーが多いほど粒度が高くなります)。メモリ モデルも単純です。単一のアクターが少量の状態でオンデマンドでハイドレートされます。

Service Fabric の実装はもう少し複雑になるようです。各アクターは一連のユーザーを処理します。スケーラビリティのために、作成するパーティションの数を事前に決定する必要があります。これは後で変更できないためです。メモリ モデルに関しては、各アクターが管理するデータの量は、ユーザーの数が増えるにつれて増加します。

私の質問は次のとおりです。Service Fabric のアクターは Project Orleans よりも単純に粗粒度であるという私の理解は正しいですか?

アップデート

答えてくれてありがとう。私の間違いは、パーティションには、パーティション内のすべてのアクター ID の状態を格納および管理する単一のアクター インスタンスが含まれていると考えていたことです。これは完全に間違っています。Michiel は、パーティションには複数のアクター インスタンス (アクター ID ごとに 1 つ) が含まれていると指摘しています。したがって、アクターは Project Orleans と同じ方法で実装できます。これは今でははるかに理にかなっています、ありがとう。

アクターが送信された順序でメッセージを処理する必要があるという問題があります。Akka では、アクター A とアクター B の間のメッセージは常に、送信された順序で到着することが保証されています。これは、Service Fabric の Reliable Actors には当てはまらないようです。私のテスト ケースでは、メッセージは非決定的な順序で受信されます。

最初のメッセージが処理されるまで次のメッセージを送信しないことで順序付けを強制できますが、これではポイント全体が無効になります。私は本当にメッセージを送信して忘れたいのですが、受信側のアクターによって順番に処理されることを知っています。

これを行うためのパターンを見た人はいますか？Orleans Actors にも、同様にメッセージの順序が乱れる可能性があると思います。おそらく、Orleans ソリューションもここで機能するでしょう。