Масштабирование

Куб масштабирования

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

Масштабирование по оси X (горизонтальное масштабирование)

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

MVC

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

Масштабирование по оси Y (функциональная декомпозиция)

Масштабирование по оси Y также называется вертикальным масштабированием, которое включает в себя любое масштабирование уровня ресурса. Любая система DBaaS или Hadoop может считаться масштабируемой по оси Y. При таком типе масштабирования пользовательский запрос перенаправляется и ограничивается путем реализации некоторой логики.

Давайте рассмотрим Facebook в качестве примера. Facebook должен обрабатывать 1,79 миллиона пользователей в секунду; следовательно, управление трафиком является огромной ответственностью сетевых инженеров Facebook. Чтобы избежать любой опасности, они используют масштабирование по оси Y, которое включает запуск нескольких серверов с одним и тем же приложением одновременно. Теперь, чтобы контролировать этот огромный уровень трафика, Facebook перенаправляет весь трафик из одного региона на конкретный сервер, как показано на рисунке. Эта передача трафика в зависимости от региона называется балансировкой нагрузки на архитектурном языке.

MVC

Этот метод разделения ресурсов на небольшие независимые бизнес-единицы известен как масштабирование по оси Y.

Масштабирование по оси Z (разбиение данных)

Масштабирование по осям X и Y гораздо проще для понимания. Однако одно приложение также можно масштабировать на бизнес-уровне, которое называется масштабированием по оси Z. Ниже приведен пример масштабирования приложения службы такси в различных вертикалях бизнес-единиц.

Стоимость

Правильное масштабирование программного обеспечения снизит стоимость обслуживания.

Производительность.

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

Распределение нагрузки

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

Повторное использование

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

Эволюция решения и микросервисы

Итак, эволюция типичного ИТ решения может развиваться по следующему пути:

Стартап MVP решение, чья цель в основном попробовать рынок и решить, подходит ли вообще этот концепт. Здесь не нужны сложные технологии, продвинутые интерфейсы и высоконагруженные сервисы. На этом этапе ценится прежде всего минимизация затрат и скорость вывода на рынок. Иной раз MVP проваливается уже на стадии опроса целевых групп. Стоит ли в этом случае сразу строить решение на микросервисах? Мой ответ — нет, не стоит даже думать об этом. Пока вы будете продумывать архитектуру и налаживать инфраструктуру уйдёт время. А это для стартапа самый ценный ресурс. Да и ключевой профит-фактор микросервисов — параллельную разработку, с командой стартапа реализовать затруднительно.
Новорождённое монолит решение. Архитектура приложения не выверена до конца, неизвестны все внутренние и внешние сервисы, которые будут задействованы. Непонятны до конца цели и задачи конечных потребителей. Неясна стратегия развития структуры данных и функциональности. Определенно не стоит перескакивать на рельсы микросервисов и здесь, если только ваша команда не состоит из профи, щёлкающих микросервисы как орешки.
Давно существующее на рынке и стабильное монолит-решение, вся функциональность которого выверена от и до, возникающие проблемы решаются грамотным рефакторингом и развитие подразумевается плавное, в едином концепте, без конкуренции между функциональными блоками. Стоит? Возможно, стоит задуматься, если цель — интегрироваться с внешними сервисами, увеличить нагрузку на существующие функциональные блоки, обеспечить их независимое развитие и вывод на рынок, если вы хотите сэкономить на технологическом стеке или улучшить характеристики решения за счёт переиспользования компонентов. Но при этом вы должны быть готовы усилить команду нужными специалистами и потратить время на грамотное разбиение монолита на независимые или очень слабосвязанные функциональные блоки, а затем на вывод этих блоков из монолита в качестве отдельных сервисов. Это определённо будет стоить дополнительных ресурсов, а также времени на обучение команды и поиск подходящих технологий.
Многоуровневый монолит в концепции DDD. Функциональность логически сгруппирована в изолированные или слабосвязанные блоки, которые, однако, все еще находятся внутри монолитной структуры, логика отделена от инфраструктуры. Это хорошая стартовая точка для перехода на микросервисы.
Распределенный монолит. У команды разработки почти получилось раздробить монолит, но что-то явно пошло не так. Сервисы слишком сильно связаны друг с другом, присутствуют явные и неявные зависимости, страдает бизнес, поскольку выдвигает требования к одному модулю, а оказывается что нужно перерабатывать несколько, эффект изменений трудно отследить, тестирование и разворачивание требуют отдельных нетривиальных подходов. Вот здесь задумайтесь. Нужны ли вам микросервисы? Действительно ли есть проблемы, которые нельзя закрыть изначально монолитным решением? Если нужны, то следует собрать эту пирамидку заново, но уже в правильном порядке.
SOA решение. Не стоит воспринимать микросервисы как следующий шаг эволюции SOA. Надо понимать, что основное отличие шины от канала обмена сообщениями между сервисами состоит в том, что именно шина несёт на себе значительную часть логики преобразования данных и их оркестрации. Канал обмена сообщениями между микросервисами, в свою очередь, должен быть максимально надёжным и “тупым”. Его цель — передать сообщение. Внедрение микросервисов в такие решения может очень дорого обойтись, поскольку якобы “независимые” модули могут быть сильносвязанными через логику шины, и простой заменой этой логики на агрегирующие паттерны не обойтись. К тому же в существующих SOA решениях в основном используются неоднородные технологии и конструкты, которые тяжело поддаются адаптации. Стоит ли вообще задумываться о таком переходе? Как правило, нет. Скорее всего, выбор SOA был обусловлен сложностью и разнородностью приложений, с которыми необходимо интегрироваться, масштабом приложения, необходимостью обеспечить согласование данных и сложную логику их преобразования. И в этом случае он был сделан правильно. О микросервисах, как об альтернативе, стоит задуматься только, если основная часть решения устарела, отпала необходимость интегрироваться с тяжеловесными приложениями, стоит вопрос об избавлении от легаси-кода и переходу к более простым веб-решениям, нет необходимости поддерживать высокий уровень абстракции и согласования данных и при этом критичны скорость разработки отдельных модулей, либо необходимо обеспечить автономность работы отдельных команд.
Монструозный монолит. Монолит полный легаси-кода и построенный на заплатках. Монолит, который развивался так давно, что превратился в огромную и не поддающуюся изменениям структуру. Монолит целиком состоящий из спагетти-кода. Это, пожалуй, единственный случай когда стоит воспользоваться лозунгом Интернационала и разрушить все до основания, тщательно вымести обломки и на развалинах построить новое решение. Возможно, на микросервисах.

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

Когда же стоит выбирать микросервисы?

Если:

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

то возможно вам стоит задуматься о реализации решения на микросервисах.

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

Digitable/Масштабирование