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