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