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

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

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

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

• Длительность сборки приложения и последующего развертывания

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

• Сложности с масштабированием

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

• Низкая устойчивость к сбоям

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

• Ограничения на внедрение новых технологий

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

• Низкий time-to-market новых релизов

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

• Сложности управления

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

• Зависимость от модели данных

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

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

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

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

• Быстрое развертывание кода

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

• Гибкое масштабирование

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

• Высокая устойчивость к сбоям

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

• Широкий выбор используемых технологий

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

• Повышение эффективности команд

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

• Переиспользование функциональностей

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

• Быстрая замена компонентов

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

• Независимость моделей данных

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

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

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

• Рост требований к специалистам

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

• Потенциальное увеличение времени отклика и рост количества точек отказа

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

• Необходимость согласованности

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

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

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

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

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