Переезд веб-портала: от монолита к микросервисной архитектуре

    Делимся опытом модернизации архитектуры веб-портала, позволившей сделать продукт удобным, стабильным и отказоустойчивым: посещаемость выросла с 350 тысяч до 7 миллионов пользователей! История будет полезна тем, кто планирует расширение своего продукта. Для начала разберемся, какие факторы могут помешать работе и развитию веб-портала:

    • Моральное устаревание. Подход к юзабилити, адаптация к разным устройствам, элементарный внешний вид и структура со временем перестают отвечать запросам аудитории.
    • Технологическое устаревание. Веб-стандарты и технологии постоянно совершенствуются. Изменения затрагивают как инструменты разработчика (например, фреймворки, базы данных, прочее ПО), так и фундаментальные основы веба. Из относительно недавнего — массовый переход с http на https и отказ от поддержки устаревших DNS.
    • Ошибки и сбои. Разработчики могут неидеально справляться со своей задачей и допускать огрехи. Вследствие этого в работе сайта могут происходить нарушения — начиная с того, что кнопки не срабатывают с первого раза, до полного отказа систем.

    Кейс

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

    Аудит

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

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

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



    Микросервисы

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

    • Выгрузка, хранение и управление данными из проектов открытых источников;
    • Динамическое создание RSS-лент;
    • Динамическое создание системы блоков, компоновка материалов любых сервисов в структурные блоки;
    • Добавление к материалам сервисов дополнительных данных;
    • Сервис технической поддержки;
    • Единый каталог различных данных.

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



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

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

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

    • Решили проблему масштабирования.
    • Внедрили более эффективный процесс разработки распределенными командами.
    • Настроили динамическое управление ресурсами для бесперебойной и быстрой работы системы.


    Модернизация стека технологий

    Параллельно мы обновили стек технологий. Если изначально портал базировался на php 5.6 и MySQL 5.6, то в ходе усовершенствования движка мы перевели его на версии php 7.0 и MySQL 5.7. Внедрили фреймворк Yii2, обеспечили кеширование memcache.



    Очередь задач

    В целях лучшего распараллеливания задач мы перевели веб-воркеры — внутренние обработчики — на очередь RabbitMQ. Она оптимизирует последовательность запуска событий, что снижает нагрузку на систему. Работа с сайтом стала гораздо быстрее и комфортнее.

    Непрерывная интеграция

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

    Для того, чтобы свести к минимуму ошибки, мы ввели дополнительные контуры разработки. Цепочка состоит из нескольких контуров тестирования приложения и инфраструктуры: предрелизный, где проходит последнее тестирование сборки (pre-prod), боевой (prod), несколько тестовых контуров для тестирования сразу нескольких билдов, а также контур для разработчиков.

    Система сборок

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

    Мониторинг ошибок

    GitLab CI дает продвинутые возможности валидации кода и автоматического тестирования. При малейшем несоответствии сборок заданным параметрам система оповещает разработчиков и не позволяет запустить дальнейший процесс реализации компонента до исправления ошибок. Дополнительно мы установили Sentry — полноценный инструмент мониторинга ошибок.



    Оптимизация процессов

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

    Мониторинг и эксплуатация

    Все процессы — как на ладони. Мониторинг состояния каждого узла нам обеспечивает Zabbix — комплексная система отслеживания. Мы получили возможность заглянуть в самое ядро структуры проекта и увидеть её компактно.

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

    Стабилизация и рефакторинг

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

    Новая архитектура — база для роста

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

    Новый сайт — мощный инструмент развития бизнеса, имеющий потенциал к дальнейшему масштабированию. Используя обновленную архитектуру веб-приложения, маркетологи проекта смогли реализовать свой комплекс мероприятий по продвижению и увеличить посещаемость — с 350 тысяч уникальных посетителей в месяц до более чем 7 миллионов. При этом после многократного увеличения аудитории портал продолжает стабильно функционировать.
    SimbirSoft
    92,53
    Лидер в разработке современных ИТ-решений на заказ
    Поделиться публикацией

    Похожие публикации

    Комментарии 2

      +1
      Вроде бы это уже было.
      Очень знакомые цифры 7 млн, 20 раз. Да и картинки тоже
        0
        Непонятен реальный выхлоп — почему этим методом сделано, в чем премущества и т.п.

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

        Еще раз, то, что было сделано, но другими словами:

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

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

        А какие минусы?
        Например, увеличилась ли нагрузка на разработчиков.
        Сколько разработчиков, сколько микросервисов?

        Чем оркестрируется?

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

        Самое читаемое