Монолит или микросервисы: критерии выбора для нового и действующего продукта
Команда обсуждает новый модуль, а разговор быстро переходит к архитектуре. Один участник предлагает отдельный сервис «с запасом на рост», второй хочет сохранить единое приложение, третий уже рисует очередь событий. Решение принимается до того, как продукт показал реальные границы.
Выбор между монолитом и микросервисами зависит от домена, нагрузки, организации команд и требований к релизам. Популярность подхода мало помогает: по опросу CNCF Q3 2025 микросервисы использовали 46% backend-разработчиков из выборки 2 790 человек. Это говорит о распространённости, но ничего не решает за конкретный продукт.
У нового продукта границы домена ещё двигаются
На старте команда уточняет сущности, правила и связи между ними. Сегодня оплата выглядит самостоятельным модулем, завтра скидка зависит от роли клиента и состава заказа, послезавтра возврат меняет бонусный баланс. Раннее разделение на сервисы закрепляет предположения в API, очередях и отдельных хранилищах.
Для большинства новых продуктов разумной исходной точкой становится модульный монолит: одно развёртываемое приложение с явными внутренними границами. Модули получают собственную ответственность и интерфейсы, а прямой доступ к их внутренним данным ограничивается. Команда сохраняет возможность менять модель без сетевого протокола между каждой частью.
Монолит здесь означает способ развёртывания, а не отсутствие структуры. Кодовая база может быть разделена по доменам, покрыта тестами и собрана в независимые модули. Плохая связанность встречается в любой архитектуре. Сеть лишь делает её дороже для диагностики.
Исключения появляются, когда граница известна заранее. Например, компонент имеет отдельный профиль нагрузки, требования к изоляции или независимую команду с собственным циклом релизов. Тогда отдельный сервис решает конкретную задачу с первого дня.
Микросервис добавляет независимость вместе с новым контуром эксплуатации
Сервис выпускается и масштабируется отдельно. За эту свободу продукт платит сетевыми вызовами, версионированием контрактов, наблюдаемостью, управлением секретами, отдельными пайплайнами и сценариями частичного отказа.
Azure Architecture Center прямо предупреждает: отдельные компоненты становятся проще, а система целиком получает больше движущихся частей. Там же зрелая DevOps-культура названа условием успешной микросервисной архитектуры, а согласованность данных — одной из основных сложностей.
Поэтому сравнивать нужно не количество строк кода. Вопрос звучит так: получит ли бизнес ценную независимость и готова ли команда обслуживать распределённую систему.
Семь критериев показывают цену каждого варианта
| Критерий | Сигнал в пользу модульного монолита | Сигнал в пользу микросервисов |
|---|---|---|
| Границы домена | Правила часто меняются, модули ещё ищут ответственность | Бизнес-возможности устойчивы и имеют ясные контракты |
| Команды | Одна или несколько тесно связанных команд | Автономные команды владеют сервисами от кода до эксплуатации |
| Релизы | Общий ритм не мешает продукту | Один контур должен выпускаться независимо и заметно чаще |
| Нагрузка | Компоненты растут примерно вместе | Отдельная функция требует собственного масштабирования |
| Данные | Много атомарных операций между модулями | Данные делятся по устойчивым владельцам, допустима согласованность во времени |
| Надёжность | Единый процесс упрощает транзакции и диагностику | Нужна изоляция отказа, а команда умеет работать с деградацией зависимостей |
| Эксплуатация | Платформа и наблюдаемость ещё развиваются | Есть автоматические релизы, трассировка, алерты, управление секретами и on-call |
Один сильный сигнал редко решает всё. Высокая нагрузка на продукт не требует делить каждый модуль. Иногда достаточно масштабировать монолит горизонтально, вынести фоновые задания или оптимизировать хранилище. Микросервис оправдан, когда отдельный контур действительно выигрывает от собственной модели нагрузки и релизов.
Общая транзакция часто удерживает модули вместе
В монолите несколько изменений объединяются в одну транзакцию базы данных. В микросервисах каждый участник обычно владеет своим хранилищем. Операция «создать заказ, зарезервировать товар и списать бонусы» превращается в последовательность сообщений и компенсаций.
Распределённая схема требует идемпотентности, журналов, повторной доставки и обработки промежуточных состояний. Заказ способен сохраниться, пока резерв ещё ожидает подтверждения. Интерфейс и поддержка должны понимать это состояние, а не показывать пользователю случайный результат последнего ответа.
Если бизнес требует строгой атомарности между сущностями и граница постоянно пересекается, разнос по сервисам создаёт постоянный налог. Это сигнал пересмотреть разделение. Сервисная автономность начинается с владения данными, а не с отдельного репозитория.
Независимый релиз должен быть реальным, а не формальным
Главное обещание микросервисов — изменение одного сервиса без синхронного выпуска остальных. Для этого контракт остаётся совместимым, потребители обновляются в своём темпе, а команда умеет поддерживать несколько версий на период перехода.
Если релиз требует собрать общий чат, обновить пять сервисов в строгом порядке и остановить трафик, независимость осталась на диаграмме. То же касается общей базы: изменение таблицы одним сервисом способно сломать остальные, даже когда у каждого свой контейнер.
Перед выделением проводят простой тест. Команда описывает изменение API, обновление данных, развёртывание, наблюдение и откат. Если большую часть шагов всё равно выполняют совместно, граница пока не приносит ожидаемой пользы.
Распределённый монолит собирает недостатки двух подходов
Распределённый монолит состоит из отдельных процессов, которые не умеют жить независимо. Сервисы делят базу, вызывают друг друга по длинной синхронной цепочке и выпускаются одним пакетом. Сеть уже добавила задержки и частичные отказы, а автономности ещё нет.
В материале об IT-аудите мы сформулировали эту позицию прямо: хорошо разделённый модульный монолит бывает предсказуемее набора сервисов с общей базой и частыми взаимными вызовами. Название архитектуры не заменяет границы ответственности.
Признаки распределённого монолита видны в работе команды:
- небольшое изменение проходит через несколько репозиториев и владельцев;
- сервисы читают и меняют чужие таблицы;
- локальный запуск требует поднять почти всю систему;
- ошибка одного вызова обрывает длинную цепочку;
- версию контракта меняют одновременно у всех потребителей.
В такой ситуации добавление новых сервисов расширяет поверхность сбоя. Сначала нужно сократить связанность и определить владельцев данных.
Действующий продукт делят по боли, которую можно измерить
Переписывать монолит целиком рискованно. Рабочий продукт продолжает получать функции, исправления и данные, пока новая архитектура догоняет его. Гораздо безопаснее выбрать один контур с понятной причиной для выделения.
Сильные кандидаты обычно имеют хотя бы один измеримый конфликт: их нагрузка заметно отличается от остального приложения, общий релиз задерживает изменения, сбой должен оставаться локальным, технология ограничивает развитие или отдельная команда уже владеет бизнес-возможностью.
Сначала модуль отделяют внутри существующего кода: фиксируют интерфейс, закрывают прямой доступ к данным, добавляют наблюдаемость и тесты контракта. Этот этап показывает реальную границу дешевле сетевой миграции. Если модуль продолжает тянуть десятки внутренних зависимостей, сервис пока рано выносить.
После этого можно применить strangler fig. AWS описывает паттерн как постепенную замену функций: слой маршрутизации направляет вызов в монолит или новый сервис, а оба контура некоторое время сосуществуют. Для глубоких зависимостей может понадобиться промежуточная абстракция внутри приложения.
Первый сервис выбирают по ясной границе, а не по простоте кода
Самый маленький модуль не всегда лучший пилот. Важно, чтобы у него были понятный владелец, отдельные данные или устойчивый контракт, самостоятельный способ проверки и ограниченный радиус ошибки.
Для пилота заранее фиксируют результат. Например, команда выпускает компонент без общего релиза, масштабирует его независимо или изолирует конкретный сбой. После запуска сравнивают не впечатление от новой технологии, а время поставки, число координаций, инциденты и трудозатраты на эксплуатацию.
Нужно учитывать обратную сторону. Один сервис требует собственного мониторинга, алертов, управления доступами, резервного копирования и процедуры отката. Если команда не готова нести эти обязанности, пилот проверит инфраструктуру, но не бизнес-гипотезу.
Две строки помогают принять решение
Для нового продукта выбирайте модульный монолит, пока доменные границы меняются и общий релиз не мешает командам. Сервис выделяйте там, где уже доказана потребность в независимом владении, масштабировании или выпуске.
Для действующего продукта начните с конкретного ограничения. Отделите модуль внутри кода, проверьте контракт и данные, затем переносите его постепенно. Массовое дробление по техническим слоям редко создаёт автономность.
Короткое правило: микросервис нужен, когда независимость конкретного контура приносит больше пользы, чем стоит его отдельная эксплуатация.
Если архитектура уже ограничивает релизы или рост, мы можем провести аудит системы и собрать план изменений — от укрепления модульного монолита до поэтапного выделения сервисов.
