Лекция 162: Различия между монолитными и микросервисными архитектурами

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

А теперь загляните в современный стриминговый сервис — плеер сам по себе, рекомендации отдельно, профили пользователей вообще на другом сервере. Упала система комментариев? Не беда, фильмы всё равно можно смотреть. Новогодний наплыв зрителей? Просто увеличиваем мощность серверов с видео, не трогая остальное. Это и есть микросервисная архитектура — набор независимых компонентов, которые умеют дружить, но могут работать и сами по себе.

А теперь рассмотрим подробнее особенности этих двух подходов.

Монолиты

Основные характеристики монолитной архитектуры:

1. Централизованный единый код: всё приложение собирается в один "кубик", будь то JAR или WAR.
2. Связанная структура: все части приложения (контроллеры, сервисы, репозитории) tightly coupled — то есть плотно связаны друг с другом.
3. Единое развертывание: даже если вы меняете одну строку в коде, вам нужно пересобрать и перезапустить всё приложение.

Преимущества монолита

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

Недостатки монолита

• Проблемы масштабирования: монолит можно масштабировать только вертикально (добавив больше CPU, RAM и других ресурсов на сервер), но что делать, если требуется масштабировать лишь небольшую часть приложения? Например, ваш серверный API для обработки изображений пользуется большей популярностью, чем остальные части системы. Увы, вы всё равно должны масштабировать весь монолит целиком.
  • Сложность обновлений: в монолите сложно выкатить изменения. Даже небольшая доработка требует пересборки всего приложения. Если в процессе обновления что-то пойдет не так, весь ваш небоскреб (ага, помните про наш небоскреб?) может рухнуть.
  • Уязвимость к сбоям: один сбой может привести к тому, что всё приложение перестанет работать. Например, если в вашем сервисе оплаты возникла ошибка, то весь сайт может стать недоступным.

Микросервисы

Мы уже привели пример современного микросервисного приложения — онлайн-кинотеатра — где модули независимы друг от друга.

Микросервисы — это независимые модули, которые:

1. Выполняют одну конкретную задачу.
2. Автономно разрабатываются и развертываются.
3. Общаются друг с другом через стандартные сетевые интерфейсы (например, REST или сообщения через Kafka).

Преимущества микросервисов

• Независимое развертывание: вы можете обновлять, исправлять или даже менять технологический стек одного микросервиса, не затрагивая другие. Это уменьшает риск внесения крушащих изменений (breaking changes).
• Масштабируемость: легко масштабировать только те микросервисы, которые испытывают нагрузку. Ваш API для загрузки котиков пользуется бешеной популярностью? Просто запускаете больше экземпляров сервиса обработки изображений.
• Устойчивость к сбоям: падение одного микросервиса не тянет за собой всю систему. Например, если сломается ваш почтовый сервис, пользователи всё ещё смогут оплачивать покупки, проверять статус заказа и добавлять товары в корзину.
• Разнообразие технологий: каждый микросервис может использовать разные языки программирования и базы данных, подходящие для конкретной задачи.
• Независимость команд: микросервисы позволяют различным командам работать автономно, что особенно полезно в больших компаниях. Каждая команда может сосредоточиться на своей области и deploy'ить изменения самостоятельно.

Недостатки микросервисов

• Усложнение разработки: разработка распределённой системы сложнее. Вам нужно предусмотреть обработку отказов, продумать стратегию взаимодействия сервисов и часто балансировать между синхронной и асинхронной коммуникацией.
• Комплексное развертывание: в отличие от монолита, развертывание микросервисов требует координации множества частей. Вам придётся наладить CI/CD, иметь систему управления конфигурациями (например, Spring Cloud Config) и мониторинг.
• Network Overhead: микросервисы обмениваются данными через сеть. Это добавляет задержки и требует продуманной стратегии по сериализации и десериализации данных.

Сравнение монолита и микросервисов

Когда выбрать монолит, а когда микросервисы?

Когда использовать монолит:

1. Вы только начинаете проект, и ваша команда небольшая.
2. У вас нет необходимости в высокой масштабируемости.
3. Вы хотите быстро разрабатывать и выводить продукт на рынок.

Когда выбрать микросервисы:

1. Приложение стало большим и слишком тяжеловесным для добавления новых фич.
2. Требуется масштабировать отдельные модули.
3. У вас есть большие команды разработчиков, работающих над различными частями системы.
4. Вам нужна высокая отказоустойчивость.

Подводные камни и типичные ошибки

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

1. Переразделение: если ваши микросервисы слишком маленькие, вы получите головную боль с сетевой коммуникацией и сложностью координации.
2. Антипаттерн распределённой монолитности: когда микросервисы всё ещё зависят друг от друга, нарушение одного блока ломает всё приложение.
3. Недостаток инструментов: без инструментов для мониторинга (например, Spring Boot Actuator или Prometheus) вы рискуете потерять контроль над системой.
4. Сложности с консистентностью данных: поддержка согласованности между микросервисами становится вызовом, особенно с асинхронной коммуникацией.

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