6

サードパーティのexeを使用してリクエストを処理するasp.net Webサイトがあります。現在、私のワークフローは

  1. ユーザーは任意のブラウザーを使用して Web サイトにアクセスし、ジョブの詳細をフォームに入力します。

  2. Web サイトは、ポートでリッスンしている WCF 自己ホスト型 Windows サービスを呼び出します

  3. Windows サービスはサードパーティの exe を起動してジョブを処理し、結果を Web サイトに返します

  4. ウェブサイトは返された結果をユーザーに表示します

上記の Web サイトはプロトタイプであり、本番環境での展開に変更する必要があります。上記のアーキテクチャには、壊れる可能性のある多くのポイントがあることに気付きました。たとえば、マシンの電源がオフになっている場合、または Windows サービスがクラッシュしてポートをリッスンしていない場合、現在のすべての要求は処理を停止します。アーキテクチャをより堅牢にするために、次のことを検討しています

  1. ユーザーは任意のブラウザーを使用して Web サイトにアクセスし、ジョブの詳細をフォームに入力します。

  2. ウェブサイトがジョブの詳細をデータベースに書き出す

  3. 新しいジョブを求めて 10 秒ごとにデータベースをポーリングしている Windows サービスは、ジョブを取得し、サード パーティのアプリケーションを使用して実行します。結果はデー​​タベースに書き戻されます。

  4. データベースのポーリングを開始した Web サイトは、結果を取得してユーザーに表示します。

2 番目のアーキテクチャでは、より多くのログ機能が提供され、ジョブがキューにある場合はジョブを再開できます。ただし、スケーラブルでない可能性がある大量のポーリングが含まれます。より良いアーキテクチャを推奨できる人はいますか?

4

2 に答える 2

0

ユーザーが複数のリクエストを処理するアプリケーションの 1 つに同じアーキテクチャを実装しました。ので、私は持っています -

  1. ユーザーは Web サイトにアクセスし、パラメーターなどを選択します。リクエストを送信します。
  2. リクエストは、すべての詳細とユーザー名などとともにデータベーステーブルに保存されます
  3. サービスはデータベース テーブルを参照し、FIFO 方式で要求を受け取ります。
  4. リクエストが処理された後、その requestId に対してステータスが Failed または Completed としてデータベース テーブルに更新されます。これは Web サイトでユーザーが確認できます。
  5. サービスは、次の要求があればそれを受け取り、そうでなければ停止します。
  6. サービスは 30 分ごとに実行されます
于 2013-01-10T04:09:15.110 に答える
0

Polling の代わりに、 MSMQ またはRabbitMQを使用します。

そうすれば、処理をキューの複数のコンシューマー (おそらく Web サーバーとは別のサーバー) にオフロードし、より多くのリクエストを並行して処理できます。

于 2013-01-10T04:52:14.147 に答える