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

API-first: сначала контракт, потом реализация

API-first означает, что граница между частями системы фиксируется раньше, чем вы напишете хоть одну строку внутренней логики. Вы описываете контракт – в OpenAPI для REST или в .proto для gRPC, – согласуете его с потребителями и только потом реализуете обе стороны. Контракт становится точкой синхронизации команд: фронтенд, смежные системы и внешние интеграторы работают по спецификации, не дожидаясь готового сервиса.

Для госсектора это особенно важно. Когда система обменивается данными через СМЭВ или с ведомственными реестрами, контракт – это ещё и предмет регламента и приёмки. Зафиксированный API проще согласовать, протестировать на стенде и провести через аттестацию, чем «живой» код, который меняется каждую неделю.

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

Strangler pattern: выносим функции по одной

Перестройка монолита идёт не разрывом, а удушением – strangler pattern, который описал Мартин Фаулер. Перед монолитом ставится шлюз (API gateway или обратный прокси). Сначала весь трафик идёт в монолит. Затем вы выбираете одну функцию – например, расчёт скидок или нотификации – выносите её в отдельный сервис и переключаете маршрут на шлюзе. Монолит про эту функцию больше не знает.

Так, кусок за куском, ядро усыхает, а новые сервисы растут. На каждом шаге система работает целиком: если новый сервис ведёт себя плохо, вы возвращаете маршрут на монолит за минуты, без отката всего релиза.

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

Что это даёт бизнесу

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

Платить за это приходится сложностью эксплуатации: сеть, мониторинг, трассировка запросов, согласованность данных. Микросервисы – не цель, а инструмент под конкретную боль. Если у вас одна команда и стабильная нагрузка, аккуратный модульный монолит честнее. Этот выбор стоит делать осознанно – мы разбирали логику решения в материале про заказную и коробочную разработку, и архитектурная зрелость закономерно попадает в приоритеты ИТ-директора на 2020 год.

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

Вывод

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