Главная · Backend
Backend

модульный монолит или микросервисы: что выбрать команде

3DH.su3DH.su 8 июня 2026 5 мин чтения
модульный монолит или микросервисы: что выбрать команде

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

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

Ловушка «масштабируемости»

Прежде чем выбирать инструмент, нужно понять, что именно мы масштабируем. В индустрии путают два разных понятия:

  1. Техническое масштабирование (способность системы выдерживать миллионы RPS).
  2. Организационное масштабирование (способность 100 разработчиков писать код, не мешая друг другу).

Микросервисы решают вторую проблему гораздо лучше первой. Если у вас команда из 5-10 человек, внедрение микросервисов создаст столько накладных расходов на инфраструктуру, что скорость разработки упадет в разы. Вы будете тратить 40% времени не на фичи, а на борьбу с «сетью».

Что такое модульный монолит на самом деле?

Многие ошибочно приравнивают монолит к «большому комку грязи» (Big Ball of Mud), где всё перемешано, а изменение в модуле оплаты внезапно ломает модуль рассылки писем. Но модульный монолит — это принципиально другой подход.

Это приложение, которое развернуто как единый процесс (один бинарный файл, одна база данных), но внутри строго разделено на независимые модули. Каждый модуль имеет:

    • Свой собственный API для взаимодействия с другими частями системы.
    • Свою внутреннюю логику, скрытую от внешнего мира.
    • (В идеале) Свою схему данных, к которой никто другой не имеет прямого доступа.

По сути, это микросервисы, которые живут в одном процессе и общаются через вызовы функций в памяти, а не через HTTP или очереди сообщений.

Микросервисы: когда это оправдано?

Я не буду говорить, что микросервисы — это зло. Это мощный инструмент, но он имеет очень высокую «цену входа». Переходить на них стоит только в следующих случаях:

  1. Разные требования к ресурсам. Например, один модуль занимается тяжелой обработкой видео (нужны GPU и много RAM), а другой — простой записью логов (нужен минимум ресурсов).
  2. Разный стек технологий. Вам нужно написать один сервис на Go для высокой производительности, а другой на Python для ML-моделей.
  3. Огромная команда (от 50+ человек). Когда координация правок в одном репозитории превращается в ад из конфликтов слияния (merge conflicts) и бесконечных ожиданий в CI/CD пайплайне.
  4. Независимый цикл релизов. Когда отдел логистики должен выкатывать обновления 10 раз в день, а отдел финансовой отчетности — раз в месяц, и они не должны зависеть друг от друга.

Сравнение подходов: прагматичный взгляд

Давайте разберем основные аспекты выбора по пунктам.

1. Сложность разработки и отладки

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

    • Распределенная трассировка (Jaeger, Zipkin).
    • Централизованный сбор логов (ELK или Grafana Loki).
    • Понимание того, что сеть нестабильна (таймауты, ретраи, Circuit Breaker).

2. Целостность данных и транзакции

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

3. Стоимость владения (TCO)

Микросервисы требуют отдельной инфраструктуры для каждого сервиса: мониторинг, CI/CD пайплайны, секреты, конфигурации. Каждый новый сервис — это новые расходы на DevOps. Модульный монолит требует одного пайплайна и одного мониторинга.

Почему модульный монолит — лучший старт?

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

  1. Быстрый Time-to-Market. Вы фокусируетесь на бизнесе, а не на инфраструктуре.
  2. Легкость рефакторинга. Передвинуть границу между модулями внутри одного проекта — это дело одного дня. Перенести функционал из одного микросервиса в другой — это переписывание API, миграция данных и перенастройка сети.
  3. Путь к миграции. Если ваш модульный монолит спроектирован правильно (с четкими границами), то выделение отдельного модуля в отдельный микросервис в будущем займет минимум усилий. Вы просто выносите код в новый репозиторий и меняете вызов функции на HTTP-запрос.

Чек-лист для выбора архитектуры

Чтобы определиться, ответьте честно на следующие вопросы:

Сколько у нас разработчиков?

    • До 20 человек $\rightarrow$ Модульный монолит.
    • Больше 50 человек $\rightarrow$ Рассмотрите микросервисы.

Насколько четко определены границы доменных областей?

    • Мы еще экспериментируем и меняем бизнес-логику $\rightarrow$ Модульный монолит (границы будут меняться, и в монолите это дешево).
    • Домены стабильны и не пересекаются $\rightarrow$ Микросервисы.

Есть ли у нас выделенная команда DevOps?

    • Нет, разработчики сами настраивают сервер $\rightarrow$ Модульный монолит.
    • Да, у нас есть профи, которые настроят K8s и Service Mesh $\rightarrow$ Микросервисы.

Критична ли для нас абсолютная доступность отдельных частей системы?

    • Если упадет всё — не страшно, починим за 5 минут $\rightarrow$ Модульный монолит.
    • Если упадет модуль аналитики, поиск и оплата должны продолжать работать $\rightarrow$ Микросервисы.

Итог: стратегия выживания

Мой совет как архитектора: начинайте с модульного монолита. Инвестируйте время не в Kubernetes, а в чистоту архитектуры. Используйте принципы Domain-Driven Design (DDD), выделяйте контексты, запретите прямые обращения к таблицам соседних модулей.

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

Выбирайте инструмент под свои задачи, а не под модные статьи в блогах крупных тех-гигантов. Google и Netflix используют микросервисы не потому, что это «лучше», а потому, что у них десятки тысяч инженеров и нагрузки, которые невозможно обработать иначе. Для 95% компаний модульный монолит будет более эффективным, дешевым и быстрым решением.