> For the complete documentation index, see [llms.txt](https://docs.system-analyst-base.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.system-analyst-base.ru/hard-skills/proektirovanie/arkhitektura/monolit.md). # Монолит {% hint style="info" %} **Монолитная архитектура** – это традиционный способ организации приложений, в котором все компоненты продукта находятся внутри одной монолитной кодовой базы и управляются как единое целое. {% endhint %}

Схематичное изображение монолитного приложения

## Преимущества монолитной архитектуры * **Простота разработки и тестирования** Монолитная архитектура проста в разработке, развертывании и обслуживании. Поскольку все компоненты являются частью единой кодовой базы, процесс разработки упрощается, и приложение можно развернуть как единое целое. Поскольку все приложение интегрировано, может быть проще выполнить сквозное тестирование для полной проверки функциональности системы. * **Меньшие накладные расходы** Запуск и обслуживание таких приложений часто дешевле, чем микросервисов, так как не требуется управление большим числом независимых сервисов. * **Производительность** Внутри монолита обмен данными между компонентами может быть более эффективным, чем в микросервисной архитектуре. Это связано с тем, что данные передаются в пределах одного процесса. ## Недостатки монолитной архитектуры * **Масштабируемость** Чаще всего такие приложения масштабируются вертикально, что означает увеличение ресурсов на одном сервере. Это может быть ограничивающим фактором при необходимости горизонтального масштабирования, особенно в случае резкого роста нагрузки. * **Сложность поддержки и обновлений (Низкий time-to-market новых релизов)** При внесении каких-либо изменений монолитному приложению необходимо пересобирать и перезапускать всю систему, что может вызвать простои и сложности в управлении обновлениями. * **Зависимость от технологий** В монолитной архитектуре труднее всего внедрять новые технологии, так как все части приложения связаны между собой, и изменение одной части может потребовать изменения всей системы. * **Сложность отладки и тестирования** Поиск и устранение ошибок может быть сложным из-за тесной интеграции всех компонентов в одной кодовой базе. * **Повышенный риск сбоя** По мере увеличения сложности монолитного приложения возрастает и риск сбоя. Единственная ошибка или проблема в одной части системы может иметь каскадные последствия, потенциально приводящие к общесистемному сбою. ## **Ситуации, когда лучше подойдет монолитное приложение** 1. У вас маленькое и относительно простое приложение, которое разрабатывается одной командой. Вообще, любое приложение, которое развивается итерационно с небольшого набора функций, на мой взгляд, должно начинаться как монолитное, а отдельные микросервисы из него выделяться по мере появления необходимости. 2. Все функции системы взаимодействуют с единой сильно связанной моделью данных. Разработчики не смогут независимо друг от друга менять модель данных (так как это повиляет на всех), а значит пресловутой "автономности команд" не добиться и мы получим в ряде случаев монолит, который деплоится двумя кусками; как говорится, сделаем из одной проблемы две. 3. Обмен данными между функциональными модулями имеет настолько высокие требования к скорости, что передача их по сети будет слишком медленной; в этом случае они (данные) должны быть расположены в памяти одного приложения. Источники: * * Тоже самое, но другими словами: * * --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.system-analyst-base.ru/hard-skills/proektirovanie/arkhitektura/monolit.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.