Этот пост будет про эволюцию web-приложений с фокусом на серверную часть (backend). Начнем мы снова со схемы работы статичного сайта и поговорим про web-сервер и протокол HTTP.

Рисунок 4 - Схема работы статичного сайта

Рисунок 4 - Схема работы статичного сайта

На рисунке для упрощения представлено будто браузер обращается напрямую к Web-северу, но в реальной жизни между ними расположены сетевые устройства, которые передают запрос от одного устройства к другому, пока запрос не достигнет Web-сервера. Web-сервер это программа, которая принимает HTTP-запрос, обрабатывает его и возвращает HTTP-ответ. HTTP это протокол, который активно использует возможности другого протокола - TCP (или TLS - защищённый TCP) - для пересылки своих сообщений. Одним из таких сообщений может быть html-документ.

В прошлом был популярен web-сервер Apache и он, согласно данным w3techs находит применение до сих пор. Дальше появились скриптовые языки и системы управления базами данных. Интеграция скриптовых языков и web-сервера выполнялась через модули для web-сервера. Модули это программы, которые исполняли скрипт. Результат скрипта внедрялся в тело страницы, которую потом отправляли в виде HTTP-ответа. Вначале сайт представлял из себя набор скриптов, но постепенно начали появляться средства и инструменты, которые упрощали разработку, вроде Zend Engine и различных фреймворков). Чем дальше в лес, тем больше фреймворков.

Росло число пользователей и, как следствие, число соединений с web-сервером. У Apache были проблемы с большим числом соединений (порядка 10 тысяч) и позже появился web-сервер nginx. Он потреблял мало ресурсов и быстро стал популярным. Кстати, nginx использовали (и используют до сих пор) вместе с apache. Nginx обрабатывал статику и перенаправлял запросы, а apache обрабатывал скрипты.

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

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

Рисунок 5 - Схема работы статичного сайта

Рисунок 5 - Микросервисная архитектура

Остановимся на описании рисунка подробнее. Frontend отправляет запрос web-серверу. Web-сервер передает его API-шлюзу. API-шлюз делает запросы сервисам и собирает все необходимые данные для ответа и возвращает ответ web-северу, который передает их во Frontend.

Последнее про что я хочу рассказать это так называемый Serverless подход. В основе подхода лежит идея о том, чтобы программист вообще ничего не настраивал и не устанавливал, а писал код, который будет исполнен в неком окружении. От разработчика требуется написать на предлагаемом языке (часто это python) функцию (serverless function) и загрузить ее в среду исполнения. Функция будет запущена в облаке и у нее будет точка входа (endpoint), куда можно передать данные для обработки. Фишка здесь в том, что нужно написать код, а его исполнение, обработку нагрузки возьмет на себя платформа. Областью использования может быть backend для мобильных приложений, чат-ботов и разного рода вычисления.

Итак, со стороны backend вначале был web-сервер, который принимал запросы и отдавал файлы, потом начали писать скрипты и работать с базой данных, появились библиотеки и фреймворки. Рост нагрузки и желание разделить приложения на отдельные компоненты, которые могут быть разработаны отдельной командой приводит к появлению микросервисной архитектуры. Еще позже, когда вовсю используют облачные технологии и контейниризацию появляются Serverless функции, которые выполняются в облаке и не требуют настройки и поддержки отдельного сервера.