Что такое масштабирование?
Я слышал, что люди говорят, что они создали масштабируемое веб-приложение.
-
Что действительно масштабируется?
-
Что могут сделать разработчики, чтобы сделать их приложение масштабируемым?
-
Каковы факторы, которые требуют разработчики при масштабировании?
-
Любые советы и рекомендации по масштабированию веб-приложений с помощью asp.net и sql-сервера...
Ответы
Ответ 1
Что действительно масштабируется?
Масштабирование - это увеличение емкости и/или использования вашего приложения.
Что делают разработчики, чтобы сделать их приложение масштабируемым?
Позволяет своим приложениям масштабироваться вертикально или горизонтально.
Горизонтальное масштабирование - это параллельное выполнение.
Вертикальное масштабирование - это ускорение работы. Обычно это означает более мощное оборудование.
Часто, когда люди говорят о горизонтальной масштабируемости, идеал должен иметь (почти) линейную масштабируемость. Это означает, что если один производственный блок объемом $5 тыс. Может обрабатывать 2000 одновременных пользователей, тогда добавление еще 4 должно обрабатывать 10 000 одновременных пользователей. Чем ближе к этой цифре, тем лучше.
Идеально подходит для высокомасштабируемых приложений - иметь почти неограниченную почти линейную горизонтальную масштабируемость, чтобы вы могли просто подключить еще один ящик, и ваша емкость увеличивается на ожидаемую сумму с небольшим или никаким уменьшающимся возвратом.
В идеале избыточность является частью уравнения, но обычно это отдельная проблема.
Родитель-плакат для такой масштабируемости, конечно же, Google.
Каковы факторы, которые задумываются разработчиками при масштабировании?
- Сколько планируется масштаб? Нет смысла тратить время и деньги на проблему, которой у вас никогда не будет;
- Возможно ли и/или экономично масштабироваться по вертикали? Это предпочтительный вариант, поскольку он обычно намного, намного дешевле (в краткосрочной перспективе);
- Стоит ли (часто значительная) стоимость, чтобы ваше приложение масштабировалось по горизонтали? Распространенные/многопоточные приложения значительно сложнее и дороже писать.
Любые советы и рекомендации по масштабированию веб-приложений...
Да:
- Не беспокойтесь о проблемах, которые у вас никогда не возникнут;
- Не волнуйся о проблемах, которые вряд ли будут иметь. Скорее всего, все изменится задолго до того, как вы их найдете;
- Не бойтесь выбросить код и начать все заново. Автоматизация тестов делает это намного проще; и
- Подумайте о том, что время разработчика дорого.
(4) является ключевым моментом. Возможно, у вас плохо написанное приложение, которое потребует 20 000 долларов США для аппаратного обеспечения. В настоящее время $20 000 покупает много энергии (64 + ГБ оперативной памяти, 4 четырехъядерных процессора и т.д.), Возможно, более 99% людей когда-либо понадобятся. Разве дешевле просто сделать это или потратить 6 месяцев на переписывание и отладку нового приложения, чтобы сделать его быстрее?
Легко первый вариант.
Итак, я добавлю еще один элемент в свой список: быть прагматичным.
Ответ 2
Мое определение 2c "масштабируемое" - это система, чья пропускная способность растет линейно (или, по крайней мере, предсказуемо) с ресурсами. Добавьте машину и получите пропускную способность 2x. Добавьте еще одну машину и получите пропускную способность 3x. Или перейдите от 2p-машины к машине 4p и получите 2x пропускную способность.
Он редко работает линейно, но хорошо продуманная система может приближаться к линейной масштабируемости. Добавьте $1 от HW и получите дополнительную производительность на 1 единицу.
Это важно в веб-приложениях, потому что потенциальная пользовательская база - ~ 1b человек.
Конфликт для ресурсов в приложении, когда он подвергается множеству параллельных запросов, является причиной страдания. Конечным результатом такой системы является то, что независимо от того, сколько аппаратного обеспечения вы используете, вы не сможете добиться большей пропускной способности. Он "заканчивается". Кривая HW-cost по сравнению с производительностью асимптотическая.
Например, если в каждой веб-транзакции или взаимодействии должна быть обновлена одна встроенная в обложке структура приложения, эта структура станет узким местом и ограничит масштабируемость приложения. Добавление большего количества процессоров или больше памяти или (может быть) больше машин не поможет увеличить пропускную способность - у вас все еще будут запросы, выстраивающиеся в очередь для блокировки этой структуры.
Часто в транзакционном приложении узким местом является база данных или конкретная таблица в базе данных.
Ответ 3
Что действительно масштабируется?
Масштабирование означает увеличение использования и объема данных, и в идеале реализация должна поддерживаться.
Что разработчики делают для масштабирования своего приложения?
Используйте базу данных, но кешируйте как можно больше, в то же время, используя пользовательский интерфейс (возможно, в сеансе).
Любые советы и рекомендации по масштабированию веб-приложений...
Есть много, но это зависит от реализации. Какие языки (языки программирования), какая база данных и т.д. Вопрос необходимо уточнить.
Ответ 4
Масштабируемость означает, что ваше приложение подготовлено для будущего роста (и может обрабатывать). Он может обрабатывать более высокий трафик, больше активности и т.д. Создание вашего сайта более масштабируемым может повлечь за собой различные вещи. Вы можете работать над хранением большего количества кеша, а не запрашивать базу данных без необходимости. Это может привести к написанию более качественных запросов, к минимуму связей и освобождению ресурсов.
Ресурсы:
Ответ 5
Книги были написаны по этой теме. Отличная программа, которая ориентирована на интернет-приложения, но описывает принципы и методы, которые могут быть применены в любых усилиях по разработке: Масштабируемые интернет-архитектуры
Ответ 6
Могу ли я предложить определение "User-Centric",
Масштабируемые приложения обеспечивают согласованный уровень опыта для каждого пользователя независимо от количества пользователей.
Для веб-приложений это означает 24/7 в любой точке мира. Однако, учитывая разнообразие доступной пропускной способности по всему миру и отсутствие контроля над его производительностью и доступностью, мы можем переопределить его следующим образом:
Масштабируемые веб-приложения обеспечивают согласованное время отклика, измеренное на используемом TCP-порту сервера, независимо от количества запросов.
Чтобы достичь этого, разработчик должен избегать или удалять все бутылки с производительностью. В настоящее время наиболее сложной проблемой является масштабируемость распределенных систем РСУБД.