Design Decision - масштабирование архитектуры веб-приложений

Question

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

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

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

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

Это лучший подход? Любые предложения будут великолепны ..

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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