Проблемы масштабируемости: скрытые проблемы развития системы

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

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

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

Проблемы с масштабированием

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

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

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

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

Синхронная связь - это тип связи между узлами или ресурсами; в этой ситуации всякий раз, когда один узел запрашивает что-то от другого узла, он «блокируется» (что означает, что он ждет и больше ничего не делает), пока не получит ответ. Многие из нас имели дело с синхронной связью в форме модели клиент-сервер, где клиент является «запрашивающим» информацию и ждет, пока «запрашивающий » или сервер отвечает на него.

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

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

Когда у одного узла слишком много контроля

Централизованная система может выглядеть по-разному: это может быть один сервер или машина, которые отвечают за работу системы, или (что более вероятно) это группа машин, которые сгруппированы вместе в одном физическом месте (подумайте о центре обработки данных). , работая вместе как единое целое. В обоих случаях основной контроль и расположение системы находятся в одном «центральном» месте, отсюда и идея централизованной системы.

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

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

Представьте, что наша система - это всего лишь один сервер на одной машине. Что произойдет, если наша централизованная система с одним сервером внезапно получит поток запросов? Допустим, наша односерверная система, вероятно, может обрабатывать 100 запросов в секунду; если бы он внезапно начал получать 10 000 запросов в секунду, он действительно мог бы сделать только так много. Независимо от наших настроек, при достаточном количестве запросов мы столкнемся с вычислительными ограничениями нашей централизованной системы.

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

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

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

Когда вы ждете ответного сообщения от узла

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

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

Сеть, в которой все узлы находятся в здании или на эквивалентно небольшой территории, называется локальными сетями или LAN . С другой стороны, сеть, в которой узлы могут быть гораздо более распространенными и располагаться по всей стране или на разных континентах, известна как глобальные сети или WAN. Сеть LAN идеальна для передачи меньших объемов информации между машинами, которые уже физически расположены близко друг к другу; Однако глобальная сеть лучше подходит для передачи больших объемов данных между машинами, которые физически очень удалены друг от друга.