Перейти на PRO

Монолитный код все еще актуален, или будущее за микросервисами?

Тип вопроса: Архитектура Вероятность: 28% Категория: PHP Разработчик

Ответ

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

Я выбираю монолит, когда:

  • Команда небольшая (1-3 разработчика), а скорость — критична. На старте проекта накладные расходы на развертывание, мониторинг и отладку распределённой системы убивают скорость разработки.
  • Предметная область (domain) тесно связана. Если сущности в системе (например, User, Order, Invoice) постоянно взаимодействуют, разделение их по сервисам создаст больше проблем (сетевые вызовы, distributed transactions), чем решит.
  • Требования к производительности крайне высоки. Локальные вызовы внутри монолита всегда быстрее сетевых RPC между микросервисами.

Пример современного монолита (Java/Spring): Чётко модульная структура внутри одной кодовой базы и одного deployable artifact.

monolith-app/
├── src/main/java/com/example/
│   ├── user/          # Модуль пользователей
│   ├── order/         # Модуль заказов
│   ├── billing/       # Модуль биллинга
│   └── shared/        # Общие DTO, утилиты
└── pom.xml            # Один артефакт, один деплой

Я перехожу к микросервисам, когда:

  • Разные части системы имеют принципиально разные требования к масштабированию. Например, сервис генерации PDF-отчётов требует много CPU, а сервис аутентификации — нет. Их можно масштабировать независимо.
  • Команды большие и автономные. Каждая команда может владеть своим сервисом, выбирать свой стек технологий и цикл разработки.
  • Требуется повышенная отказоустойчивость. Падение одного сервиса не должно валить всю систему.

Вывод: Начинать с монолита — это не технический долг, а часто лучшая практика. Микросервисы — это дорогое архитектурное решение, которое должно быть принято осознанно, когда преимущества перевешивают операционные издержки. Модульный монолит (Modulith) — отличный компромисс, позволяющий позже относительно безболезненно выделить модули в отдельные сервисы, если потребуется.

Ответ 18+ 🔞

Да ты послушай, что эти архитектурные гуру несут! Все как с цепи сорвались — микросервисы, микросервисы... А монолит, блядь, объявили реликтом, как будто на дворе 2002-й год. Так вот, ебать мои старые костыли, слушай сюда: монолит — это часто самый адекватный и прагматичный выбор, а не какой-то позорный компромисс.

Вот когда я беру монолит и ни секунды не сомневаюсь:

  • Команда — три с половиной человека, а надо вчера. Пока ты будешь настраивать кубер, оркестрацию, логи и трассировку для десятка сервисов, проект уже накроется медным тазом. Накладные расходы просто съедают всю скорость, это пиздец.
  • Вся предметная область — один большой комок. Ну представь: Пользователь, Заказ, Счёт. Они друг без друга нихуя не смыслят, постоянно дергают друг друга за данные. Зачем их раскидывать по сервисам? Чтобы потом мучиться с сетевыми вызовами и distributed транзакциями? Да иди ты нахуй с такими микросервисами.
  • Надо, чтобы всё летало. Локальный вызов в памяти — он всегда, сука, быстрее, чем RPC через сеть, даже по HTTP/2. Это аксиома, ёпта.

Как выглядит современный монолит? Да не куча спагетти в одном файле! Это чёткая модульная структура, но в одном артефакте.

monolith-app/
├── src/main/java/com/example/
│   ├── user/          # Отдельный модуль, своя зона ответственности
│   ├── order/         # Всё своё, но внутри одного приложения
│   ├── billing/       # Никакой магии, просто пакеты
│   └── shared/        # Общие штуки, которые все используют
└── pom.xml            # Собрал один jar — и на прод. Красота.

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

  • Части системы живут абсолютно разной жизнью. Один сервис — генератор PDF, жрёт CPU как не в себя, а другой — простенький апишка для формы. Их масштабировать по-разному надо. Вот тут разделение имеет смысл.
  • Команд разрослось овердохуища, и они хотят независимости. Пусть одна команда пишет на Go, другая на Java, и деплоят когда хотят. Автономия, блядь.
  • Нужна отказоустойчивость. Чтобы если один сервис лег, остальные хотя бы частично работали. В монолите упало одно — падает всё, тут без вариантов.

Так что вывод-то какой? Начинать с монолита — это не технический долг, а часто гениальное решение. Это как взять отвёртку, а не целый фургон инструментов для того, чтобы повесить полку. Микросервисы — это дорогущая архитектура, оправданная только тогда, когда её сложность реально окупается. А модульный монолит — это хитрая жопа, которая даёт тебе все плюшки структуры, но оставляет дверь открытой. Захотел позже выделить модуль в сервис — пожалуйста, без этой вселенской боли рефакторинга. Прагматизм, ёпта, а не религия.

Видео-ответы

© ХакСобесов, 2026
support@hacksobesov.com