Привет, меня зовут Анатолий, я ведущий разработчик в ITFB Group. Наш ключевой микросервис со временем превратился в настоящего монстра. Разросшийся, медленный и перегруженный лишними функциями, он тормозил весь продукт и усложнял жизнь разработчикам. Любая правка превращалась в квест: чтобы внести изменение в одном месте, приходилось разбираться ещё в десятке несвязанных процессов.

Мы решили провести «хирургическую операцию»: за один месяц силами выделенной команды из 10 человек полностью расчистить сервис, вынести из него 40 процессов и вернуть архитектуре прозрачность. В этой статье я расскажу, как мы поставили диагноз, спланировали операцию и справились с самыми болезненными моментами — от войны с конфигами до разрыва общих DTO.

Главный спойлер: результат превзошёл ожидания. Сервис стал быстрее, команды — автономнее, а система наконец-то обрела масштабируемость.

Диагноз: микросервис, захваченный процессами-паразитами

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

Мы столкнулись с классическими симптомами:

• Когнитивная перегрузка. Чтобы поправить один процесс, нужно было вникать ещё в десять.

• Медленный цикл разработки. Запуск сотен несвязанных тестов занимал огромное время.

• Архитектурная гниль. Сервис стал «точкой связывания» для всей системы, нарушая принципы слабой связанности.

Пример: в сервис платежей зачем-то встроили генерацию отчётов, а в сервисе уведомлений жили свои утилиты для расчёта метрик. Смешение ответственности стало нормой.

Операция «Расщепление»: план и вызовы

Мы выделили dedicated-команду из 10 разработчиков и поставили амбициозную цель: за один месяц провести полный рефакторинг.

План выглядел так:

1. Инвентаризация и маркировка. Мы каталогизировали всё: процессы, делегаты, DTO, фикстуры, конфигурации.

2. Пошаговое «выпиливание». Выносили по 2–3 процесса в неделю, проверяя, что продакшен не ломается.

3. Отслеживание зависимостей. Следили, чтобы за процессом уходили все его хвосты: DTO, утилиты, фикстуры, настройки в pom.xml и application.yaml.

Самые болезненные моменты:

• Мусор, который легко забыть. Один «забытый» dependency мог свести на нет всю работу.

• Война конфигов. Вырезание конфигураций из pom.xml и application.yaml оказалось самым кропотливым: неверный dependency — и сервис не встаёт. Несколько раз у нас реально падали стенды.

• Разделение DTO и API. Мы раскладывали общие DTO и интерфейсы feign-клиентов по тематическим библиотекам, чтобы новые сервисы оставались независимыми.

Это было похоже на хирургическую операцию: каждый «разрез» должен быть точным, иначе вся система начинала «кровоточить».

Результат: не только чистота, но и скорость

Через месяц мы вынесли около 40 процессов. Но главная ценность была не в цифрах, а в качественных изменениях.

• Чистая архитектура. Каждый сервис теперь выполняет только свою основную задачу. Ответственности перестали пересекаться.

• Скорость запуска стендов. Ушла необходимость поднимать и настраивать лишние компоненты. Время подготовки окружения сократилось в разы.

• Быстрее ответы на запросы. Бывший монстр перестал тратить ресурсы на посторонние задачи.

• Скорость разработки. Команды, работающие с выделенными сервисами, стали полностью автономными: меньше координации, больше результата.

Что мы вынесли для себя

Главный урок прост: рефакторинг монолита в микросервисы — это не только про бизнес-логику. Это ещё и война с конфигурациями, зависимостями и «мусором», который копится годами.

Успех обеспечили три вещи:

• тщательное планирование,

• выделенная команда,

• и фокус на полном цикле — от кода до конфигов.

Теперь наша система не просто чище. Она быстрее, масштабируемее и готова к новым фичам без страха превратиться в очередного монстра.