Все статьи

Микросервисная vs. монолитная архитектура: отличия и факторы выбора

18 ноя 20212563

Что вы представляете при слове «монолит»? Может быть, огромную каменную глыбу с древними письменами? Впрочем, сейчас ассоциативный ряд значения не имеет, ведь сегодня мы будем говорить про разновидности архитектур. Разберемся, чем отличаются монолитные и микросервисные приложения, какие плюсы и минусы у каждого подхода и когда стоит переходить на микросервисы.

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

Об этом подходе стали особенно часто говорить, когда облака обрели популярность. Это и не удивительно: микросервисная архитектура актуальна именно для cloud-native приложений.

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

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

Вот так схематично можно представить себе устройство монолитного приложения.

20_1.png Увеличить

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

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

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

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

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

  • Низкий time-to-market новых релизов
  • Как вы помните, для добавления новой функциональности или возможности придется обновить все приложение целиком. К сожалению, этот фактор негативно отражается на частоте получения обновлений. В некоторых случаях, чтобы минимизировать этот эффект, разработчики прибегают к увеличению числа изменений в одном релизе. А это значительно повышает риски возникновения сбоев.

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

  • Зависимость от модели данных
  • Даже небольшие изменения в БД будут влиять на приложения и требовать существенных изменений в кодовой базе.

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

Особенности микросервисов

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

Преимущества подхода:

  • Быстрое развертывание кода
  • Хотите внести изменение в определенные «кусочки»»приложения? Просто разверните те микросервисы, которые нужно обновить. Тратить время и силы на развертывание приложения целиком в случае с микросервисами не придется.

  • Гибкое масштабирование
  • Вы можете расширить только те сервисы, которым не хватает производительности, а другие компоненты продолжат работать без изменений.

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

  • Широкий выбор используемых технологий
  • Разработчик ничем не ограничен при формировании стека технологий и может выбирать оптимальные инструменты и решения.

  • Повышение эффективности команд
  • При создании микросервисного приложения каждая бизнес-функциональность закрепляется за конкретной группой разработчиков. Это значительно упрощает процесс управления и повышает его эффективность.

  • Переиспользование функциональностей
  • Есть возможность использовать оптимальные функциональности повторно — для разных задач и разными способами.

  • Быстрая замена компонентов
  • В процессе развития приложения вы можете столкнуться с необходимостью заменить используемый микросервис другим. Так как все компоненты четко отделены друг от друга и имеют очевидные границы, делать это можно без риска «уронить» систему.

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

Недостатки подхода

Конечно, микросервисный подход не лишен своих особенностей.

  • Рост требований к специалистам
  • При переходе на микросервисы всем специалистам придется овладеть солидным набором новых навыков и освоить неизвестные ранее инструменты. Например, методологию DevOps. Она призвана подружить команды разработки и эксплуатации и обеспечить их тесное взаимодействие друг с другом. К сожалению, далеко не каждая компания сможет самостоятельно справиться с этим вызовом.

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

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

Сравним обе архитектуры по выбранным параметрам:

Монолитное приложение Микросервисное приложение
Масштабирование Только целиком Можно масштабировать отдельные компоненты
Устойчивость к сбоям Низкая Высокая
Развертывание Только целиком Можно разворачивать отдельные компоненты
Гибкость в выборе технологий Ограничен Свободный
Time-to-market продуктов Низкий Высокий
Управление разработкой Сложное Простое
Зависимость от модели данных Есть Нет

Кому подойдут микросервисы

В некоторых случаях без внедрения микросервисов не обойтись:

  • Приложение содержит множество модулей и компонентов
  • Различающиеся требования компонентов к вычислительным ресурсам
  • Объемная кодовая база
  • Большая команда разработки (10+), которую вы планируете расширять
  • Для вашего приложения характерны всплески трафика
  • Необходимо сократить time-to-market и ускорить выпуск новых релизов

Узнали в чек-листе себя? Задумайтесь о внедрении микросервисов, но не торопитесь. Поспешный или попросту неоправданный переход нивелирует любые преимущества архитектуры.