до 18 ноября
Хватай скидки -30% на все!
Черная пятница
Микросервисы VS монолит: когда пора переходить от одного к другому?
Автор — Владимир Балун
ex-TeamLead в Яндекс
Представьте интернет-магазин, в котором есть каталог товаров, корзина, оплата, авторизация и доставка. Пока проект небольшой, всё это можно собрать в одном приложении. Но по мере роста системы изменения становятся сложнее: небольшая правка в одном модуле может потребовать тестирования и развертывания всего приложения.
Один из способов справиться с такой сложностью — разделить систему на независимые микросервисы.
В этой статье разберемся в отличиях микросервисной архитектуры от монолита и когда стоит выбирать каждый из них.
Один из способов справиться с такой сложностью — разделить систему на независимые микросервисы.
В этой статье разберемся в отличиях микросервисной архитектуры от монолита и когда стоит выбирать каждый из них.
Разбор монолитной архитектуры
При монолитной архитектуре основные части приложения находятся внутри одного проекта и разворачиваются как единое целое:
«Клиент → приложение → база данных»
Например, интернет-магазин может состоять из модулей авторизации, каталога, корзины и оплаты, но весь код при этом находится в одном приложении.
Её удобно использовать на старте проекта, когда не нужно настраивать взаимодействие между отдельными сервисами, организовывать сложную инфраструктуру или продумывать десятки API.
«Клиент → приложение → база данных»
Например, интернет-магазин может состоять из модулей авторизации, каталога, корзины и оплаты, но весь код при этом находится в одном приложении.
Её удобно использовать на старте проекта, когда не нужно настраивать взаимодействие между отдельными сервисами, организовывать сложную инфраструктуру или продумывать десятки API.
Главная проблема появляется тогда, когда приложение начинает сильно разрастаться
Допустим, разработчик изменил модуль оплаты. Даже если остальные части системы не менялись, перед релизом может потребоваться проверить всё приложение и заново развернуть его целиком.
Разбор микросервисной архитектуры
Микросервисная архитектура предполагает разделение приложения на несколько относительно независимых сервисов. Каждый из них отвечает за определенную бизнес-функцию и взаимодействует с другими сервисами через API:
«Клиент → API → сервисы каталога, корзины, оплаты, доставки»
Например, сервис оплаты занимается только платежами, а сервис каталога — товарами. Их можно разрабатывать, тестировать, обновлять и масштабировать независимо друг от друга.
«Клиент → API → сервисы каталога, корзины, оплаты, доставки»
Например, сервис оплаты занимается только платежами, а сервис каталога — товарами. Их можно разрабатывать, тестировать, обновлять и масштабировать независимо друг от друга.
Но за независимость приходится платить дополнительной сложностью
Теперь вместо одного приложения нужно поддерживать множество сервисов, которые должны корректно взаимодействовать между собой. Появляются сетевые запросы, дополнительные точки отказа, системы мониторинга, логирования и трассировки.
Сравнение монолита и микросервисов
Проведем сравнение архитектуры по ключевым для разработки и эксплуатации критериям и найдем разницу между монолитной архитектурой и микросервисной.
Критерий
Монолит
Микросервисы
Граница приложения
Все бизнес-модули работают внутри одного приложения
Система разделена на сервисы, каждый из которых отвечает за отдельную бизнес-функцию
Связь между компонентами
Вызовы между модулями происходят внутри одного процесса
Сервисы взаимодействуют по сети через API или очереди сообщений
Развертывание
Даже небольшое изменение обычно требует сборки и выкладки всего приложения
Можно развернуть только изменённый сервис, не затрагивая остальные
Масштабирование
При росте нагрузки чаще масштабируется всё приложение целиком
Можно отдельно масштабировать сервис, который испытывает наибольшую нагрузку
Отказоустойчивость
Ошибка в одном компоненте потенциально может повлиять на всё приложение
Отказ одного сервиса можно изолировать, но нужно отдельно обрабатывать таймауты, недоступность и повторные запросы
Отладка
Проще проследить выполнение запроса внутри одного приложения
Нужно отслеживать цепочку вызовов между сервисами с помощью логов, метрик и распределенной трассировки
Изменение архитектуры
Сильная связанность модулей может привести к тому, что изменение одного компонента затронет другие
При хорошо определенных границах сервис можно менять независимо от остальных
Технологический стек
Обычно используется единый стек для всего приложения
Для разных сервисов можно выбирать разные технологии, если это оправдано задачей
Инфраструктура
Относительно простая: один основной процесс, единый деплой и набор инструментов
Требуются дополнительные механизмы для оркестрации, обнаружения сервисов, мониторинга, логирования и доставки
Стоимость эксплуатации
Ниже на небольшом масштабе благодаря простой инфраструктуре
Выше из-за количества сервисов, окружений и инфраструктурных компонентов
Чек-лист: когда переходить с монолита на микросервисы
На практике путь перехода встречается довольно часто. Компания может начать с монолитного приложения, а затем по мере роста постепенно выделять из него отдельные компоненты.
Переход на микросервисы стоит рассматривать, если вы можете отметить несколько пунктов:
Переход на микросервисы стоит рассматривать, если вы можете отметить несколько пунктов:
- Отдельная часть системы постоянно испытывает высокую нагрузкуНапример, каталог получает в десятки раз больше запросов, чем административная панель, но масштабировать их приходится вместе
- Разные компоненты выпускаются с разной скоростьюНапример, команда оплаты выкатывает изменения несколько раз в неделю, а каталог обновляется ежедневно
- Одна кодовая база стала узким местом для нескольких командРазработчики часто сталкиваются с конфликтами, блокируют релизы друг друга и тратят много времени на согласования
- Изменения в одном модуле регулярно затрагивают другиеНебольшая доработка требует масштабного тестирования и превращается в общий релиз всего приложения
- У частей системы разные требования к технологиям и масштабированиюНапример, поиск, обработка платежей и каталог работают под разными нагрузками и требуют разных технических решений
- Команда готова поддерживать дополнительную инфраструктуруЕсть ресурсы на мониторинг, логирование, трассировку, автоматизацию развертывания и обработку сетевых сбоев
- Границы бизнес-функций уже достаточно понятныВы можете определить, какие данные и операции относятся к каталогу, оплате, доставке или другому отдельному домену
- Проблемы монолита уже подтверждены практикойПереход решает конкретные сложности с релизами, масштабированием или командной работой, а не выполняется только ради использования микросервисов
Не обязательно сразу превращать весь монолит в десятки сервисов. Лучше постепенно выделять наиболее самостоятельные части, чтобы не усложнять систему раньше времени.
Заключение
При выборе монолита и микросервисов нельзя точно определить, какой подход всегда лучше другого.
Монолит позволяет быстро и относительно просто создать приложение, а микросервисы дают независимость отдельным компонентам и помогают управлять сложными системами.
При этом вместе с гибкостью микросервисы приносят дополнительную инфраструктурную и организационную сложность. Поэтому архитектуру стоит выбирать исходя из размера проекта, команды, нагрузки и будущих требований, а не только из популярности технологии.
Монолит позволяет быстро и относительно просто создать приложение, а микросервисы дают независимость отдельным компонентам и помогают управлять сложными системами.
При этом вместе с гибкостью микросервисы приносят дополнительную инфраструктурную и организационную сложность. Поэтому архитектуру стоит выбирать исходя из размера проекта, команды, нагрузки и будущих требований, а не только из популярности технологии.
Другие статьи