サービスファブリックのフローパターン

Question

膨大な量のデータを別々のテーブルやデータベースに保持するために、責任の異なる複数のコンソールアプリケーションを作成しました。例えば、あるアプリケーションがデータベースをシードし、次のアプリケーションがその新しいデータを処理し、最後のフィルタが古いデータと新しいデータを処理することがあります。等

今すぐサービスは順次（手作業で）実行されます。 このようなアプリケーションの結果によっては、前のアプリケーションを実行する必要があります。

このプロセスフローを自動化するために、私はサービスファブリックを使用することを考えています。
1つのサービスの入出力を制御し、正しいサービスに送信する1つの「メイン」サービスがあるパターンはありますか？あるいは、私はサービスファブリックの使用を暴力的に見越していますか？

Answer 1

サービスファブリックは、さまざまなニーズに対応するための非常に柔軟でパワフルな獣です。希望のアーキテクチャを確実に構築できるはずです。

フローを作成して制御するには、SFアクターの使用を検討することができます。パイプラインや何らかの連鎖を簡単に構築することができ、各アクタはタスクの完了方法、次のアクタが成功を呼び出すこと、何かが失敗した場合には誰に苦情を言いますか。アクターが長時間実行し集中的なI/O作業をするのを避けるために、リマインダーを活用することができます。例えば、入力の新しい部分が到着すると、コンソールアプリロジックが実装されている別のSFサービス（実際の作業者）を呼び出して、タスクIDやその他の属性をアクターの状態に保存して 'ワーカー'を識別し、進行中のタスクの状態を確認するようリマインダを設定します。 SFでは、サービスが互いに通信するためのさまざまな方法が用意されているため、瞬く間にアクターと「労働者」のやりとりを設定できます。

あなたのコンソールアプリケーションが些細ではないロジックを持ち、あなたの十字軍の始めにコードを移行するのに多くの時間を費やしたくなければ、SFでGuestExecutablesをプレイすることもできます。

これはちょうど最初の考えであり、いくつかの非常に一般的なデザインです。私の要点は、SFはさまざまなケースを扱うためのすばらしい堅牢なオプションの多様性のために、サービスを行うことに関しては非常に良い選択であるということです。

P.S.

Service Fabric Reliable Services Pipeline designを参照してください。このディスカッションでは、同様の話題に関連していて、わかりやすい詳細を説明しています。