МОНОЛИТ ИЛИ МИКРОСЕРВИСЫ: КОГДА ПОРА РАЗДЕЛЯТЬ ПРИЛОЖЕНИЕ

MONOLITH OR MICROSERVICES: WHEN IS IT TIME TO SPLIT AN APPLICATION

Kladovshikov Dmitry Andreevich

Master's student, Department of Information Systems, Moscow State University of Technology "STANKIN",

Russia, Moscow

АННОТАЦИЯ

В статье рассматривается вопрос выбора архитектурного подхода при разработке веб-приложений: монолитная архитектура и микросервисная. Описываются признаки, при которых монолит перестаёт справляться с растущей нагрузкой и усложняет командную разработку. Рассматриваются основные преимущества и практические риски перехода на микросервисы, критерии принятия решения о декомпозиции, а также типичные сценарии, в которых такой переход оправдан с точки зрения затрат и выгод.

ABSTRACT

The article considers the choice between monolithic and microservice architectures in web application development. It describes the signs indicating that a monolith is struggling with load and complicating team development. The main advantages and practical risks of migrating to microservices are examined, along with decision criteria for decomposition and typical scenarios where such a transition is justified from a cost-benefit perspective.

Ключевые слова: монолитная архитектура; микросервисы; масштабирование; декомпозиция; программная инженерия; веб-приложение.

Keywords: monolithic architecture; microservices; scalability; decomposition; software engineering; web application.

Когда разработчик создаёт своё первое приложение – блог, интернет-магазин или корпоративный портал – он, как правило, пишет весь код в одном проекте. Один сервер, одна база данных, один деплой. Такой подход называют монолитной архитектурой, и поначалу он работает отлично: всё просто, понятно и быстро развёртывается.

Монолит – это архитектурный стиль, при котором всё приложение упаковано в единый исполняемый модуль. Пользовательский интерфейс, бизнес-логика и слой доступа к данным живут вместе и запускаются как одно целое [1]. Для небольших команд и молодых продуктов это удобно: не нужно думать об интеграции компонентов, нет накладных расходов на сеть между сервисами, а отлаживать код значительно проще – достаточно запустить одно приложение и смотреть на один журнал ошибок.

Проблемы начинаются тогда, когда приложение растёт. Команда из трёх человек превращается в тридцать, число строк кода переваливает за миллион, а любое изменение в одном модуле рискует сломать что-то совсем в другом месте. Такое явление в программировании называется «запутанностью зависимостей» или, образно, «большим комком грязи» (Big Ball of Mud) – термин, который ввели Б. Фут и Дж. Йодер [5]. Разработчик, добавляющий новую кнопку в форму оплаты, вынужден думать о том, не нарушит ли его правка логику каталога товаров – потому что всё находится в одном проекте.

Кроме проблем с кодом, монолит создаёт операционные трудности. Если нагрузка на сайт резко возрастает во время распродажи, единственный способ справиться – запустить больше копий всего приложения целиком. Это расточительно: большинство компонентов, например, административная панель или страница «О компании», не нуждаются в дополнительных ресурсах. Платить приходится за всё.

Микросервисная архитектура предполагает, что приложение разбивается на небольшие независимые сервисы, каждый из которых отвечает за свою конкретную задачу: авторизация пользователей, обработка заказов, отправка уведомлений. Каждый сервис работает в своём процессе, имеет собственную базу данных и общается с остальными через API или очереди сообщений [1]. Такой подход позволяет разным командам работать над разными сервисами независимо друг от друга.

Главное преимущество – независимость развёртывания. Если нужно обновить сервис уведомлений, не нужно трогать и перезапускать весь интернет-магазин. Более того, разные сервисы могут быть написаны на разных языках программирования: один на Python, другой на Java, третий на Go – каждый на том, который лучше подходит для конкретной задачи. Это называется полиглот-программированием – термин, предложенный Н. Фордом [8].

Независимость сервисов открывает возможность точечного масштабирования. Если каталог товаров нагружен сильнее, чем личный кабинет, можно запустить больше копий именно каталога, не трогая остальное. Современные оркестраторы контейнеров, такие как Kubernetes, позволяют делать это автоматически, реагируя на текущую нагрузку [4]. Это существенно снижает затраты на инфраструктуру по сравнению с горизонтальным масштабированием монолита.

Однако переход к микросервисам – это не бесплатное улучшение. Вместо одной сложной системы появляется много взаимодействующих систем, каждую из которых нужно мониторить, деплоить и поддерживать отдельно. Простая операция, которая в монолите занимает одну строку кода, в микросервисах может превратиться в цепочку HTTP-запросов между несколькими сервисами. Это добавляет задержку и точки отказа: если один сервис недоступен, вся цепочка может прерваться [1].

Отдельную сложность представляют распределённые транзакции. В монолите изменить запись в базе данных атомарно – тривиальная задача. В микросервисах, где у каждого сервиса своя база, согласованность данных приходится обеспечивать с помощью специальных паттернов, например Saga, что существенно усложняет код и требует дополнительных знаний от команды [3]. Сам подход восходит к концепции saga, предложенной Х. Гарсиа-Молиной и К. Салемом ещё в 1987 году [9].

Существенно возрастают и требования к инфраструктуре: нужны реестр сервисов, система централизованного логирования, трассировка запросов, API-шлюз. Для небольшой команды сопровождение всего этого хозяйства может занимать больше времени, чем разработка самих функций приложения.

Опыт трансформации реальных проектов показывает: переходить на микросервисы имеет смысл тогда, когда монолит уже «болит» – когда скорость разработки падает из-за конфликтов в коде между командами, когда сборка занимает часы, когда невозможно масштабировать отдельную часть без поднятия всего приложения. Специалисты в области программной инженерии рекомендуют начинать с монолита и переходить к декомпозиции постепенно, выделяя сервисы по мере выявления реальных узких мест. Именно такую стратегию – «сначала монолит» – отстаивает М. Фаулер [6], и схожего инкрементального подхода придерживается С. Ньюмен [2].

Если же продукт небольшой и команда маленькая, микросервисы могут принести больше сложности, чем пользы. Мартин Фаулер, один из ведущих теоретиков архитектуры программного обеспечения, называет это «надбавкой за микросервисы» (microservice premium) – дополнительными издержками сложности, которые оправдывают себя лишь при достаточном масштабе системы [7].

Таким образом, архитектурный выбор – это не вопрос «что модно», а вопрос «что решает актуальные проблемы». Монолит остаётся правильным решением для старта и для небольших систем. Микросервисы – это инструмент масштабирования, который оправдывает себя на определённой стадии роста продукта. Понимание этой границы и умение выбрать подходящий момент для перехода – один из ключевых навыков современного разработчика программного обеспечения.

Список литературы:

1. Ньюмен С. Создание микросервисов. 2-е изд. – СПб.: Питер, 2023. – 624 с.
2. Ньюмен С. От монолита к микросервисам. – СПб.: БХВ-Петербург, 2021. – 272 с.
3. Ричардсон К. Микросервисы. Паттерны разработки и рефакторинга. – СПб.: Питер, 2019. – 544 с.
4. Лукша М. Kubernetes в действии. – М.: ДМК Пресс, 2019. – 672 с.
5. Foote B., Yoder J. Big Ball of Mud // Pattern Languages of Program Design 4 / ed. by N. Harrison, B. Foote, H. Rohnert. – Addison-Wesley, 2000. – Ch. 29. – URL: http://www.laputan.org/mud/ (дата обращения: 10.06.2026).
6. Fowler M. MonolithFirst [Электронный ресурс]. – 2015. – URL: https://martinfowler.com/bliki/MonolithFirst.html (дата обращения: 10.06.2026).
7. Fowler M. MicroservicePremium [Электронный ресурс]. – 2015. – URL: https://martinfowler.com/bliki/MicroservicePremium.html (дата обращения: 10.06.2026).
8. Ford N. Polyglot Programming [Электронный ресурс]. – 2006. – URL: https://nealford.com/memeagora/2006/12/05/Polyglot_Programming.html (дата обращения: 10.06.2026).
9. Garcia-Molina H., Salem K. Sagas // Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data. – ACM Press, 1987. – P. 249–259. – DOI: 10.1145/38713.38742.