Стратегии масштабирования уровней обслуживания в .NET

Question

Я работаю над веб-продуктом, который состоит из множества модульных веб-приложений. Для конечного пользователя оно представляется одним приложением, хотя различные компоненты разбиты на собственные приложения.

Отчасти это объясняется тем, что его можно легко масштабировать по горизонтали между несколькими серверами приложений.

Чтобы упростить горизонтальное масштабирование уровня данных, мы планируем использовать слой веб-службы перед базой данных. Этот слой можно масштабировать до N машин, и каждый его экземпляр будет обрабатывать кэширование индивидуально.

Идея состоит в том, что приложение будет вызывать балансировщик нагрузки уровня обслуживания, который будет назначать вызов экземпляру службы, затем использовать его кэш для возврата данных или подключаться к базе данных и запрашивать данные. , Похоже, что это было бы самым простым перспективным решением для масштабирования без необходимости значительного изменения кода приложения.

[N Amount of Databases]
         |
         \/
[Service Tier X N amount of Machines]
         |
         \/
[Application Tier X n amount of Machines]

Однако возникает несколько вопросов, я хотел бы сохранить сеанс пользователя на уровне обслуживания, чтобы каждое приложение просто аутентифицировалось с помощью токена, однако я не уверен, как я буду поддерживать данные сеанса на всех машинах обслуживания. без единой точки отказа.

Есть идеи, как это осуществить? Есть еще идеи по архитектуре? У кого-нибудь еще был проект создания сайта, который потенциально мог бы обрабатывать миллионы посещений в день?

РЕДАКТИРОВАТЬ: Даже не идея? (

Answer 1

вы описали идеальный вариант использования механизма распределенного кэширования, такого как memcached (http://www.danga.com/memcached) или предстоящий проект MS Velocity (http://code.msdn.microsoft.com/velocity).

)

В описываемой вами ситуации, когда у вас растет число экземпляров уровня обслуживания, каждый из которых выполняет свое локальное кэширование, полезность вашего кэша уменьшается с каждым новым полем, поскольку каждый отдельный экземпляр должен извлекать те же данные из базы данных, чтобы заполнить его локальный кеш, даже если к тем же данным только что обращался другой экземпляр уровня обслуживания. При использовании memcached или Velocity механизм кэширования будет разумно объединять неиспользуемую оперативную память на всех ваших серверах в единый кеш для всех установок уровня обслуживания. Таким образом, только первый экземпляр уровня обслуживания для доступа к части данных должен будет использовать базу данных, а последующие обращения к другим экземплярам уровня обслуживания будут извлекать те же данные из кэша.

Наличие этого также отвечает на вопрос о сеансе пользователя, поскольку вы можете легко использовать этот же кеш для хранения значений состояния для сеансов пользователя, и все ваши экземпляры уровня обслуживания будут иметь доступ к этой же информации.

Надеюсь, это поможет!

Адам