冗長/分散アプリケーションの構築
これは、「正しい方向に私を向ける」という質問です。
私の3人のチームと私は、カスタマーチャットリクエストをキューに入れて利用可能なカスタマーサービスエージェントにルーティングするホスト型Webアプリを構築しました（他のことも行いますが、これは問題を説明するのに十分な背景です）。
今日の基本的な開発アーキテクチャは次のとおりです。
- フローティングチャットウィンドウを備えた単一ページのajaxWeb UI（ASP.NET MVC）（Gmailを考えてください）
- チャットリクエストをキューに入れてルーティングするバックエンドWindowsサービス
- このサービスは、チャットのログ記録、サービスレベルの計算なども行います。
- webフロントエンドとバックエンドWindowsサービスの間でデータをルーティングするCometサーバー製品
- これは、どのエージェントがまだ接続されているかを検出するのにも役立ちます（オンライン）
そして、今日のハードウェアアーキテクチャは次のとおりです。
- アプリケーションのWebUI部分をホストする2台のサーバー
- 2つの異なるWebアプリサーバーにリクエストをルーティングするロードバランサー
- sQL Server DBをホストする3番目のサーバーと、チャットのキューイング/配信を担当するバックエンドWindowsサービス
そのため、現在のところ、Webアプリサーバーの1つがダウンする可能性があり、問題はありません。ただし、SQL Server/Windowsサービスサーバーに何かが起こった場合、私たちは骨が折れるでしょう。
私の質問-このバックエンドWindowsサービスロジックを複数のマシンに分散（分散）できるようにするにはどうすればよいですか？ Windowsサービスは、Cometサーバーからの要求を受け入れ、使用可能なエージェントを確認し、チャットをそれらのエージェントにルーティングするように作成されています。これをもっと分散させるにはどうすればよいですか？冗長性と稼働時間の目的で、バックエンドWindowsサービスの作業を複数のマシンに分散できるようにするにはどうすればよいですか？分散コンピューティングを念頭に置いて書き直す必要がありますか？
また、これらすべてをRackspace Cloudインスタンスでホストしていることにも注意する必要があります。つまり、それほど心配する必要はないのでしょうか。
助けてくれてありがとう！
WindowsサービスがDBサーバーのインスタンスに疎結合されていることを確認してください。これにより、Windowsサービス：DBサーバーの比率をN：1に移行できます。 DBサーバーをより堅牢にするために使用できるテクニックはたくさんありますが、それは実際にはQで得ているものではありません。
次の情報を分離します。
- Windowsサービスが機能するために必要なデータ
- その情報の即時フィードがなかった場合、Windowsサービスはどのように動作しますか
- Windowsサービスは、その情報をそれ自体の他のインスタンスとどのように共有しますか
Windowsサービスに依存しているものとその理由を特定します。これらの要素とWindowsサービスの間にロードバランサーが挿入された場合、これらの要素はどのように反応しますか？これらの要素がロードバランサーでうまく機能するためには、何を変更する必要がありますか？
Windowsサービスがダウンした場合に、既存のチャットと着信チャット要求に何が起こるかを分析し始めます。理想的には、既存のチャットで失うのはログ情報だけです。着信チャットは別のWindowsサービスインスタンスにルーティングされます。
最終的に、あなたの質問に対する答えは、レイヤーを結び付ける前提条件と要件を特定することです。これらの要件を緩和し、レイヤーをより独立させれば、アプリケーションのスケーリングと配布に取り掛かることができます。
メインラインパスでは、WindowsサービスのみがDBサーバーと直接対話することを前提としています。それが当てはまらない場合は、そのモデルを続行するか、変更するかを検討する必要があります。