Режим ожидания сеанса WCF Хостинг Выпуск

Question

У меня возникла ситуация с хостингом WCF в режиме Session Instancing. Я инкапсулирую фактическую ситуацию и предлагаю пример для ее репликации ... как показано ниже.

Услуга, которая будет размещаться, - «MyService». Я использую службу Windows, чтобы разместить ее ... с конечной точкой http.
Он должен поддерживать 500 одновременных сеансов. (Singleton & Percall не может быть выполнен, потому что контракт основан на рабочем потоке ... Вход ... Function1, Function2, Logout ..)
У меня есть 4 сервера с аппаратной возможностью поддержки 200 одновременных сеансов.
Таким образом, я настроил службу на одном сервере в качестве маршрутизатора (ServiceHost S = новый ServiceHost (RouterService)) с хостинговым путем, таким как «http: // myserver/MyService». Я установил простой механизм балансировки нагрузки и применил таблицу Router для перенаправления входящих запросов на другие три сервера, на которых размещены фактические копии службы ... («http: // myserver/MyService1», «http: // myserver/MyService2 "," http: // myserver/MyService3 ")

Он по-прежнему не работает ... Как только хиты превышают 200 ... ошибка связи начинается ... Я полагаю, потому что, когда производится 500 одновременных вызовов, то маршрутизатор (возможность 200) также должен оставаться подключенным к клиенту вместе с фактическим сервером службы ... (в режиме вызова сеанса). Я считаю, что правильно?

Мой вопрос ...

1) Является ли мой подход правильный или недостатки от концепции ... Должен ли я попросить команду Hardware настроить NLB ...
2) Если мы перепроектировать контракт специально чтобы запросы могли каким-то образом быть сделаны PerCall ...
3) Кто-то предположил, что такие системы должны размещаться в облаке (Windows Azure) ... нужно будет посмотреть на затраты, связанные ... но это правильно .. .
4) Каковы наилучшие практики, связанные с хостингом WCF для обработки вызовов на основе сеанса.

Я понимаю, что мой вопрос сложный и не было бы одного «правильного» ответа ... но любая помощь и понимание будут действительно оценены.

Благодаря

Answer 1

«Должен ли я попросить команду оборудования настроить NLB ...» по вашему адресу? & «Липкий кластер IP» от Shiraz - это самый близкий, который можно разместить для размещения данного скнеро.

Дело в том, что сеансы WCF связаны с транспортом. Если мы не можем хранить эти «сеансы» на государственном сервере/db, как традиционный aspnet.

WCF4.0 придумал новые привязки, такие как NetTcpContextBinding, BasicHttpContextBinding, WSHttpContextBinding, которые могут помочь в создании контекста при перекрестной компьютерной среде. Но у меня нет знаний о реализации производства, чтобы предоставить пример.

This статья должна помочь вам узнать больше ...

Answer 2

Есть три отдельных, но связанных с этим вопросов здесь:

• Ваша конструкция требует, чтобы вы поддерживать состояние между вызовами
• Вы зависимы от получения к тому же серверу каждый раз (так как вы состояние хранилища в памяти)
• У вас есть ограничение на 200 соединений на сервер

Решение, в котором вы зависите от возврата на тот же сервер, не будет работать (хорошо) на Windows Azure.

Вы можете реализовать Sticky IP-кластер, который бы разрешил большинство ваших проблем, но это не гарантировало бы, что на одном сервере не более 200 подключений. По большей части это было бы хорошо.

Вы можете сохранить кеш в Appfabric Cache, тогда неважно, на какой сервер вы вернулись.

Вы можете переделать систему так, чтобы все состояние хранилось в базе данных.