Привет, меня зовут Анатолий, я ведущий разработчик в ITFB Group. Наш ключевой микросервис со временем превратился в настоящего монстра. Разросшийся, медленный и перегруженный лишними функциями, он тормозил весь продукт и усложнял жизнь разработчикам. Любая правка превращалась в квест: чтобы внести изменение в одном месте, приходилось разбираться ещё в десятке несвязанных процессов.
Мы решили провести «хирургическую операцию»: за один месяц силами выделенной команды из 10 человек полностью расчистить сервис, вынести из него 40 процессов и вернуть архитектуре прозрачность. В этой статье я расскажу, как мы поставили диагноз, спланировали операцию и справились с самыми болезненными моментами — от войны с конфигами до разрыва общих DTO.
Главный спойлер: результат превзошёл ожидания. Сервис стал быстрее, команды — автономнее, а система наконец-то обрела масштабируемость.
Диагноз: микросервис, захваченный процессами-паразитами
Сервис стал жертвой собственной востребованности. Каждая новая фича добавляла «всего пару классов», но в итоге он оброс десятками побочных процессов, которые к его основной задаче имели лишь косвенное отношение.
Мы столкнулись с классическими симптомами:
Когнитивная перегрузка. Чтобы поправить один процесс, нужно было вникать ещё в десять.
Медленный цикл разработки. Запуск сотен несвязанных тестов занимал огромное время.
Архитектурная гниль. Сервис стал «точкой связывания» для всей системы, нарушая принципы слабой связанности.
Пример: в сервис платежей зачем-то встроили генерацию отчётов, а в сервисе уведомлений жили свои утилиты для расчёта метрик. Смешение ответственности стало нормой.
Операция «Расщепление»: план и вызовы
Мы выделили dedicated-команду из 10 разработчиков и поставили амбициозную цель: за один месяц провести полный рефакторинг.
План выглядел так:
Инвентаризация и маркировка. Мы каталогизировали всё: процессы, делегаты, DTO, фикстуры, конфигурации.
Пошаговое «выпиливание». Выносили по 2–3 процесса в неделю, проверяя, что продакшен не ломается.
Отслеживание зависимостей. Следили, чтобы за процессом уходили все его хвосты: DTO, утилиты, фикстуры, настройки в pom.xml и application.yaml.
Самые болезненные моменты:
Мусор, который легко забыть. Один «забытый» dependency мог свести на нет всю работу.
Война конфигов. Вырезание конфигураций из pom.xml и application.yaml оказалось самым кропотливым: неверный dependency — и сервис не встаёт. Несколько раз у нас реально падали стенды.
Разделение DTO и API. Мы раскладывали общие DTO и интерфейсы feign-клиентов по тематическим библиотекам, чтобы новые сервисы оставались независимыми.
Это было похоже на хирургическую операцию: каждый «разрез» должен быть точным, иначе вся система начинала «кровоточить».
Результат: не только чистота, но и скорость
Через месяц мы вынесли около 40 процессов. Но главная ценность была не в цифрах, а в качественных изменениях.
Чистая архитектура. Каждый сервис теперь выполняет только свою основную задачу. Ответственности перестали пересекаться.
Скорость запуска стендов. Ушла необходимость поднимать и настраивать лишние компоненты. Время подготовки окружения сократилось в разы.
Быстрее ответы на запросы. Бывший монстр перестал тратить ресурсы на посторонние задачи.
Скорость разработки. Команды, работающие с выделенными сервисами, стали полностью автономными: меньше координации, больше результата.
Что мы вынесли для себя
Главный урок прост: рефакторинг монолита в микросервисы — это не только про бизнес-логику. Это ещё и война с конфигурациями, зависимостями и «мусором», который копится годами.
Успех обеспечили три вещи:
тщательное планирование,
выделенная команда,
и фокус на полном цикле — от кода до конфигов.
Теперь наша система не просто чище. Она быстрее, масштабируемее и готова к новым фичам без страха превратиться в очередного монстра.
