Если вы решили создать крупный проект, перед началом проектирования подумайте о масштабировании. Это позволит избежать многих проблем. Если вы планируете разработать крупный проект, тогда вам обязательно нужно подумать о правильном масштабировании. Этот вопрос лучше решать перед началом проектирования, так как изменения в уже готовом проекте потребует намного больше усилий.
Масштабирование веб приложения – это способность проекта увеличивать свои возможности за счёт повышения количества функциональных модулей, которые выполняют одни и те же задачи. Как правило, о масштабировании начинают думать когда текущая система не выдерживает существующие нагрузки. Преимущественно это крупные проекты такие как социальные сети типа Вконтакте или создание криптовалютной биржи, которые имеют высокие нагрузки. Самое простое решение – повысить мощность сервера. Для этого достаточно заказать обновление железа у провайдера.
Это позволит кратковременно решить проблему, но в глобальном смысле, этого недостаточно. Реконструкция существующего сайта требует много ресурсов и усилий, потому, компания Merehead, рекомендует перед началом разработки обдумать варианты масштабироваться. Это позволит построить стабильную и гибкое веб приложение. Каждый сайт имеет стандартную архитектура взаимодействия, но многие компании предпочитают разделять проект на несколько основных модулей. В основном это: front-end, back-end и database.
Это дает огромное преимущество в дальнейшей разработке. Благодаря такой архитектуре, упрощается навигация между файлами и система становится намного гибче для будущего масштабирования. Кроме того желательно использовать лучшие языки программирования в 2020 году, которые обеспечивают необходимую производительность.
На втором этапе можно сделать масштабирование back-end части. Это также позволит существенно повысить скорость работы. Как правило front-end, остается на том же сервере, так как он использует минимальную нагрузку и его разделение не приведет к столь существенному повышению производительности. Кроме того можно вынести на отдельный сервер хранилище файлов, это также позволить снизить нагрузку на основной сервер.
Как правило крупные проекты (такие как крупные интернет-магазины) имеют сильную back-end часть. На нее возложена обработка сложных вычислений. Очень часто back-end является причиной медленной работы веб приложения. В процессе разработки сложных проектов, следует уделить внимание оптимизации запросов и рациональном использовании производительности сервера. Если Ваш проект имеет хорошо разработанную back-end часть, но нагрузка продолжает расти и это приводит к нестабильной работе, мы рекомендуем сделать масштабировать.
Если нагрузка временная, можно увеличить мощность сервера. В ином случае следует разделить back-end на несколько серверов. Достаточно перенести часть скриптов и модулей на второй сервер. После этого, необходимо распределить запросы равномерно между ними. Это даст возможность снять нагрузку с основного сервера и перенаправить на другие машины. В основном это делается на front-end стороне.
Если база данных имеет огромное количество данных и нагружает отдельный сервер, можно масштабировать данный кластер. Существует два подхода масштабирования базы данных:
Если Вы имеете не большую базу данных, но много сложных вычислений, которые нагружают сервер, рекомендуем разделить именно процесс вычислений. Таким образом, каждый сервер будет иметь полную копию базы данных и выполнять только свой ограниченный пул работы. Это более сложная задача, которая требует больше усилий для реализации. В первую очередь это связано с синхронизацией данных между серверами, чтобы держать каждую копию базы данных актуальной. Существует несколько походов для решение этой проблемы:
Если у Вас не много вычислений, но база данных состоит из множество записей (часто такие проблемы имеют крупные e-commerce сайты), в этом случае Вам нужно разделить базу данных на несколько серверов. Каждый сервер будет иметь часть данных и взаимодействовать с другими серверами. Существует несколько схем распределения данных:
Вертикальное (vertical partitioning). Суть данной схемы заключается в том что некоторые таблицы перемещаются на другой сервер. В таком случае теряется гибкость, так как нет возможности сделать сложные SQL запросы. Если провести правильное и логическое разделение базы, этот недостаток можно свести к минимуму.
Горизонтальное (horizontal partitioning). В данной схеме база данных хранить одну и туже таблицу, только с разными частями. Например, у Вас есть таблица с 100 миллионами записями пользователей. Мы ее раздели на 2 сервера, на одном сервере будут хранится записи только мужчины, а на втором – только женщины. В этом случае необходимо внести изменения в back-end чтобы правильно распределить запросы между серверами.
Как только ваша система будет имеет несколько серверов, перед Вами появится вопрос правильного распределение запросов между серверами. Существует два метода распределения запросов (балансировки):
Балансирующий узел. Это простой методы распределение нагрузки между запросами. Клиент взаимодействует с основным сервером, который самостоятельно определяет к какому серверу обратится для обработки запроса. Основная проблема состоит в надежности данного метода, так как в одной точке находится вся цепная логика. Если этот узел выйдет из стоя, это остановит работу всей системы.
Балансировка на стороне клиента. Более безопасный и более гибкий метод распределения запросов между серверами. Идея заключается в получении параметров пользователя. После этого, на основе этих данных, происходит автоматическое распределение запросов. Очень часто для этого используются данные IP и страны пользователя. Зная это, происходит автоматическое взаимодействие пользователя с нужными серверами. Таким подходом пользуются крупные компании, например Facebook.