Когда вы читаете о фреймворках (.net. ruby on rails, django, spring и т.д.), я постоянно вижу и так хорошо масштабируется.
Что означает, когда кто-то говорит, что структура "хорошо масштабируется" и что означает сказать, что структура "недостаточно масштабируется"?
Спасибо.
Когда вы планируете использование ресурсов (память, время, пространство на диске, пропускную способность сети) для одновременных пользователей, вы получаете функцию, которая описывает, как приложение работает с разными масштабными коэффициентами.
Маломасштабный - несколько пользователей - использует несколько ресурсов.
Крупномасштабное - большое количество пользователей - использует большое количество ресурсов.
Критический вопрос: "насколько близко к линейному - масштабирование?" Если он масштабируется линейно, то обслуживание 2 000 одновременно работающих пользователей в 2 раза больше, чем 1000 пользователей, и в 4 раза больше, чем 500 пользователей. Это инструмент /framework/language/platform/os, который хорошо масштабируется. Он предсказуем, и предсказание является линейным.
Если он не масштабируется линейно, то обслуживание 4000 пользователей стоит в 1000 раз больше, чем обслуживание 2000 пользователей, которые стоят 100 раз, обслуживая 500 пользователей. Это плохо масштабировалось. Что-то пошло не так, как использование выросло; он не кажется предсказуемым и не является линейным.
Это означает, что определенная структура (или не соответствует) удовлетворяет возросшему спросу, которое на нее накладывает больше пользователей. Если у вас есть приложение, написанное в VBScript, возможно, он не справится с работой с 40 000 000 пользователей Facebook.
Это сообщение в блоге объясняет некоторые проблемы масштабируемости, которые испытывал Twitter примерно год назад. Это могло бы дать более глубокое понимание ответа на ваш вопрос.
Иногда недостаток масштабируемости используется для очернения языка или фреймворка, поэтому следите за этим. Придерживайтесь исследований, которые показывают реальные показатели. Это относится и к моему примеру VBScript в предыдущем абзаце.
Если каркас или приложение хорошо масштабируются, это означает, что он может обрабатывать большие нагрузки. Поскольку ваш сайт становится все более популярным среди большего числа посетителей и больше обращений в день, структура, которая хорошо масштабируется, будет обрабатывать большую нагрузку так же, как она обрабатывает меньшую нагрузку. Рамка, которая хорошо масштабируется, будет действовать одинаково, когда она получает 200 000 обращений в час, как это происходит, когда она получает 1 удар в час. Не только удары, но и развертывание на нескольких серверах, возможно, за балансировкой нагрузки, возможно, с несколькими разными серверами баз данных. Рамка, которая хорошо масштабируется, может хорошо справляться с этими растущими требованиями.
Например, twitter взорвался почти в одночасье в прошлом году. Он был разработан с использованием Ruby On Rails, и он горячо показал в продолжающихся дискуссиях о том, масштабируется ли Rails или нет.
заменить фразу "расширение ручки" для "шкалы"
В моем сознании есть несколько элементов. Первое - это очевидное масштабирование производительности. Может ли ваша инфраструктура использоваться для создания высокопроизводительной системы с высокой пропускной способностью или может использоваться только для создания небольших приложений. Будет ли он масштабироваться по вертикали на оборудовании (например, параллельные библиотеки) и будет ли он масштабироваться горизонтально (например, веб-фермы).
Во-вторых, он может масштабироваться для более крупных команд или предприятия. То есть, хорошо ли это работает с большими базами кода? Крупные команды разработчиков? Имеет ли он хорошую поддержку инструмента? Насколько легко развертывать? Можете ли вы развернуть десятки, сотни или даже тысячи пользователей? На всем пути до этого легко нанимать людей, обладающих этим навыком. Подумайте о том, чтобы попытаться собрать команду разработчиков из 20 или 50 человек, которые работают над этой структурой. Было бы легко или почти невозможно?
ИМХО, говоря, что структура "хорошо масштабируется" обычно означает, что кто-то в цепочке слуха смог использовать ее для обработки большого объема.
В параллельном программировании масштабируемость обычно используется для описания того, как работает алгоритм, когда он распараллелен. Алгоритм, который имеет ускорение 1:1, является редким зверьком, но удваивает производительность в два раза по сравнению с аппаратным/процессорным, тройным в три раза аппаратным/процессорным и т.д....
По моему опыту практически любые рамки могут быть сделаны для масштабирования, учитывая достаточный опыт.
Чем проще структура, тем больше вероятность того, что разработчик с недостаточной квалификацией столкнется с проблемами масштабируемости.
Это означает, что какая-то уважаемая компания делает с ней что-то серьезное и не имеет с ней никаких проблем.
Масштабирование означает, как легко удовлетворить спрос, используя больше аппаратного обеспечения.
Пример. У вас есть сайт, написанный на каком-то языке, который получает 1000 посещений в день. Вы попадаете в какой-то известный магазин, и число пользователей растет. Внезапно у вас 1000000 посещений в день, что в 1000 раз больше. Если вы можете использовать только 1000 серверов для удовлетворения растущей потребности в ресурсах, ваш сайт будет хорошо масштабироваться. Если, с другой стороны, вы добавляете 2000 серверов, но все же пользователи не могут подключиться, потому что ваша база данных может обрабатывать только 1000 запросов в день, чем ваш сайт плохо масштабируется.