Модульный монолит или микросервисы: критерии и миграция

С чего начинается выбор: какие проблемы вы реально решаете

Разговор про модульный монолит или микросервисы почти никогда не начинается с архитектуры. Он начинается с боли, которая мешает выпускать изменения, держать качество и проходить проверки. Первый шаг простой: честно назвать 2-3 главные проблемы и измерить их. Сколько релизов в месяц вы делаете сейчас, сколько инцидентов ловите, сколько времени уходит на согласования, тесты и откаты.

Чаще всего к теме микросервисов приводят одни и те же ситуации. Релизы становятся редкими и рискованными: любое изменение цепляет полсистемы. Команды мешают друг другу в одном репозитории и одной базе, появляются очереди на то, чтобы «влить» код. Бизнесу нужна разная скорость развития модулей: часть функций меняется каждую неделю, часть почти статична. Добавляются требования по изоляции данных, аудиту, доступам и регуляторике. А если продукт работает 24/7, то инцидент в одном месте начинает валить весь сервис.

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

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

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

Коротко о подходах: модульный монолит и микросервисы простыми словами

Модульный монолит - это одно приложение и один деплой, но внутри оно разделено на понятные части (модули) с жесткими границами. У каждого модуля своя зона ответственности: свои бизнес-правила, свои модели данных и свой API для остальных. Главное правило: модули общаются только через договоренные интерфейсы, а не по принципу «давай я напрямую возьму твою таблицу или класс».

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

Как понять, что у вас сейчас? Если «все со всем связано», общий слой сущностей используется повсюду, а любая правка требует прогонять регрессию половины системы - это монолит без модулей. Если вы уже можете назвать 5-10 доменов (например, «клиенты», «заказы», «счета»), и изменения чаще всего затрагивают один домен, а не все сразу, вы уже близко к модульности, даже если деплой пока один.

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

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

Критерии выбора, которые важны именно для корпорации

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

Первый критерий - команды. Если у вас 2-3 команды, которые постоянно трогают один и тот же код и выпускают релизы вместе, модульный монолит часто проще и быстрее. Если команд много, и они могут работать почти независимо (разные домены, разные темпы, отдельные окна релизов), микросервисы дают организационную свободу, но только при дисциплине и зрелой эксплуатации.

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

Третий критерий - надежность и цена простоя. Если падение одного участка не должно «уронить все», сервисная изоляция помогает. Но иногда достаточно грамотных границ внутри модульного монолита и резервирования на уровне инфраструктуры.

Четвертый - интеграции. Чем больше внешних систем (госреестры, банки, ERP/CRM) и чем они нестабильнее, тем важнее изолировать точки риска и заранее закладывать очереди, ретраи и лимиты. Это можно сделать и в монолите, но в сервисах границы обычно виднее.

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

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

Простая матрица решения: как принять выбор без споров

Споры обычно начинаются с громких формулировок, а заканчиваются сорванными сроками. Практичнее договориться так: взять 4-5 критериев, честно оценить оба подхода и зафиксировать приоритеты именно вашего бизнеса. Тогда вопрос «модульный монолит или микросервисы» превращается в понятное решение, а не в борьбу мнений.

Есть несколько пороговых вопросов, после которых микросервисы почти всегда рано. Например: релизы выходят реже, чем раз в 2-4 недели, и бизнесу это нормально; нет выделенной роли или команды эксплуатации (SRE/DevOps), все держится на «одном герое»; нет единого мониторинга и понятного процесса реакции на инциденты; границы доменов спорные и не зафиксированы в терминах бизнеса; тестирование в основном ручное и уже заметно тормозит поставку.

Если нужно получить 80% результата быстрее, часто выигрывает модульный монолит: вы вводите границы модулей, запрещаете прямые зависимости, чистите контракты. Уже этого хватает, чтобы снизить хаос без резкого роста операционных затрат.

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

Если остаетесь в модульном монолите: как сделать его настоящим

Модульный монолит работает, только если модули реально отделены. Иначе это просто один большой код, где «все зависит от всего», а изменения становятся медленнее с каждым месяцем. Если вы выбираете путь «модульный монолит или микросервисы», начните с того, чтобы монолит стал управляемым и предсказуемым.

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

Границы и зависимости

Дальше определите, что считается модулем, а что должно остаться общим. «Общее» обычно ограничивается инфраструктурой (логирование, конфиг, доступ к очереди) и редко - общими справочниками. Все остальное лучше держать внутри модулей.

Правила зависимостей важно не только написать, но и сделать проверяемыми. Обычно хватает нескольких базовых запретов: модуль обращается наружу только через публичный интерфейс (API модуля); прямые вызовы «внутренних» классов другого модуля запрещены; данные другого модуля читаются через его слой доступа, а не через прямые запросы; любые новые зависимости между модулями обсуждаются и фиксируются. Эти правила лучше проверять в сборке (архитектурные тесты или статическая проверка).

Технические стоп-листы и быстрый эффект

Самые частые «дыры», которые размывают модульность, лучше сразу запретить и вынести в стоп-лист. Обычно туда попадает общая база как единственная точка правды для всех модулей, «общие утилиты», которые превращаются в свалку на все случаи, общие модели данных, которые тянут за собой половину системы, и общий слой service, куда складывают бизнес-логику.

Чтобы показать результат быстро, изолируйте самый проблемный участок: тот, где больше всего инцидентов или где изменения ломают соседние функции. Вынесите его в отдельный модуль с четким API, запретите прямой доступ к его таблицам и добавьте несколько тестов на контракт. Это дает ощутимый эффект без переписывания всего приложения.

План миграции без переписывания: пошаговая схема

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

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

Пошаговая схема

1. Выберите пилотный модуль с понятной пользой и умеренным риском. Хороший кандидат - то, что часто меняется, но не останавливает бизнес при сбое (например, уведомления, справочники, витрина отчетов).

2. Стабилизируйте интерфейсы. Зафиксируйте версии API или форматы событий, добавьте контрактные тесты и заведите правило: новые интеграции делаются только через контракт.

3. Примените паттерн Strangler: поставьте «обходной контур» вокруг старого кода. Новые запросы идут в новый модуль или сервис, старые остаются в монолите. Доля трафика растет постепенно.

4. Вынесите один сервис целиком и доведите эксплуатацию до нормы: отдельный релизный цикл, мониторинг, алерты, трассировка, понятный откат (фича-флаги, переключение маршрута, возврат на старый обработчик).

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

Небольшой пример

В корпоративной системе согласования закупок можно начать с модуля уведомлений. Он дает быстрый эффект (меньше ручной коммуникации) и легко отделяется контрактом «событие: заявка перешла в новый статус». После этого проще выносить более критичные части, потому что «швы» уже проверены в реальной работе.

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

Данные и транзакции: как не сломать бизнес-процессы

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

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

Минимальный набор правил, который обычно спасает, выглядит так: у каждой таблицы (или набора таблиц) есть владелец (команда и сервис); записи меняет только владелец, остальные читают через API или представления; любые изменения схемы проходят через общий процесс согласования; критичные поля и справочники покрываются проверками качества данных; фиксируется единый словарь идентификаторов (что считается ключом).

Следующий шаг - у сервиса появляется своя база. Тогда изменения не «протекают» наружу, но возникает синхронизация. Самый понятный вариант - события: сервис-владелец пишет у себя и публикует факт (например, «заказ создан»), а другие сервисы обновляют свои копии данных.

Распределенные транзакции почти всегда приносят больше боли, чем пользы. Вместо них используют саги: бизнес-операция разбивается на шаги, и если один шаг не удался, выполняются компенсирующие действия. Простой пример: «выставить счет -> зарезервировать товар -> отправить уведомление». Если резерв не прошел, счет отменяется.

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

Эксплуатация и надежность: к чему готовиться заранее

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

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

Минимум наблюдаемости, без которого больно

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

• Централизованные логи с единым форматом и корреляцией по request id.
• Метрики (задержки, ошибки, нагрузка) и понятные дашборды.
• Распределенная трассировка для цепочек вызовов между сервисами.
• Алерты с порогами и правилами эскалации, а не «шумом».
• Проверки здоровья и готовности, чтобы выкатывать без сюрпризов.

Практики надежности, которые окупаются сразу

Сетевые сбои будут, поэтому защиту нужно закладывать в протоколы и бизнес-операции. Если сервис оплаты отправляет событие в очередь, повторная отправка не должна списать деньги дважды.

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

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

Типичные ошибки и ловушки при переходе

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

Вторая ловушка - «сделали микросервисы», но оставили одну общую базу данных без правил. Сервисы разные только на словах, а по факту они ломают друг другу схемы, спорят за транзакции и делают релизы опасными. Если общая БД временно неизбежна, нужны строгие договоренности: кто и какие таблицы меняет, как согласуются миграции, какие данные считаются источником истины.

Еще один частый провал - строить сложную инфраструктуру раньше времени, когда нет команды, которая будет ее поддерживать. Оркестрация, наблюдаемость, CI/CD, управление секретами и доступами дают пользу, только если есть люди и процессы, которые этим живут каждый день. Иначе это превращается в дорогую «черную коробку».

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

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

Короткий чек-лист перед стартом миграции

Перед тем как спорить, что лучше - модульный монолит или микросервисы, зафиксируйте базовые вещи. Этот чек-лист помогает не начать «переезд», а потом внезапно выяснить, что цели разные, данные никто не трогать боится, а откаты делать нечем.

Проверьте, что у вас готово до первой задачи в бэклоге:

• Сформулированы 3-5 целей в измеримых терминах: релизы раз в неделю вместо раз в месяц, меньше инцидентов, изоляция рисков при изменениях, снижение времени восстановления.
• Есть карта доменов и список модулей с владельцами: кто принимает решения, кто отвечает за качество, кто дежурит при сбоях.
• Заданы правила зависимостей между модулями и они проверяются сборкой: запрещенные прямые импорты, доступ к базе только через слой, тесты на границы модулей.
• Выбран пилотный кандидат и критерии успеха: небольшой, но важный модуль с понятными входами и выходами; заранее решено, что считается победой и что станет стоп-сигналом.
• Настроен минимальный набор наблюдаемости и отката: метрики по ошибкам и задержкам, централизованные логи, алерты и понятная процедура отката версии без ручной паники.

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

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

Пример сценария: как компания переходит по частям

Представьте корпоративную систему, где есть заявки от сотрудников, согласование договоров, платежи, отчеты для руководства и уведомления. Все живет в одном приложении. Формально это монолит, но внутри много «модулей», которые постоянно цепляются друг за друга.

Проблема проявляется не в коде, а в темпе. Релизы выходят раз в квартал, потому что любое изменение в заявках неожиданно ломает отчеты, а правка в платежах требует синхронизации сразу трех команд. В итоге все боятся трогать систему и копят задачи.

Команда решает не спорить абстрактно про модульный монолит или микросервисы, а начать с границ. За 3-4 недели они превращают текущий монолит в модульный монолит «по-настоящему»: описывают домены (заявки, договоры, платежи, отчеты, уведомления), фиксируют правила зависимостей и назначают владельцев модулей. Параллельно вводят правило: межмодульные вызовы только через публичные интерфейсы, без прямого доступа к таблицам «соседа».

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

Чтобы понять, что переход дает эффект, заранее выбирают метрики и фиксируют базовую точку:

• время от задачи до продакшена (lead time)
• число инцидентов после релиза
• время отката или отключения функции
• количество блокировок между командами

Через 3 месяца успех выглядит просто: один сервис (например, уведомления) выпускается независимо раз в неделю, а в монолите становится меньше «сквозных» правок. Команды спорят меньше, потому что видят цифры, а не обещания.

Следующие шаги: как начать без остановки бизнеса

Начните не с технологий, а с реальных болей. Соберите 5-10 конкретных проблем: релизы слишком редкие, изменения ломают соседние функции, разные команды мешают друг другу, сложно масштабировать только один модуль, растет очередь инцидентов. Затем приложите эти боли к вашей матрице решения и проверьте, что выбранный путь лечит причины, а не симптомы.

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

Чтобы не остановить бизнес, выберите один пилот, который можно отделить с минимальным риском. Хорошие кандидаты - отчетность, уведомления, каталог справочников или отдельный интеграционный шлюз. Важно, чтобы пилот стал образцом: по нему вы закрепите стандарты, шаблоны CI/CD, подход к тестам, мониторингу и откатам.

Перед запуском пилота подготовьте базовую эксплуатацию, иначе «первая победа» превратится в рост инцидентов. Как минимум нужны наблюдаемость (метрики, логи, трассировка и понятные алерты), ресурсы (вычисления, хранилище, лимиты и план масштабирования), резервирование (бэкапы и сценарии восстановления), безопасные релизы (быстрый откат, feature flags) и ответственность (кто дежурит и кто утверждает изменения).

Практичный старт выглядит так: за 2-4 недели вы формируете карту доменов и правила модульности, параллельно поднимаете мониторинг и окружения, а затем делаете один пилотный компонент «по-взрослому». Если не хватает экспертизы в архитектуре, интеграциях и инфраструктуре, в корпорациях часто подключают системного интегратора. Например, GSE.kz (gse.kz) сочетает интеграцию с поставкой и поддержкой корпоративной инфраструктуры, включая серверы и рабочие станции, чтобы пилот сразу работал в условиях, близких к продакшену.