Архитектура веб-проекта: для чего она нужна

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

Веб-приложения состоят из двух составляющих – клиентской и сервисной. Айтишники называют их «фронтенд» и «бекенд». Двухуровневая архитектура считается традиционной, в которой бекенд играет роль сервера базы данных. Один из ее существенных недостатков – снижение производительности приложения при увеличении пользователей. К тому же прямое взаимодействие базы данных и устройства клиента угрожают безопасности приложения.

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

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

1. Безошибочно подберет базовую структуру проекта, расставит приоритеты между ее основными и второстепенными элементами.
2. Выстроит логическую цепочку взаимодействия компонентов .
3. Предусмотрит возможные риски и найдет способы их нивелирования на стадии разработки и в процессе использования готового ПО.
4. Обеспечит комфортную работу всей команды.
5. Сможет оценить трудоемкость разработки, разбить объем работы рад проектом на отдельные этапы и установить срок выполнения каждого из них.

Любое приложение представляет собой совокупность «кирпичиков», взаимодействующих между собой в соответствии с принятым IT-решением. А их на данный момент три:

1. Монолит: все блоки приложения находятся в прямой зависимости друг от друга.
2. Микросервис: каждый модуль приложения самостоятелен. В общую схему работы они встраиваются через определенные алгоритмы.
3. Серверлесс: разновидность микросервиса, ориентированная на облачные технологии, благодаря которым производится автоматическое развертывание системы.

У каждого из архитектурных решений есть свои достоинства и недостатки.

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

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

Благодаря автономии каждого сервиса система приобрела гибкость: разработчик может менять любой из модулей, не затрагивая другие составляющие элементы архитектуры. А выход из строя одной подсистемы не оказывает влияния на ее «соседей».

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

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

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

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

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

1. Клиент. Такой статус получает устройство, подключенное к серверу с целью использования его сервиса или ресурсов. Роль клиента может исполнять программное обеспечение, веб-сайт, компьютер пользователя, встроенная система. Название клиента зависит от сервиса, которым он пользуется (клиент базы данных, веб-клиент и .д.).
2. Балансировщик или распределитель нагрузки между отдельными модулями. Он оценивает загруженность серверов и находит самый доступный на данный момент. Балансировщики бывают аппаратные и программные. Вторые применяются чаще по причине их дешевизны и способности работать с виртуальными серверами.
3. CDN – совокупность серверов, обеспечивающих высокую производительность и безопасность приложений.
4. База данных, в которой хранится различная информация.
5. Очередь сообщений. Этот модуль разработчики используют в тех случаях, когда необходимо обеспечить надежность транзакций.

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

Пользователь в браузере ищет в Гугле нужную информацию. Кликает по ссылке в поисковике и ждет результата. На экране открывается выбранная им страница – допустим, это Storyblocks. Ждет клиент недолго, по его наблюдению процесс протекает в считанные секунды. И за такой малый временной промежуток между запросом и ответом происходит следующее:

• Браузер формирует и направляет запрос на DNS-сервер на установление соединения со Storyblocks, дожидается ответа и запрашивает разрешение у сайта.
• Обращение попадает на балансировщик нагрузки. Он проверяет сетевую информацию (IP-адреса и пр.) и оптимизирует перенаправления трафика. Этот модуль выбирает один из примерно 10 веб-серверов, на которых активирован сайт. Выбранный сервер берет часть информации из кэша (в нашем примере речь идет об изображении) и дополняет ее сведениями из базы данных.
• Осуществляется поиск похожих фотографий: роль входных данных отводится запросу с заголовком картинки. Если произошла авторизация клиента в Storyblocks, из базы данных загружается информация о его учетной записи.
• Сведения о просмотре страницы отправляются в хранилище, где они записываются в облачную систему хранения. После загрузки данных в хранилище данных аналитики смогут использовать их для обработки.
• Сервер подвергает страничку рендерингу в HTML (структурирует ее) и возвращает браузеру пользователя – но опять через балансировщик загрузки. Браузер связывается с CDN (системой доставки информации – текстовой, графической и т.д.) для получения контента и отображает страницу клиенту.

Из приведенного примера видно, насколько сложна веб-архитектура по своему строению, и как важно правильно ее построить.

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

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

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

• гибкость;
• многоразовость;
• простота;
• скорость отклика;
• конфиденциальность;
• использование проверенных на практике стандартов безопасности.

Архитектура веб-приложений строится с учетом разных аспектов. Ее разработка требует от исполнителя специальных знаний. Лучший способ получить безопасный и надежный вариант – это обратиться к профессиональной команде. Опыт ее участников позволит быстро выполнить задачу с учетом ее индивидуальных особенностей.