WCF - архитектура решения

Question

Я работаю над проектом, в котором сервис WCF будет использоваться приложениями iOS.Число ожидаемых посещений веб-сервера в любой данный момент времени составляет около 900-1000.Каждый запрос может занять 1-2 секунды.Такое же количество запросов ожидается каждую секунду 24/7.

Это мой план:

1. Записать WCF RESTful-сервис (контекстный режим экземпляра будет percall).
2. Запрос / ответ будет в Json.
3. Есть некоторая информация, которую необходимо сохранить на сервере - эта информация фактически получена из другой удаленной системы - которая распределяется между всеми запросами.Поскольку использование базы данных может не быть хорошей идеей (время отклика очень важно - максимум 2 секунды - это максимум, которое клиент может подождать), было бы хорошо сохранить ее в памяти сервера (скажем, статический словарь - предположим, что этот словарь будетколлекция из 150000 объектов - каждый объект состоит из 5-7 типов строк и их ключей).Я знаю, что это изменчиво!
4. Каждый запрос будет порождать новый поток (используя Threading.Timers) для некоторой очистки - этот поток также будет выполнять чтение / запись базы данных.

Теперь, если через некоторое время появится балансировщик нагрузки, хранимые в памяти объекты не могут быть разделены между запросами, направляемыми через другой узел. Есть идеи?

Я надеюсь, что вы, гуру, могли бы помочь мне, поделившись своими комментариями / предложениями по всей архитектуре, регулированию WCF, сохранению состояния объекта и т. Д. Просьба также предоставить некоторые указатели на необходимое оборудование.Мы планируем использовать сервер Windows 2008 Enterprise Edition, базу данных IIS и SQL Server 2008 Std Edition.

Добавление дополнительной информации № 3: Как я уже сказал, мы получаем некоторую информацию для службы из удаленной системы.На веб-сервере, где размещен WCF, будет установлен клиент удаленной системы, и WCF ссылается на одну из этих клиентских библиотек для получения информации в виде хеш-таблицы (этот метод возвращает хеш-таблицу - около 150000 объектовбыть там в этой коллекции).Вы бы предложили записать эту информацию в базу данных, и запросы iOS (каждую секунду), которые обращаются к службе, получают эту информацию непосредственно из базы данных?Будет ли он работать лучше, чем потреблять напрямую из этой хеш-таблицы, если он сделан статическим?

Answer 1

Поскольку вы используете Windows Server 2008, я бы определенно использовал кэш фабрики приложений Windows Server для хранения вашего состояния:

http://msdn.microsoft.com/en-us/library/ff383813.aspx

Оно бесплатное, хорошо поддерживается и интегрированои совместим (более или менее) API с кэш-памятью приложений Windows Azure, если вы каждый раз переводите свой сервис в Azure.В нашей компании (отказ от ответственности: не моя команда) мы использовали MemCache, но перешли на App Fabirc Cache и не жалеем об этом.

Answer 2

Позвольте мне высказать некоторые комментарии / предложения, основанные на моем опыте обслуживания аналогичной суммы или запроса в рамках WCF, 3,5 в те времена.

Я не согласен с # 3.Использование базы данных здесь является правильным решением.Чтобы учесть время отклика, внедрите кэширование и, возможно, cache dependency, чтобы синхронизировать данные во всех экземплярах (при условии, что вы сбалансированы по нагрузке) (также см. Выше предложенную / приведенную ниже App Fabric).В реальных сценариях изменения данных часто происходят, и вы должны минимизировать влияние.

Мы использовали аппаратное и программное обеспечение Barracuda для обеспечения масштабируемости, насколько я могу судить.

Рассмотрим индексирование keys/values с Lucene, если применимо.Lucene обеспечивает отличную производительность при чтении / записи.Не используйте его для хранения всех ваших данных, прочитайте их.Спасатель при правильном использовании.Обратите внимание, что это может быть сложно реализовать в среде с балансировкой нагрузки.

По сути, кэширование может быть единственным необходимым изменением в вашей архитектуре.