Монолит
Монолитная архитектура – это традиционный способ организации приложений, в котором все компоненты продукта находятся внутри одной монолитной кодовой базы и управляются как единое целое.
Преимущества монолитной архитектуры
Простота разработки и тестирования
Монолитная архитектура проста в разработке, развертывании и обслуживании. Поскольку все компоненты являются частью единой кодовой базы, процесс разработки упрощается, и приложение можно развернуть как единое целое. Поскольку все приложение интегрировано, может быть проще выполнить сквозное тестирование для полной проверки функциональности системы.
Меньшие накладные расходы
Запуск и обслуживание таких приложений часто дешевле, чем микросервисов, так как не требуется управление большим числом независимых сервисов.
Производительность
Внутри монолита обмен данными между компонентами может быть более эффективным, чем в микросервисной архитектуре. Это связано с тем, что данные передаются в пределах одного процесса.
Недостатки монолитной архитектуры
Масштабируемость
Чаще всего такие приложения масштабируются вертикально, что означает увеличение ресурсов на одном сервере. Это может быть ограничивающим фактором при необходимости горизонтального масштабирования, особенно в случае резкого роста нагрузки.
Сложность поддержки и обновлений (Низкий time-to-market новых релизов)
При внесении каких-либо изменений монолитному приложению необходимо пересобирать и перезапускать всю систему, что может вызвать простои и сложности в управлении обновлениями.
Зависимость от технологий
В монолитной архитектуре труднее всего внедрять новые технологии, так как все части приложения связаны между собой, и изменение одной части может потребовать изменения всей системы.
Сложность отладки и тестирования
Поиск и устранение ошибок может быть сложным из-за тесной интеграции всех компонентов в одной кодовой базе.
Повышенный риск сбоя
По мере увеличения сложности монолитного приложения возрастает и риск сбоя. Единственная ошибка или проблема в одной части системы может иметь каскадные последствия, потенциально приводящие к общесистемному сбою.
Ситуации, когда лучше подойдет монолитное приложение
У вас маленькое и относительно простое приложение, которое разрабатывается одной командой. Вообще, любое приложение, которое развивается итерационно с небольшого набора функций, на мой взгляд, должно начинаться как монолитное, а отдельные микросервисы из него выделяться по мере появления необходимости.
Все функции системы взаимодействуют с единой сильно связанной моделью данных. Разработчики не смогут независимо друг от друга менять модель данных (так как это повиляет на всех), а значит пресловутой "автономности команд" не добиться и мы получим в ряде случаев монолит, который деплоится двумя кусками; как говорится, сделаем из одной проблемы две.
Обмен данными между функциональными модулями имеет настолько высокие требования к скорости, что передача их по сети будет слишком медленной; в этом случае они (данные) должны быть расположены в памяти одного приложения.
Источники:
Тоже самое, но другими словами:
Last updated
