Когда использовать балансировку нагрузки?

Question

Я только вхожу в более сложные части веб-разработки.Это может быть не в лучшем месте.Однако когда лучше всего получить балансировку нагрузки для веб-проекта?Я понимаю, что от хорошего дизайна / плохого дизайна зависит количество пользователей, посещающих сайт без ДЕЙСТВИТЕЛЬНОГО влияния на производительность.Тем не менее, я планирую написать новый проект, в котором потенциально может быть много пользователей, и я подумал, стоит ли мне думать о балансировке нагрузки.Мнения приветствуются;заранее спасибо!

Не следует также упоминать, что проект, скорее всего, будет asp.net (веб-формы или mvc еще не определены) с бэкэндом mongodb или pgsql (опять-таки все еще решается).

Answer 1

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

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

Stackoverflow обслуживает 10 миллионов уникальных пользователей.месяц с несколькими серверами (6 или около того).Подумайте о том, сколько запросов в день у вас было, если вы постоянно генерировали 10 HTTP-ответов в секунду в течение 8 горячих часов: 10 *3600* 8 = 288000 показов страниц в день.У вас не будет столько пользователей в ближайшее время.

И если вы это сделаете, вы оптимизируете свое приложение до 20 запросов в секунду и ядра ЦП, что означает, что вы получаете 80 запросов в секунду для товарасервер.То есть много .

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

Answer 2

Это для сайта электронной коммерции?Если это так, то реальный вопрос - «за каждый час, в течение которого сайт не работает, сколько денег вы теряете?» Если это число будет значительным, я бы сделал балансировку нагрузки приоритетной.

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

Я поддерживаю подобное решение на работе.Мы запустили четыре (раньше было восемь) веб-сайтов электронной коммерции .NET на трех серверах Windows 2k8 (поддерживаемых двумя первичными / вторичными базами данных SQL Server 2008), принимая около 1300 (комбинированных) заказов в день.Каждый сайт сбалансирован по нагрузке и поддерживается на ферме.Приятно то, что мы можем отключить один сервер для обслуживания, при этом пользователи ничего не замечают.Когда мы вернем его, мы снова включим нашу службу репликации, и наши изменения будут довольно быстро перенесены на два других сервера.

Так что да, я бы порекомендовал подумать над подобным решением.

Answer 3

Параметры, которые могут влиять друг на друга и замедлять производительность:

• Пропускная способность
• Обработка
• Синхронизация

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

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

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

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

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

ref: Веб-приложение заблокировано во время обработкидругое веб-приложение для совместного использования того же сеанса

полная замена сеанса ASP.Net

вызов страницы aspx для случайного медленного возврата изображения

Всегда онлайн

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

Answer 4

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

UPDATE

Возможно, вам придется подумать заранее, но не за счет усложнения вашего приложения. Не идите параноиком и подготовьте все к молниеносной работе «на всякий случай». Например, не беспокойтесь о сессиях - управление сессиями можно легко перенести на SQL Server в любое время, и это тот путь, который используется в LB. Кэширование также поможет, если вы столкнетесь с некоторыми узкими местами в будущем, но вам не нужно сразу его реализовывать - хороший дизайн (стабильные интерфейсы), разделение и развязка позволят добавить кэш позже. Итак, еще раз - придерживайтесь хороших практик, не закрывайте двери, но и не открывайте их все сразу.

Вы можете найти эту статью интересной.