Что вы представляете при слове «монолит»? Может быть, огромную каменную глыбу с древними письменами? Впрочем, сейчас ассоциативный ряд значения не имеет, ведь сегодня мы будем говорить про разновидности архитектур. Разберемся, чем отличаются монолитные и микросервисные приложения, какие плюсы и минусы у каждого подхода и когда стоит переходить на микросервисы.
Уже из названия можно догадаться, что микросервисная архитектура предусматривает разбиение приложения на множество отдельно работающих компонентов. При этом микросервисы в составе продукта слабо связаны друг с другом и могут работать автономно.
Об этом подходе стали особенно часто говорить, когда облака обрели популярность. Это и не удивительно: микросервисная архитектура актуальна именно для cloud-native приложений.
Особенности монолитной архитектуры
Противопоставляются микросервисам монолиты. Приложения с монолитной архитектурой изначально создаются как нечто единое и неделимое. Хоть они и могут состоять из широкого набора модулей, связь между ними так сильна, что сломается один модуль — возникнут проблемы со всем приложением целиком. Вся логика обработки запросов внутри монолитного приложения представляет из себя один процесс.
Вот так схематично можно представить себе устройство монолитного приложения.
Увеличить
Несмотря на разнообразие бизнес-функциональностей, все они представляют собой один блок. Такой подход к разработке имеет определенные ограничения и недостатки.
- Длительность сборки приложения и последующего развертывания
- Сложности с масштабированием
- Низкая устойчивость к сбоям
- Ограничения на внедрение новых технологий
- Низкий time-to-market новых релизов
- Сложности управления
- Зависимость от модели данных
Если вы вдруг захотите добавить в монолит новую фичу или выполнить обновление, вам придется разворачивать приложение заново. Это займет больше времени и сил, чем обновление отдельного компонента.
Здесь проблема похожа. Масштабировать приложение в любом случае придется целиком, даже если на самом деле этого требует какой-то конкретный компонент.
Когда на одном из модулей монолитного приложения происходит сбой, отражается это на работоспособности всего продукта. Виной тому — слишком близкие и сильные связи между разными компонентами.
Разработчик монолита, увы, будет связан выбранным ранее стеком технологий, даже если для некоторых компонентов оптимальнее подходят решения за рамками этого набора.
Как вы помните, для добавления новой функциональности или возможности придется обновить все приложение целиком. К сожалению, этот фактор негативно отражается на частоте получения обновлений. В некоторых случаях, чтобы минимизировать этот эффект, разработчики прибегают к увеличению числа изменений в одном релизе. А это значительно повышает риски возникновения сбоев.
Как правило, в разработке монолитного приложения участвует большая команда. Несмотря на то, за что отвечает конкретная группа разработчиков, ей придется овладеть экспертизой коллег из других групп. С течением времени управлять такой командой становится все сложнее и сложнее.
Даже небольшие изменения в БД будут влиять на приложения и требовать существенных изменений в кодовой базе.
В определенных ситуациях монолитная архитектура может быть удобной. Например, если вы разрабатываете относительно небольшое приложение и не планируете его часто обновлять. Однако если вы хотите добиться высокой гибкости продукта и планируете постоянно его развивать — стоит присмотреться к микросервисной архитектуре.
Особенности микросервисов
Микросервисная архитектура призвана устранить ограничения, сопутствующие монолитной. Такие приложения строятся по принципу конструктора: можно заменить любую деталь, но ваш «замок» при этом не сломается. Кроме того, в микросервисном приложении четко видны границы между всеми компонентами, чего не скажешь про монолитные продукты.
Преимущества подхода:
- Быстрое развертывание кода
- Гибкое масштабирование
- Высокая устойчивость к сбоям
- Широкий выбор используемых технологий
- Повышение эффективности команд
- Переиспользование функциональностей
- Быстрая замена компонентов
- Независимость моделей данных
Хотите внести изменение в определенные «кусочки»»приложения? Просто разверните те микросервисы, которые нужно обновить. Тратить время и силы на развертывание приложения целиком в случае с микросервисами не придется.
Вы можете расширить только те сервисы, которым не хватает производительности, а другие компоненты продолжат работать без изменений.
Если один из микросервисов в составе приложения откажет, это не приведет к остановке всей системы сразу. А после того, как вы почините сбойный компонент, можно будет обновить лишь его, не разворачивая все приложение заново.
Разработчик ничем не ограничен при формировании стека технологий и может выбирать оптимальные инструменты и решения.
При создании микросервисного приложения каждая бизнес-функциональность закрепляется за конкретной группой разработчиков. Это значительно упрощает процесс управления и повышает его эффективность.
Есть возможность использовать оптимальные функциональности повторно — для разных задач и разными способами.
В процессе развития приложения вы можете столкнуться с необходимостью заменить используемый микросервис другим. Так как все компоненты четко отделены друг от друга и имеют очевидные границы, делать это можно без риска «уронить» систему.
Чаще всего у каждого микросервиса его отдельное хранилище данных. По этой причине внесение изменений в одну модель не повлияет на работоспособность остальных.
Недостатки подхода
Конечно, микросервисный подход не лишен своих особенностей.
- Рост требований к специалистам
- Потенциальное увеличение времени отклика и рост количества точек отказа
- Необходимость согласованности
При переходе на микросервисы всем специалистам придется овладеть солидным набором новых навыков и освоить неизвестные ранее инструменты. Например, методологию DevOps. Она призвана подружить команды разработки и эксплуатации и обеспечить их тесное взаимодействие друг с другом. К сожалению, далеко не каждая компания сможет самостоятельно справиться с этим вызовом.
Один микросервис в составе приложения может обращаться к десяти другим, и каждый из этих десяти — еще к нескольким. Чем больше сервисов, тем выше время отклика и количество потенциальных точек отказа.
Микросервисная архитектура может вызвать определенные проблемы с согласованностью из-за децентрализации управления данными. Увы, нередки ситуации, когда какой-то компонент временно перестает отвечать, так как на другом еще не завершилась выполняемая операция.
Сравним обе архитектуры по выбранным параметрам:
| Монолитное приложение | Микросервисное приложение | |
|---|---|---|
| Масштабирование | Только целиком | Можно масштабировать отдельные компоненты |
| Устойчивость к сбоям | Низкая | Высокая |
| Развертывание | Только целиком | Можно разворачивать отдельные компоненты |
| Гибкость в выборе технологий | Ограничен | Свободный |
| Time-to-market продуктов | Низкий | Высокий |
| Управление разработкой | Сложное | Простое |
| Зависимость от модели данных | Есть | Нет |
Кому подойдут микросервисы
В некоторых случаях без внедрения микросервисов не обойтись:
- Приложение содержит множество модулей и компонентов
- Различающиеся требования компонентов к вычислительным ресурсам
- Объемная кодовая база
- Большая команда разработки (10+), которую вы планируете расширять
- Для вашего приложения характерны всплески трафика
- Необходимо сократить time-to-market и ускорить выпуск новых релизов
Узнали в чек-листе себя? Задумайтесь о внедрении микросервисов, но не торопитесь. Поспешный или попросту неоправданный переход нивелирует любые преимущества архитектуры.
