1

セッションインスタンス化モードでのWCFのホスティングに関する状況に直面しています。実際の状況をカプセル化し、それを複製する例を提案しています...以下のように。

ホストされるサービスは「MyService」です。私はそれをホストするためにWindowsサービスを使用しています..httpエンドポイントで。
500の同時セッションをサポートする必要があります（契約はワークフローベースであるため、シングルトンとパーコールは実行できません...ログイン...機能1、機能2、ログアウト..）
それぞれ200の同時セッションをサポートするハードウェア機能を備えた4台のサーバーがありますセッション。
そこで、1台のサーバーでサービスを「http：// myserver / MyService」などのホスティングパスを持つルーター（ServiceHost S = new ServiceHost（RouterService））として構成しました。単純な負荷分散メカニズムを設定し、ルーターテーブルを適用して、実際のサービスコピーがホストされている他の3つのサーバーに着信要求をリダイレクトしました...（ "http：// myserver / MyService1"、 "http：// myserver / MyService2 "、" http：

それはまだ機能していません...ヒットが200を超えるとすぐに...通信エラーが始まります...500の同時呼び出しが行われると、ルーター（機能200）もクライアントへの接続を維持する必要があるためだと思います実際のサービスサーバーと一緒に...（セッションコールモードで）..私の考えは正しいですか？

私の質問は...

1）私のアプローチは正しいか概念に欠陥がありますか...ハードウェアチームにNLBを設定するように依頼する必要があります...
2）要求が何らかの形でPerCallにできるように、契約を具体的に再設計する必要があります...
3）誰かそのようなシステムはクラウド（Windows Azure）でホストする必要があることを提案しました...関連するコストを調べる必要があります...しかしそれは正しいです...
4）セッションベースの呼び出しを処理するためにWCFをホストする際に必要な最良のプラクティスは何ですか。

私の質問は複雑で、「正しい」答えは1つではないことを理解しています...しかし、どんな助けや洞察も本当にありがたいです。

ありがとう

4

2 に答える 2

0

ここには、3つの別個の、しかし関連する問題があります。

  • 設計では、呼び出し間で状態を維持する必要があります
  • 毎回同じサーバーにアクセスすることに依存しています（状態をメモリに保存するため）
  • サーバーあたりの接続数は200に制限されています

同じサーバーに戻ることに依存しているソリューションは、Windows Azureでは（うまく）機能しません。

スティッキーIPクラスターを実装して、ほとんどの問題を解決することはできますが、1つのサーバーに200を超える接続が存在することを保証するものではありません。ほとんどの場合、これは問題ありません。

キャッシュをAppfabricCacheに保存すると、どのサーバーに戻ったかは関係ありません。

すべての状態がデータベースに保存されるように、システムを再設計できます。

于 2012-06-16T15:55:21.820 に答える
0

「ハードウェアチームにNLBのセットアップを依頼する必要がありますか...」とShirazの「StickyIPcluster」は、特定のscnerioをホストするのに最も近いものです。

重要なのは、WCFセッションはトランスポートベースであるため、これらの「セッション」を従来のaspnetのように状態サーバー/dbに保存することはできません。

WCF4.0は、NetTcpContextBinding、BasicHttpContextBinding、WSHttpContextBindingなどの新しいバインディングを考案しました。これは、クロスマシン環境でのコンテキストの再作成に役立ちます。しかし、例を提供するための本番実装の知識はありません。

この記事はあなたがもっと知るのに役立つはずです...

于 2012-06-27T04:35:19.723 に答える