Решение о разработке - масштабирование архитектуры веб-приложения

Question

Этот вопрос касается дизайнерского решения. В настоящее время я работаю над веб-проектом, в котором будут 40K пользователей, и через пару месяцев ожидается рост 50M пользователей (хотя и не одновременных пользователей). Я хотел бы иметь архитектуру, которую можно легко масштабировать без особых усилий.

Чтобы объяснить, я хотел бы использовать тривиальный сценарий. Допустим, что пользовательские объекты и службы, такие как CreateUser, AuthenticateUser и т. Д., Представляют собой простой метод для вызовов для контроллеров страниц. Но как только рост трафика увеличивается, например, аутентификация пользователя (или таких служб, связанных с пользовательскими объектами), должна быть перенесена на другой внутренний сервер для распространения нагрузки. Но в то же время использование вызовов RPC по сети, когда пользователь подсчитывает 40K, станет излишним.

Мое предложение состояло в том, чтобы использовать IPC изначально, и когда нам нужно масштабировать, мы можем взаимно переключиться на вызовы RPC на основе TCP, чтобы он мог легко масштабироваться. Например, я имею в виду System.IO.Pipes.NamedPipeStreamServer для начала и перейдите к TcpListener позже.

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

Это лучший подход? Любые предложения были бы замечательными.

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

Answer 1

Если вы планируете делать это (если я правильно прочитаю), выполните проверку подлинности и авторизации на центральный сервер, то я думаю, что вы найдете проблемы с масштабируемостью, если попытаетесь это сделать с именованными каналами или даже низкоуровневыми сокетами TCP. Нет причин, по которым вы не можете связаться с этими внутренними серверами через обычные веб-службы или даже с помощью служб WCF на основе TCP-канала.

Причина, по которой я должен идти по этому маршруту, заключается в том, что вызов веб-служб без учета состояния (ASMX или WCF) позволит вам создать ваш сервер аутентификации и авторизации (аутентификация и авторизация), а также ваш сервер управления пользователями (createuser , и т. д.) на ферме. Таким образом, по мере того, как ваши обращения к этим услугам увеличиваются, вы можете масштабировать количество серверов, отвечающих на эти вызовы, без изменения кода клиента.

Answer 2

По моему опыту всегда есть напряжение между «вам оно не нужно сейчас, так что не тратьте на него усилий» и «вот драконы».

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

Моя общая рекомендация - атаковать риск рано. Таким образом, в этом случае вы намерены в будущем использовать технологию удаленного доступа для разгрузки какой-либо работы. Добавление этого нового (в системе) технология будет (по крайней мере) два воздействия:

1. Новые режимы отказа
2. Увеличение латентности

Ох, и это (Admitedly маловероятно) вероятность того, что удаленная стратегия не работает!Вы не можете видеть преимущества масштабирования, которые вы ожидаете. Производительность заведомо неинтуитивна.

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

Answer 3

В одном из моих проектов для индустрии туризма (около 1 м хитов в день) у нас была отдельная ферма серверов auth. В то время было около четырех серверов с балансировкой нагрузки. Наш бизнес-уровень называется веб-службой аутентификации (asmx), передающей учетные данные пользователя и получая результаты xml. Если число пользователей увеличится, мы продолжим расширять ферму auth. ИМХО, использующее веб-службы через http (в интранете), дает больше преимуществ по производительности, чем TCP.