Елизавета Акманова

Ведущий аналитик

Коллеги, привет! Я, Акманова Елизавета, ведущий аналитик ГК Юзтех, продолжаю делиться своим опытом в проекте, связанным с распиливанием монолита на микросервисы микрофронты. В первой части мы подробнее познакомились с данной концепцией и теперь понимаем ее сильные и слабые стороны. В текущей части посмотрим на алгоритм перехода от одной архитектуры к другой. Вперед! 

Предыстория

Ранее ИТ отдел в компании был не таким большим: 3 команды (Каталог, Заказы, Личный кабинет). Архитектуры сайта была очень банальной: монолитный фронт, API Gateway для приема всех клиентских запросов, бэк сервисы уже разбиты на микросервисы. 

На этом этапе монолит не был проблемой. Изменения вносились быстро, конфликты решались за пять минут, сборка — за две. Мы даже думали: «Зачем нам микрофронтенды? И так всё работает!» Но это длилось ровно до тех пор, пока проект не начал масштабироваться.

Целевой картиной развития ИТ отдела в компании была примерно следующая: 13 продуктовых команд (+клиентская поддержка, лояльность/акции, доставка…), 100+ разработчиков. Бэкенд справлялся — ведь он изначально был микросервисным. А вот фронтенд оставался монолитом. И он стал точкой отказа. Все команды согласились: именно монолит тормозил развитие. Некоторые проблемы стали появляться уже в ходе развития, некоторые мы предвидели наперед, а именно…

Зависимости

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

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

• Предвидеть последствия изменений еще на этапе проектирования

• Координировать требования между командами, которые даже не знают о существовании друг друга

• Разрешать конфликты, когда две команды по-разному интерпретируют одни и те же бизнес-правила.

Тестирование

Еще один кошмар — тестирование. В монолите нельзя протестировать фичу изолированно. QA-инженеры вынуждены проверять ВСЁ, потому что изменение в одном модуле могло незаметно сломать другой. Регрессионное тестирование растягивалось на дни, дедлайны срывались, заказчики недовольны.

Мы пробовали автоматизировать тесты, но и это не спасало. Ведь если в монолите 1000 компонентов, то даже 1% ошибок даёт 10 багов. И каждый из них — это срочный фикс, передеплой и риск для продакшена. Казалось бы, тестирование — это зона ответственности QA. Но в монолите аналитик вынужден:

• Описать все возможные сценарии влияния изменений на другие модули

• Участвовать в приемке, потому что только он знает все скрытые взаимосвязи

• Объяснять заказчику, почему баги появляются в неожиданных местах (самая нетривиальная задача)

Адаптация новых сотрудников

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

• Огромное количество страниц документации, большая часть которой безнадежно устарела

• 50+ взаимосвязанных модулей, где изменение в одном месте может сломать три других

• Критические знания, которые существуют только в головах "старослужащих"

Мы фиксировали: в среднем уходило от 8 до 12 недель, чтобы новый аналитик начал более-менее уверенно ориентироваться в проекте. И даже после этого периода они постоянно переспрашивали и перепроверяли каждое свое решение. Почему? Потому что в монолите последствия изменений практически невозможно предсказать заранее.

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

…и некоторые проблемы для разработчиков…

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

Вторая боль — катастрофическая деградация наших процессов CI/CD. Поскольку мы имеем дело с единой сборкой для всего монолита, даже самое незначительное изменение — буквально правка одной строки кода — требует полного пересборки всего приложения. На практике это означает: 15-20 минут на сборку, ещё 25-30 минут на прогон всех тестов, и 10-15 минут на сам деплой. В сумме — около часа ожидания для внесения мелкого исправления! И это в идеальном случае, когда всё проходит гладко. А ведь достаточно одной ошибки в любом из 1500 тестов, чтобы весь процесс пришлось начинать заново.

Процесс переезда с монолита на микрофронты

После всего услышанного у вас наверняка возникает вопрос: как мы продолжали работать в таких условиях? Ответ прост — мы не продолжали. Мы начали двигаться к микрофронтендам. Глобально рассматривали два подхода: 

Постепенная миграция

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

❌ Если модули сильно связаны, миграция усложняется

Полный рефакторинг

Суть: Полный перезапуск фронтенда с нуля в виде микрофронтендов

❌ Если что-то пойдет не так, весь фронтенд может "лечь"

❌ Долгий период разработки 

❌ Нужен freeze фич

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

Какие задачи у меня, как у аналитика, были в этом всем процессе: 

1. Выделение микрофронтов по бизнес-доменам

- Сегментация системы на автономные бизнес-возможности (например: "Личный кабинет", "Оплата", "Каталог")

Инструмент: С4 до уровня контейнеров 

- Определение границ доменов (Bounded Context) совместно с архитекторами

Инструмент: Bounded Context Canvas

- Приоритизация модулей для переноса (начинаем с самых независимых и простых для выстраивания процесса знакомства с новым подходом и технологиями)

2. Проектирование API-контрактов

Думаю, что большинство аналитиков, читающих данную статью, умеют проектировать API. Единственный нюанс уточню, что мы это делаем с помощью OpenAPI спецификации (работает только с VPN). 

3. Описание Shell / Контейнера

- Определение требований к shell 

Какие общие сервисы должны быть доступны всем микрофронтам (навигация, аутентификация)

Какие межмикрофронтовые сценарии нужны (передача данных между "Корзиной" и "Оплатой")

- Сценарии интеграции

Как shell управляет жизненным циклом микрофронтов (загрузка, кэширование, версионирование)

Требования к изолированности (CSS/JS-конфликты, shared-зависимости)

- Бизнес-ограничения

Нужна ли отложенная загрузка (lazy loading) для производительности

Последствия внедрения

Решили ли мы все проблемы после полного переезда с монолита на микрофронты? 

Изолированная работа команд

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

Собственные репозитории

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

Автономное тестирование

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

Простота изучения

Новым аналитикам теперь не нужно разбирать всю компанию - достаточно погрузиться в один домен. Это сократило время адаптации с 3 месяцев до 2-3 недель. Да и опытным коллегам проще вносить изменения, когда перед глазами только релевантная логика, а не сотни связанных документов.

А появились ли новые проблемы?))) Конечно! 

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

Почему? Потому что микрофронты — это не просто "поделим на папки", это повышение сложности на всех уровнях:

• у вас появится больше сборок, больше точек отказа

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

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

Заключение

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

В нашем случае микрофронты — это решение под конкретную боль. А если её нет — и хорошо! Сэкономите кучу времени.