Корпоративный монолит редко мешает, пока он молодой. Проблемы начинаются на пятый-седьмой год: релиз тянется неделями, одна правка в биллинге ломает отчётность, а команда боится трогать код, который никто не помнит. Соблазн – переписать всё с нуля. Это почти всегда ошибка: новая система догоняет старую годами, а бизнес продолжает работать на том, что есть. Правильный путь – постепенная декомпозиция, при которой монолит остаётся в строю, а вокруг него отрастают сервисы.
Найдите швы, а не модули
Микросервис начинается не с технологии, а с границы ответственности. Не делите код по слоям (контроллеры, репозитории, утилиты) – делите по бизнес-возможностям: расчёт тарифа, ведение договоров, обмен с контрагентами. Каждая такая возможность – кандидат на отдельный сервис со своими данными и своим владельцем.
Самый надёжный способ найти границы – посмотреть, что чаще всего меняется вместе и что чаще всего ломается вместе. Возьмите историю коммитов и инцидентов за полгода. Куски кода, которые правят синхронно разные команды, – это будущий конфликт. Куски, которые меняются изолированно, – готовые швы для отделения.
Начинать стоит с периферии, а не с ядра. Хороший первый кандидат – функция с понятным контрактом и небольшим числом зависимостей: уведомления, генерация печатных форм, выгрузка во внешние системы. Ядро (учётная запись клиента, главная книга) трогайте в последнюю очередь, когда команда уже набила руку.
Отделяйте через контракт и Strangler
Базовый приём – паттерн «удушающего» фасада (Strangler). Перед монолитом ставится точка маршрутизации. Новый сервис принимает часть запросов, остальное по-прежнему идёт в монолит. Доля трафика на сервис растёт постепенно, и в любой момент можно откатиться. Это безопаснее, чем «большой взрыв» с одномоментным переключением.
Ключевое условие – явный контракт между сервисом и остальной системой. Зафиксируйте API: формат запросов, коды ошибок, гарантии по времени ответа. Пока контракт не зафиксирован, внутреннюю реализацию можно менять как угодно – это и есть свобода, ради которой всё затевалось.
Отдельный больной вопрос – данные. Сервис без своей базы не сервис, а распределённый монолит. Но и резать общую БД сразу опасно. Промежуточный шаг: сервис владеет таблицами логически (только он пишет в них), физически они пока остаются в общей базе. Прямые SQL-запросы из других модулей к этим таблицам запрещаются и заменяются вызовами через контракт. Физическое разнесение – позже.
Учитывайте данные и регуляторику
Декомпозиция меняет географию данных. Когда вы выносите обмен с контрагентами или хранение клиентских записей в отдельный сервис, вы заново отвечаете на вопрос, где эти данные лежат. Для российского бизнеса это не абстракция: вступающие в силу требования к локализации персональных данных распространяются и на новые сервисы. Перед выделением сервиса с ПДн проведите аудит размещения данных, чтобы дробление не вынесло персональные данные за пределы РФ.
То же касается юридически значимого обмена. Если монолит выпускал электронные документы, выделенный сервис должен сохранить требования к юридически значимому ЭДО: подпись, форматы, хранение. Разбивая систему, легко потерять эти гарантии в стыках между сервисами.
Вывод
Декомпозиция – это дисциплина, а не разовый проект. Находите швы по бизнес-границам, отделяйте периферию через контракты и Strangler, держите данные под одним владельцем и не теряйте регуляторные требования на стыках. Монолит при этом работает все время, пока вокруг него вырастает новая архитектура. Поэтому модернизацию корпоративных бизнес-систем разумно начинать с одного сервиса и доводить его до продакшена – остальные пойдут быстрее.
