2

今、システムのアーキテクチャをどのように整理するかを考えています。このシステムは、ユーザーがドキュメントをアップロードして処理を戻すことができる Web サイトと、提供されたドキュメントを処理するタスクのキューを備えたバックグラウンド デーモンで構成されます。

私の質問は: 名前付きパイプのみを使用する (このサービスへのネットワーク アクセスは必要ありません) WCF サービスとして、上記で説明したデーモンを実装する必要がありますか?

それに関する提案/ヒント/アドバイスはありますか？

ユーザーが提供できるデータは、XML ファイルの集まりです。ASP.NET Web サイトは、この XML ファイルを取得する機能を公開し、何らかの方法でそれらをデーモンに渡すことができるはずです。

そのトピックに関するいくつかの記事を教えてください。前もって感謝します！

編集後

ここで提案された MSMQ を発見して数時間後、そのテクノロジについての私の考えは、分散アーキテクチャ (処理ノードは別々のマシンに配置され、ネットワークを介して異なるコンピュータ間でメッセージが交換されます) 向けのものです。

現時点では、独立したマシンに分離する必要はありません。ASP.NET Web サイトといくつかの処理プログラムがあるマシン上にあるだけです。

MSMQの使用はそれほど必要ですか?

ポストエディット #2

ここでは .NET Framework を使用しているため、.NET と互換性のあるもののみを提案してください。ここには本当にオプションはありません。

4

4 に答える 4

3

展開が単一のサーバー上にある場合は、WCFサービスの最初のアイデアがおそらく進むべき道です。IISまたはWindowsサービスでのホスティングに関する説明については、MSDNを参照してください。

@JeffWatkinsが言ったように、サービスを呼び出すときに従うべき良いパターンは、処理が必要なディスク上のファイルの場所を単に渡すことです。これは、大きなファイルを処理するときにはるかに効率的です。

ここで採用する正確なアプローチは、ユーザーから受け取るファイルの性質によって異なると思います。非常に小さいファイルの場合は、ディスクに触れないように、Webサイトからサービスにストリーミングする方が効率的です。この場合、サービスは小さなファイルを処理するときに使用される追加のメソッドを公開します。

編集

ファイルがストリーミングされる可能性のある条件を導入することはおそらく良い考えですが、次のことを理解できるように、いくつかのテストを行うことは価値があります。

  1. やる価値があるかどうか
  2. ストリーミングとディスクへの書き込みに最適なサイズ

私の答えは、単一のマシンにデプロイしているという仮定に基づいていました。よりスケーラブルなものが必要な場合は、そうです。MSMQを使用すると、アプリケーションをスケーリングするのに適した方法になります。

WCF / MSMQデモアプリを構築するためのサンプルコードについては、MSDNを参照してください。

于 2012-10-16T00:48:43.120 に答える
3

似たようなものをデザインしました。接続ポイントとして WCF サービスを使用し、次にメッセージをキューに入れるために RabbitMQ を使用しました。次に、別のサービスがキュー内のアイテムを処理し、タスクが終了したときに非同期コールバックを送信して、WCF 呼び出しを終了します (WCF には、これを処理するための組み込み機能が多数あります)。

各側でタイムアウトを設定することも、WCF 接続をドロップして非同期コールバックを使用して「処理が終了した」ことをユーザーに通知することもできます。

これは私たちのチームが思いついたものであり、非常にうまく機能しているため (4 サーバー プールで 1000 TPS、100% ステートレス)、リンクはありません。単なるアイデアです。

于 2012-10-17T21:46:52.797 に答える
1

ServiceStack を真剣に検討します。この機能は組み込まれており、最小限のプログラミングで済みます。さらに、ServiceStack のアーキテクチャは非常に優れており、問題が発生した場合でも簡単にデバッグできます。

https://github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis

関連して、私の会社は Web ベースの REST API フロント エンド (REST サービスは ServiceStack を使用) を使用して多くの非同期バックグラウンド処理を行っています。複数のマシンを使用し、RabbitMQ バックエンドを実装しました。ただし、RabbitMQ .NET ライブラリは非常に設計が不十分で、不必要に扱いにくいものです。この問題を修正するためにコア クラスの再設計を行いましたが、プロジェクトを本番環境にリリースしていないため、まだコミュニティに公開できていません。

于 2012-10-18T23:30:39.107 に答える
0

http://www.devx.com/dotnet/Article/27560をご覧ください

少し時代遅れですが、有利なスタートと基本的な理解を得ることができます。

于 2012-10-11T09:35:46.473 に答える