Как архитектура сайта снижает расходы на поддержку и развитие

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

Именно с такой ситуацией мы столкнулись при модернизации портала ВДНХ. Нужно было не только создать новый интерфейс, но и объединить 14 сайтов, сохранить работу мобильного приложения и информационных стел, упростить публикацию контента и подготовить платформу к резким скачкам посещаемости.

Новый сайт не решает проблему старой системы

До модернизации разные направления ВДНХ существовали в виде отдельных сайтов. У проектов отличались дизайн, навигация и техническая реализация. Для посетителя это выглядело так, будто он покидает одну организацию и попадает на совершенно другой ресурс.

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

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

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

Единая платформа вместо набора сайтов

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

Серверная часть отвечает за данные и правила их обработки. Nuxt формирует пользовательский интерфейс. Отдельная административная панель используется редакторами. Эти компоненты можно развивать и масштабировать независимо.

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

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

Старые интеграции сохранили

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

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

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

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

Производительность перестраивали на нескольких уровнях

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

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

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

Отдельная задача возникла с афишей. Более 100 параметров фильтрации создавали слишком много сочетаний. При прямых запросах база не справлялась даже с 10 обращениями в секунду.

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

Запрос вида "бесплатные детские концерты в ближайшие выходные" стал обрабатываться за 3-5 мс. Нагрузка на базу сократилась на 90%.

Пиковая нагрузка не должна требовать постоянного запаса серверов

Посещаемость ВДНХ меняется неравномерно. Открытие катка или крупная выставка могут за короткое время привести на сайт значительно больше посетителей, чем в обычный день.

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

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

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

Редактор стал частью архитектуры

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

Для ВДНХ сделали модульный редактор. Страницы собираются из готовых блоков: текста, изображений, карт и подборок событий. У каждого блока есть несколько вариантов оформления.

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

Обучение работе с административной панелью заняло 2 часа. Через неделю разработчики заказчика уже самостоятельно добавляли в нее новые функции.

Отдельно пересмотрели работу с картами и переводами

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

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

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

Переводы также встроили в редакционный процесс. Элементы интерфейса выгружаются в Excel, переводятся и загружаются обратно. Если материал не переведен на конкретный язык, система просто не показывает его в этой версии сайта.

Так английская и китайская версии не превращаются в неполные копии основного ресурса.

Результат проекта

Разработка заняла 6 месяцев, включая дизайн, согласования и подготовку документации.

Время отклика серверной части сократилось с 900 до 62 мс, почти в 15 раз. Основной экран загружается менее чем за 2 секунды даже при пиковых нагрузках. Показатель скорости отображения главного содержимого улучшился на 40%.

Но главный результат не ограничивается скоростью. ВДНХ получила единую платформу вместо набора самостоятельных сайтов. Редакторы управляют контентом без постоянного участия разработчиков. Старые приложения продолжают работать. Команда заказчика может самостоятельно развивать систему или передать ее другому подрядчику.

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

Здесь я обычно пишу про проекты, кейсы и ИТ-практику.
А если хочется увидеть меня не только в рабочих текстах - приходите в мой тг https://t.me/alekseypostrigaylo. Там - сын, поездки, работа за кадром, личные наблюдения и попытка жить так, чтобы было что вспомнить.