Планирование Архитектуры Проекта

Развернуть все на одном сервере, сэкономить на инфраструктуре, потратить сэкономленный бюджет на продвижение проекта — все это работает еще до того, как проект станет посещаемым.

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

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

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

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

Разобьем весь процесс на две независимые части: клиентский запрос и обработка клиентского запроса на стороне приложения.

Таким образом, DNS-запись определяет точку входа клиента в приложение.

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

На этом этапе начинается самое интересное.

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

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

Обычно в самом начале в целях экономии все развертывается в пределах одного сервера.

В принципе, при старте приложения этот вариант может подойти для понимания нагрузки.

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

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

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

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

оптимизировать затраты на инфраструктуру.

При необходимости мы теперь можем безболезненно добавить фронтенд-серверы и добавить для них A-запись.

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

Все дальнейшее построение логики будет полностью определяться вашим приложением.

При планировании архитектуры проекта необходимо уделять внимание даже мельчайшим деталям.