Azure Service Fabricの信頼できるアクターと信頼できるサービス
私はAzure Service Fabricを初めて使用しますが、最大の質問は
- 信頼できるアクターを使用する必要があるのはいつですか？実用的な例をお願いします。
- いつ信頼できるサービスを使用すべきですか？実用的な例をお願いします。
違いを見てみましょう：
- 状態の類推：アクターはオブジェクトグラフの単一インスタンスで動作します。通常、サービスには複数の発信者の状態があります。
- スコープ：アクターは、サイズが大きいため（オブジェクトに似ているため）、単独では動作しません。
- ライフサイクル：アクターは使用されている場合にのみアクティブになるため、利用可能なサーバーリソースにより多くのアクターが適合
- 同時実行：アクターはシングルスレッドアクセスを強制します
- State：アクターは集合体を変更するだけで、サービスはセットで動作するため、ACID動作のためにセットでトランザクションを使用することがよくあります。
- 通信：アクターはプラットフォームが提供するチャネルを介して通信します。それ以外の場合、サービスが選択する場合があります。
- アクセス：クラスター内のアクターは、デフォルトでは外部から到達できません。おそらく、アクセスを提供するサービスが必要になります。
アクターを使用する場合のサンプル：
- モバイルアプリのすべてのユーザーに対して、アクターを1人持つことができます。
- 情報をアプリケーションに送信するサーモスタットごとに、1人のアクターがいる可能性があります。
- Eコマースサイトのすべての顧客に対して、ショッピングバスケットアクターを1人持つことができます。
おそらく慣れている場合にサービスを作成します。一度に複数のユーザーにサービスを提供する信頼できるサービスを作成します。たとえば、天気予報サービス。
Wordを使用して自分自身を定義するつもりはありませんが、問題がアクターのデザインパターンに適合すると判断した場合にのみ、信頼できるアクターを使用してください。アクターは、Gang of Fourの多くのデザインパターンによく似たデザインパターンです。問題がパターンのいずれかに当てはまる場合は、それを使用します。そうでない場合は、問題を間違ったパターンに押し付けないようにすることをお勧めします。
Service Fabricでは、Reliable ActorsはVirtual Actorパターンの実装です。特定の操作規則と、それに伴う警告があります。これは、Reliable Actorフレームワークがどのように機能し、それが要件を満たしているかどうかのアイデアを得るために読むべき良いドキュメントです： https://Azure.Microsoft.com/en-us/documentation/articles/service -fabric-reliable-actors-platform /
Reliable Actorsは、実際にはReliable Servicesの上に構築された単なるフレームワークであるため、すべて同じスケーリング、パーティション分割、および配布ルールが適用されます。