Архитектурные компромиссы
Микросервисы против монолита: критерии выбора
1. Критерии сравнения
Выбор между монолитом и микросервисами часто сводят к моде, а решение должно строиться на конкретных условиях. Оценивать нужно по пяти критериям, от которых зависит реальная стоимость владения:
- Размер команды. Сколько людей ведут систему и смогут разделиться на автономные команды.
- Скорость изменений. Как часто правятся разные части продукта и конфликтуют ли они между собой.
- Нагрузка и рост. Требуется ли горизонтальное масштабирование отдельных сервисов.
- Отказоустойчивость. Насколько критичен отказ одного модуля для работы остальных.
- Бюджет и сложность поддержки. Сколько стоят инфраструктура, наблюдаемость и DevOps-процессы.
По каждому критерию монолит и микросервисы дают разный результат. Ниже — сравнительная таблица и условия, при которых один подход выигрывает у другого.
2. Сравнительная таблица
| Параметр | Монолит | Микросервисы |
|---|---|---|
| Разработка и старт | Быстрый, один репозиторий, один деплой | Медленнее: контракты, инфраструктура, оркестрация |
| Скорость изменений | Один конфликт-код, полный тест | Каждый сервис меняется независимо |
| Масштабирование | Всё вместе, «упирается» всё разом | Точечно по самому нагруженному сервису |
| Отказоустойчивость | Отказ одной части может лечь на всё | Изолированный сбой, влияние ограничено |
| Команда и роли | Одна команда, меньше коммуникации | Автономные команды на сервис |
| Стоимость инфраструктуры | Ниже, проще и предсказуемее | Выше: оркестрация, сеть, наблюдаемость |
| Инструментарий | Проще: мониторинга и CI/CD меньше | Сложнее: сервис-меш, трейсинг, метрики, логи |
Из таблицы видно: микросервисы выигрывают на масштабируемости и отказоустойчивости, но проигрывают по стартовой сложности и стоимости владения. Монолит — наоборот: быстро и дёшево в начале, но дороже при росте команды и нагрузке.
3. Когда выбирать монолит / микросервисы
- Монолит — если команда 2–8 человек, продукт меняется в основном одним модулем, нагрузка предсказуема и редко требует точечного масштабирования. Отказываться от монолита из-за «модного слова» — ошибка.
- Микросервисы — если команда большая и делится на автономные группы, продукт — набор независимых доменов, а нагрузка на один сервис растёт в разы быстрее остальных. Тогда точечное масштабирование и изоляция сбоев окупаются.
- Гибрид/модульный монолит — практичный промежуточный вариант. Один репозиторий, но чёткие границы внутри: модули, которые потом легко вынести в сервисы. Это снижает риск переходить на микросервисы «в лоб».
Важно: микросервисная архитектура — про границы и контракты, а не про количество сервисов. Раздробить приложение на 30 «микросервисов» внутри одной команды — это распределённый монолит: плюсы потеряны, сложность осталась.
Три уточняющих вопроса перед решением:
- Будет ли нагрузка расти по-разному по модулям? Если всё растёт одинаково — монолит не хуже.
- Сколько людей автономно работают над разными доменами? Меньше трёх команд — микросервисам сложно оправдать себя.
- Какой допустим простой? Если простоя быть не должно, микросервисы и изоляция сбоев дают преимущество.
4. Выгоды и риски по сегментам
Интегратор. Выгода — возможность подключать разных заказчиков к отдельным сервисам и масштабировать их независимо. Риск — нужно содержать инфраструктуру оркестрации и наблюдаемость, что не каждый заказчик готов оплачивать. При несогласованности получается «куча сервисов без документации».
ГБ / корпорация. Выгода — автономные команды, изоляция сбоев, независимый деплой. Риск — рост стоимости и сложности, необходимость в большой инфраструктурной базе и сильном DevOps. Микросервисы оправданы при большом ландшафте приложений, а не для одного сервиса.
Госзаказчик. Выгода — точечное обновление и масштабирование без остановки всей работы. Риск — соответствие требованиям: инфраструктура должна быть из реестра Минпромторга, а обоснование закупки по 44-ФЗ/223-ФЗ — грамотно оформлено. Иначе сложность микросервисов станет преградой для согласования. Порядок разобран в Как перейти на отечественное оборудование. Нужное под каждый сервис железо удобно подбирать по сегментам: российские серверы — под приложение и узлы БД.
4.1 Типовые ошибки при переходе
| Ошибка | Причина | Решение |
|---|---|---|
| Дробление «в лоб» без границ | Мода, а не доменное прочерчивание | Выносить по одному явно перегруженному домену |
| Слишком много «сервисов» | Путаница «микросервис» и «модуль» | Держать число = числу автономных команд |
| Пропуск наблюдаемости | Сервисов больше — сбои сложнее видеть | Метрики, логи, трейсинг с первого сервиса |
| Отказ от монолита без запроса | Решение от продукта, а не от нагрузки | Фиксировать нагрузку и проверять, где боль |
| Распределённый монолит | Сервисы порознь, а деплой вместе | Развалить связность, а не только код |
5. Итог и рекомендация
- Начинайте с монолита или модульного монолита, если нет явного признака роста и больших команд.
- Переходите на микросервисы по одному домену, а не «всё разом», ориентируясь на точки, где нагрузка или команда упирается.
- Выносите только то, что реально даст выигрыш — иначе останетесь с распределённым монолитом и полным набором его минусов.
Ключевой совет: сначала нагрузка и команда, потом архитектура. Число сервисов — следствие ограничений, а не цель. Определившись со структурой, фиксируйте связи между сервисами, потому что именно там живёт будущая сложность. Как решать эту часть — в архитектуре ПО.
Если же микросервисы выбраны, узлы под них подбираются расчётом. Каждый сервис можно масштабировать отдельно — значит, масштабирование и балансировка становятся штатным инструментом.
6. Вопросы и ответы
Микросервисы всегда лучше монолита? — Нет. Они окупаются при большой команде и выраженной разнице в нагрузке. В остальных случаях монолит проще, дешевле и надёжнее.
Когда точно пора дробить монолит? — Когда один модуль упирается в нагрузку отдельно от остальных, или когда несколько команд конфликтуют в одном репозитории, замедляя релизы.
Что такое «распределённый монолит»? — Это когда сервисов много, но они всё равно связаны и деплой происходит вместе. Плюсы микросервисов теряются, а сложность остаётся.
Сколько сервисов должно быть? — Столько, сколько границ доменов и автономных команд. Число «для красоты» — антипаттерн.
Частые вопросы
Микросервисы всегда лучше монолита?
Нет. Они окупаются при большой команде и выраженной разнице в нагрузке. В остальных случаях монолит проще, дешевле и надёжнее.
Когда точно пора дробить монолит?
Когда один модуль упирается в нагрузку отдельно от остальных, или когда несколько команд конфликтуют в одном репозитории, замедляя релизы.
Что такое «распределённый монолит»?
Это когда сервисов много, но они всё равно связаны и деплой происходит вместе. Плюсы микросервисов теряются, а сложность остаётся.
Сколько сервисов должно быть?
Столько, сколько границ доменов и автономных команд. Число «для красоты» — антипаттерн.