どのアーキテクチャを選ぶべきですか？メッセージをキューから取り出し、1つずつ処理するワーカープロセスがあります。これで、多くのWindowsサービスインスタンスにこのジョブを実行させることができます。または、1つのWCFサービスをWindowsサービスとしてホストして、インスタンスごとにスレッドを開始できるサーバーのようなものとして機能させることができます。
どちらのアプローチがより適切にスケーリングしますか？スケーリングが非常に速いインフラストラクチャのようなクラウドと、非クラウドベースのインフラストラクチャについて話しているときの視点が必要です。
クラウドで最もスケーラブルなアプローチは、WCFまたはWeb-apiを使用してサービスを処理するようにインスタンスを構成することです（RESTFULサービスを設計している場合に推奨されます）。このようなインスタンスはスケーラブルです。Azureの場合、これをIISでホストされるWebロールと見なします。IISは、クライアントからの着信要求に合わせて拡張できるように設計されています。もう1つの利点は、IISとasp.netインフラストラクチャを使用してセキュリティなどを管理できることです。ただし、それが必要ない場合は、WindowsサービスでホストされているWCFまたはWeb-apiサービスを使用してください。次に、Webサービスインスタンスはメッセージをキューに入れるか、作業がキューにロードされると言います。Azureの場合、キューはサービスバスキューにすることができます。次に、WindowsサービスまたはAzureワーカーの役割を使用して、キューから作業項目をプルできます。通常、1人のワーカーがキューから複数のメッセージをプルして処理します。そうしている間、それらのメッセージは他のワーカーには利用できません。ワーカーが完了したら、メッセージまたは作業負荷をキューから削除します。しばらくすると、他のワーカーに表示されるようになるため、Amazon SQSのように、可視性のタイムアウト設定があるように、可視性の設定があります。* 1つのワーカーで5〜10個のメッセージをプルし、それらを「タスク」並列としてスレッドプールスレッドとして実行します。
フロントエンドにスケーラブルなサービスインスタンスがあり、バックエンドで着信リクエストとワーカーの役割を受け取り、ワークアイテムをできるだけ早くクリアするアーキテクチャは、AzureサービスバスやAmazonSQS。そうしないと、競合の問題が発生する可能性があります。
通常、分散キューがない場合の社内（非クラウド）展開の場合、ここでは、IISホストサービスインスタンスにすべてを実行させるか、Windowsサービスにすべてまたは組み合わせを実行させることができます。Webページを提供して着信要求を受信するためにIISでHTTPサービスをホストすることをお勧めします（RESTサービス）。IISはその点で優れています。ただし、IISプールはリサイクルされる可能性があり、長期間要求がない場合は実行されない可能性があります。したがって、スケジュールされたタスクまたはジョブを実行する必要がある場合は、バックエンドでWindowsサービスが適しています。Windowsサービスですべてを実行できることは確かに実行可能ですが、私の経験から、着信要求にIISとasp.netを使用すると生産性が向上します。セキュリティをサービスやウェブアプリと共有できます。フロントエンドにIISを、バックエンドにWindowsサービスを配置することを好みます。これにより、Windowsサービスでセキュリティを管理する必要がなくなります。社内キューにNServiceBusを試してくださいhttps://github.com/NServiceBus/NServiceBus。私はそれを評価していません。
単にワーカーをサービスでホストしてマルチスレッドにすることはできませんか？キューを読み取ってサービスを呼び出すディスパッチャを作成する必要があるため、Wcfは物事を台無しにします。コンシューマーをサービスとして機能させることで、複数のマシンにインストールすることもでき、同じキューから読み取るように構成して、垂直方向と水平方向の両方にスケーリングできます。MSMQ使用している、または他の同様のキューメカニズムを使用していると思いますが、そうでない場合は、使用を検討してください。
各ワーカーをシングルスレッドのWindowsサービスでホストします。これには次の利点があります。