Что выбрать для проекта — монолит или микросервисы

Монолит и микросервисы — не последовательные стадии развития, где одна архитектура автоматически лучше другой. Монолит объединяет основные компоненты приложения в единое развёртываемое решение, а микросервисная архитектура разделяет систему на независимые сервисы. Выбор зависит от нагрузки, сложности продукта, структуры команды, требований к масштабированию и скорости изменений.

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

На практике архитектуру стоит выбирать не по моде, а по ограничениям проекта. Ошибка на старте — строить десятки сервисов только потому, что в будущем продукт теоретически может стать большим.

Что такое микросервисная архитектура

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

Например, интернет-платформа может иметь отдельные сервисы:

• пользователей;
• каталога;
• заказов;
• платежей;
• уведомлений;
• поиска;
• аналитики.

При высокой нагрузке это позволяет увеличить мощности только для компонента, который действительно становится узким местом. Не требуется масштабировать всё приложение целиком. Microsoft относит независимое развёртывание и масштабирование к основным особенностям микросервисного подхода.

Но появляется новая сложность. Вместо одного приложения команда получает распределённую систему с сетевым взаимодействием, несколькими точками отказа, мониторингом, логированием, версионированием API и вопросами согласованности данных.

Поэтому для разработки высоконагруженных систем выбор микросервисной архитектуры должен быть следствием требований к системе, а не самостоятельной целью. На странице Adlíbis среди принципов таких проектов отдельно рассматриваются архитектура, масштабируемость, отказоустойчивость, инфраструктура, CI/CD, тестирование и регулярный code review.

Когда нужен монолит

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

Монолит особенно рационален для:

• MVP;
• внутренних корпоративных систем;
• небольших SaaS-продуктов;
• проектов с одной командой разработки;
• систем с умеренной нагрузкой;
• продуктов, требования к которым ещё активно меняются.

Главное преимущество — простота. Код находится в одном проекте или тесно связанном наборе модулей, меньше сетевых взаимодействий, проще локальная разработка и первоначальное развёртывание.

При этом хороший монолит не должен означать хаотичную структуру. Его можно проектировать модульно: разделить бизнес-области, определить интерфейсы между ними и минимизировать жёсткие зависимости.

Такой подход оставляет возможность позднее вынести действительно нагруженные или организационно независимые компоненты в отдельные сервисы.

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

Какие плюсы и минусы микросервисов

Главные плюсы микросервисов — независимое масштабирование, развёртывание и развитие отдельных компонентов; основные минусы — высокая инфраструктурная и операционная сложность. Микросервисы дают больше архитектурной свободы, но требуют зрелых процессов разработки, DevOps, мониторинга и управления распределёнными данными.

К преимуществам микросервисов относится возможность независимо выпускать отдельные части системы. Команда платежей, например, может обновить свой сервис без полного релиза приложения. Microsoft отдельно отмечает независимую разработку, тестирование, развёртывание и версионирование сервисов.

Другой плюс — выборочное масштабирование. Если основная нагрузка приходится на каталог или поиск, дополнительные ресурсы можно предоставить именно этим компонентам.

Но бесплатной эта гибкость не бывает. В распределённой системе необходимо учитывать сетевые задержки, отказ одного сервиса при доступности остальных, трассировку запросов, централизованные логи, балансировку, очереди, безопасность API и управление версиями.

Поэтому микросервисы могут ухудшить проект, если команда не готова к их эксплуатации. В актуальном руководстве Microsoft по оценке готовности к микросервисам рекомендуется отдельно анализировать зрелость приложения, инфраструктуры, DevOps-процессов и модели разработки.

Когда переходить на микросервисы

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

Сигналами для пересмотра архитектуры могут быть:

• один модуль получает значительно больше нагрузки остальных;
• релиз небольшой функции требует развёртывания всей системы;
• несколько команд постоянно изменяют одну кодовую базу;
• сборка и тестирование стали слишком длительными;
• отдельные бизнес-функции имеют разные требования к отказоустойчивости;
• части продукта развиваются с разной скоростью;
• текущая архитектура мешает дальнейшему масштабированию.

Не обязательно переписывать весь продукт сразу. AWS рекомендует для ряда сценариев постепенную декомпозицию, при которой функциональность последовательно выносится из существующего монолита в отдельные сервисы. Такой подход снижает риски по сравнению с полной одномоментной заменой системы.

Например:

Было:
монолит → пользователи + каталог + заказы + платежи + уведомления.

Стало:
монолит → основная бизнес-логика;
отдельный сервис → платежи;
отдельный сервис → уведомления;
отдельный сервис → поиск.

Затем декомпозицию можно продолжать только там, где она приносит измеримый технический или бизнес-эффект.

Именно поэтому при разработке IT-систем для бизнеса архитектуру разумнее определять после анализа процессов, требований и предполагаемой нагрузки. Adlíbis указывает среди этапов своей работы изучение потребностей клиента, формирование пользовательских сценариев и функциональных требований, проектирование архитектуры, выбор технологического стека и планирование релизов.

Если монолит стабильно работает, команда выпускает изменения без проблем, а нагрузка масштабируется доступными способами, миграция на микросервисы может не дать достаточного эффекта для оправдания её стоимости.

Об авторе