サービスファブリックサービスは完全にシングルスレッドですか？

Question

私はサービスファブリックを手に入れようとしており、少し苦労しています。いくつかの質問：

• すべてのサービスファブリックサービスインスタンスはシングルスレッドですか？私はTask.Delayを行ったメソッドでステートレスWeb APIを作成し、文字列を返しました。このサービスへの2つの要求は、同時にではなく次々と提供されました。だから私は、サービスマニフェストのサービスインスタンス数に応じて、同時に処理できる同時リクエストの数が増えると考えていますか？ これについて考えると、おそらくOWIN Wep Apiの設定と関係があるでしょう。セッションでブロックしている可能性はありますか？私はデフォルトでセッションがないと仮定しましたか？

• サービスファブリックで実行する必要がある実行時間が長すぎます（数時間かかることがあります）。これをサービスファブリックで使用するための推奨パターンはありますか？これらは現在、Webジョブをトリガーするストレージキューを使用して処理されます。信頼できるキューとRunAsyncループを備えた何か？

Answer 1

これは純粋にクライアントの問題です。 Chromeは私の要求を本質的でないと見て、第1の要求が応答するまで第2の要求を延期しました。要求のパラメータを変更することで、それらを同時に処理することができました。

Answer 2

最初の部分を処理したようですので、2番目の部分についてコメントします。「長期実行操作」。

長時間実行されている操作/ワークフローは、サービスファブリックが出現するずっと前から処理されています。このため、ソフトウェア専門家が何十年も使ってきた設計パターンを見て、巨人の肩を築くことができます。たとえば、有名なオールインクルーシブProcess Managerです。このパターンは時には過度のことであることに気をつけてください。あなたのケースでは、Enterprise Integration Patternsの書籍（Gregor Hohpe）の関連するパターンの残りの部分をチェックしてください。

信頼できるコレクションの使用に関しては、選択したデザインパターンをサポートするデータ構造を選択する際の実装の詳細です。

私はそれはあなたの第二の点に関しては

Answer 3

を支援を期待 - それは本当にあなたの長時間実行タスクの性質に依存します。

長時間実行されている作業は、ローカルOS/VMレベルのリソースに依存し、最終的に結果（A）が返される独立したスレッドで実行されるワークロードの種類ですか？それとも、ステージを経て一連の持続的な状態変化（B）によって結果のモデルを構築する、長時間実行されるタスクの種類ですか？

私はService Fabricについて理解しているので、長時間実行されるワークロード（A）を実行するためのものではなく、水平方向に拡張可能な高可用性システムを書くためのものです。

あなたがサービスファブリックを使用することに絶対に熱心だったなら（そしてあなたの仕事の種類はAよりもBの方が多い傾向があります）、私は間違いなく、クラスタ全体で並列に処理できる長時間実行されているタスクを分解する方法を見つけます。しかし、それでもAzure Batchのようなこれに適した技術はおそらくありますか？

p.s.RunAsyncメソッドに長時間実行するプロセスを配置する場合は、ワークロードを中断可能に設計し、その状態をクラスタ内の別のノードから再開できるように設計する必要があります。

Inステートフルなサービスでは、プライマリレプリカのみが 状態への書き込みアクセス権を持っているため、通常はサービスが実際に の作業を実行しています。ステートフルサービスのRunAsyncメソッドは、 ステートフルサービスレプリカがプライマリの場合にのみ実行されます。プライマリレプリカのロールがプライマリから変更された場合、RunAsyncメソッドは となり、クローズおよびアボートイベントの場合と同様に となります。

P.s.s長時間実行される操作は、スケーラブルなシステムを作成しようとすると悪魔です。それを試してみて、将来の痛みを取り除いてください。