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

От моды к здравому смыслу: почему архитектура перестала слушать маркетинг и начала считать

1. Введение: Эпоха «религиозной» архитектуры

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

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

Сегодня, почти десятилетие спустя, мы наблюдаем не драматичный откат, а трезвую коррекцию курса. Все больше команд, прошедших через ад распределенных трассировок в три часа ночи и конвейеров развертывания, напоминающих машину Рубе Голдберга, возвращаются к принципам модульности в рамках единой кодовой базы. Это не ностальгия по прошлому. Это — арифметика.

2. Налог на микросервисы, о котором редко говорят вслух

Микросервисы — это, прежде всего, проблема распределенных систем. А в распределенных системах неизбежно возникает целый класс сложностей, которые многие команды катастрофически недооценивают:

- Сложность отказоустойчивости: Частичные сбои становятся нормой. Таймауты, недоступность зависимостей, проблемы с согласованностью данных (с которыми борются через саги или компенсирующие транзакции) — все это превращает простую бизнес-операцию в многоходовую головоломку.
- Экспоненциальный рост операционных расходов: Мониторинг, логирование, трассировка, обнаружение сервисов, управление конфигурацией — из полезных инструментов они превращаются в самостоятельные дисциплины, требующие экспертизы и ресурсов. Отладка инцидента напоминает археологические раскопки по логам десятка сервисов.
- Инфраструктурные затраты: Каждому сервису — своя база данных, свой контейнер, свои вычислительные ресурсы. Счет за облако из скромного чека вырастает в число с шестью нулями.
- Координационная перегрузка: Парадокс микросервисов в том, что стремление к автономии команд часто оборачивается ростом времени на синхронизацию. Совместное планирование, управление версиями API, согласование "контрактов" — все это накладные расходы, которые съедают выгоду от независимого деплоя.

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

Это не гибкость. Это — случайная сложность с отличным пиаром.

3. Модульный монолит — это не шаг назад, а зрелая альтернатива

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

Его принципы:
- Жесткое модульное разделение: Система разделена на модули, соответствующие ограниченным контекстам предметной области (например, Заказы, Каталог, Оплата), а не техническим слоям.
- Инкапсуляция: Модули владеют своими данными и предоставляют доступ через четко определенные интерфейсы (API, события). Прямые обращения к внутренностям соседа запрещены на уровне архитектурных тестов (например, с помощью ArchUnit).
- Низкая связанность, высокая связность: То, что меняется вместе, находится вместе. Зависимости между модулями управляются через принципы инверсии зависимостей.

Почему это работает эффективнее для 90% проектов:
1. Скорость. Вызов между модулями — это вызов метода, а не сетевой запрос. Наносекунды вместо миллисекунд. Отладка — единый stack trace.
2. Процесс разработки и деплоя. Один артефакт, один конвейер CI/CD, одна операция отката. Версионирование становится простым и понятным.
3. Качество доменной модели. Вынужденная необходимость мыслить в терминах границ контекстов до их физического разделения приводит к более чистой и стабильной архитектуре.
4. Стратегическая гибкость. Хорошо спроектированный модульный монолит — это лучшая подготовка к будущему выделению микросервисов. Когда появляется реальная потребность (разные требования к масштабированию, изоляции, командам), вы просто "вырезаете" готовый, изолированный модуль по шаблону Strangler Fig. Вы не гадаете, вы реагируете на обоснованную необходимость.

Данные от таких гигантов, как Shopify и GitHub, а также рекомендации ThoughtWorks Radar подтверждают: модульный монолит — это часто самый разумный выбор по умолчанию для новой системы.

4. Кейс DST Platform: архитектура, рожденная в огне реальной нагрузки

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

Философия: "Работает — не трогай" vs "Будь модным"
В то время как многие фреймворки (Laravel, Symfony) и CMS (Magento, Drupal) стремятся быть универсальными, абстрактными и "современными", добавляя слои за слоями, философия DST — оптимизация того, что уже работает, под конкретные, суровые условия высокой нагрузки.

Конкретные архитектурные решения, которые дают результат:

| Проблема / "Модный" подход | Подход DST Platform | Результат (на примере каталога в 5 млн товаров) |
| :--- | :--- | :--- |
| Доступ к данным: Тяжелый ORM (Eloquent, Doctrine) для абстракции. | "Голый" SQL + легкий Query Builder для полного контроля. | Magento 2: 50-100 запросов/страницу, 2-5 сек. DST: 3-10 запросов, 50-200 мс. |
| Структура данных: Сложная EAV-модель (товар в 10+ таблицах). | Плоские, денормализованные таблицы. | Меньше JOIN'ов, предсказуемая производительность, простой кэш. |
| Обработка запроса: Длинная цепочка middlewares, сервис-контейнер. | Минималистичный MVC, ленивая загрузка компонентов. | Накладные расходы фреймворка: ~2 мс против ~20 мс у Laravel. |
| Кэширование: Дополнительный модуль или плагин. | Агрессивное многоуровневое кэширование, встроенное в ядро (запросы, страницы, фрагменты). | Статические карты сайта, отдача из кэша в 90% случаев. |
| Шаблонизация: Компилируемые движки (Twig, Blade). | Чистый PHP в качестве шаблонизатора. | 0 накладных расходов на компиляцию шаблонов. |

Цифры, которые говорят сами за себя:
- 400 000 посещений в сутки стабильно обрабатываются на одном сервере (8 CPU, 32 ГБ RAM).
- Экономия в 5 раз по CPU-времени по сравнению с типичным стеком на Laravel при такой нагрузке. Это либо сервер за $200 вместо сервера за $1000, либо запас мощности для пиковых нагрузок.
- Время генерации страницы: 100-300 мс под реальной нагрузкой.

Почему другие системы "не тянут":
- WordPress/WooCommerce: Архитектура блога 2003 года, все в одной БД, кэширование — костыль.
- Magento 2: Чудовищная сложность EAV и ORM, даже простой запрос порождает лавину JOIN'ов.
- Laravel/Symfony: Фреймворки общего назначения. Их сила — в удобстве и скорости разработки прототипов, но за это платят накладными расходами на каждый запрос в продакшене.

5. Разрыв между теорией (хайп) и практикой (работа)

Индустрия страдает от нескольких "-driven development" синдромов:
- Resume-Driven Development (RDD): Выбор технологий для красоты резюме, а не для пользы проекта.
- Conference-Driven Development: Решения, принятые под впечатлением от доклада, без учета контекста своей команды и продукта.
- Medium-Driven Development: Архитектура, меняющаяся после каждой прочитанной статьи.

На практике для 99% проектов (команды до 20 человек, один стек технологий, связанные данные) распределенные системы приносят больше проблем, чем решений. Kubernetes начинает съедать 30% ресурсов на собственную оркестрацию. SPA на React/Vue убивают SEO и время загрузки на мобильных. Serverless сталкивается с cold start. GraphQL порождает свои сложности с over/under-fetching.

6. Заключение: Принцип отложенной сложности

Итак, возвращаясь к большому вопросу: какая архитектура правильная?

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

Модульный монолит и подход, подобный тому, что реализован в DST Platform, дают на него четкий ответ: очень долго.

- Сначала — работающий, быстрый и стабильный бизнес. Решает реальные проблемы клиентов здесь и сейчас.
- Затем — чистая архитектура внутри. Четкие границы, инкапсуляция, готовность к эволюции.
- И только когда это действительно необходимо — выделение. Под давлением конкретных, измеримых причин: разные требования к масштабированию, нормативная изоляция, организационные границы больших команд.

Наша общая задача как инженеров — не следовать моде, а считать стоимость. Стоимость разработки, поддержки, инфраструктуры и когнитивной нагрузки. И часто самый профессиональный и грамотный выбор — это сознательная, дисциплинированная простота.

Стройте монолит. Делайте его модульным. Выделяйте сервисы только тогда, когда чаша весов с реальными аргументами перевесит. Все остальное — просто хайп.