Как масштабируются монолиты и микросервисы
Монолитная архитектура — это традиционный подход в программировании, при котором приложение строится как единый неделимый блок. Вся функциональность приложения сосредоточена в одной базе кода и обновляется через полное пересобирание и развертывание всей системы.
В качестве примера использования монолитов можно привести ранний eBay. Изначально eBay использовал монолитную архитектуру для управления своими онлайн-аукционами, что обеспечивало быстрый старт и упрощенное управление продуктом.
Многие традиционные банковские системы до сих пор используют монолитные архитектуры из-за высоких требований к безопасности и надежности, а также из-за сложности миграции на более современные технологии.
Крупные корпоративные информационные системы, такие как ERP (Enterprise Resource Planning) и CRM (Customer Relationship Management), также традиционно строились как монолиты, что обеспечивало интеграцию всех бизнес-процессов в единое целое.
Какие преимущества и недостатки имеет монолитная архитектура?
Так как в монолите все связано единой базой кода, это значительно упрощает процесс разработки и тестирования. По этой же причине обмен данными между компонентами внутри монолита более эффективный, чем в микросервисной архитектуре. Запуск и обслуживание таких приложений часто дешевле, чем микросервисов, так как не требуется управление большим числом независимых сервисов.
А главный недостаток – это негибкость и сложности с масштабированием. В монолитной архитектуре труднее всего внедрять новые технологии, делать обновления, так как все части приложения связаны между собой, и изменение одной части может потребовать изменения всей системы. Ошибка в одном модуле может повлиять на доступность всего приложения.
Twitter изначально был построен как монолитное приложение. Когда число пользователей и данных начало расти, компания столкнулась с серьезными проблемами производительности: монолитная структура затрудняла горизонтальное масштабирование систему, что приводило к частным отказам и необходимости значительно увеличивать серверные мощности, чтобы справиться с нагрузкой.
В крупных монолитных коммерческих системах, например, для управления заказами, всегда сложная структура, в которой сложнее искать и справлять ошибки из-за высокой степени взаимозависимости компонентов.
В каких случаях использование монолитной системы целесообразно?
Во-первых, для приложений малого и среднего бизнеса, если это приложение предусматривает относительно небольшой функционал и небольшую команду разработки. Монолит идеален для приложения одной функции без сложной интеграции или больших требований к масштабируемости. В этом случае монолит гарантирует высокую производительность приложения. Если же потребуется масштабировать систему, то можно просто добавить больше реплик монолита под подсистему балансировки нагрузок, и, тем самым, решить эту проблему.
Например, в нашей практике мы использовали монолиты, когда продавали решения на CMS UMI. Это позволяло нам производить продукты максимально быстро и в сжатые сроки. В каком-то плане, это было нашим преимуществом для входа на рынок.
Во-вторых, монолит подойдет для проектов прототипирования и проверки концепции (proof-of-concept или PoC). Для начальных этапов разработки, когда нужно быстро проверить идеи, монолиты предлагают простоту и скорость. Они идеальны для создания MVP (минимально жизнеспособного продукта), позволяя быстро собрать обратную связь без лишних затрат на инфраструктуру. В Inetstudio мы часто запускам MVP как монолит. Это позволяет нам быстро проверить корректность наших идея для внутренних проектов, заложить основной функционал, которым уже можно пользоваться. А дальше постепенно обновляем приложение и мигрируем на микросервисы.
В-третьих, монолит подходит для среды с ограниченными ресурсами инфраструктуры или возможностями развертывания. Для работы такой системы требуется меньше ресурсов (по сравнению с установкой распределенного микросервиса), так что она лучше подходит для сред с аппаратными или финансовыми ограничениями.
Наконец, использование монолита оправдано для унаследованных систем (Legacy-системы). Модернизация и миграция унаследованных систем – это сложные процессы. Часто практичнее будет сохранить существующую монолитную архитектуру и постепенно провести рефакторинг системы, либо добавить в нужные места микросервисы. Так получается поэтапный переход, сводятся к минимуму сбои.
Что такое микросервисная архитектура?
Микросервисы – это независимые друг от друга службы с собственной бизнес-логикой и базой данных для выполнения конкретной задачи. Микросервисы облегчают управление сложностью за счет того, что они разбивают большие задачи на меньшие, тем самым повышая видимость каждого процесса.
Микросервисная архитектура тесно связана с практиками DevOps и методиками непрерывной интеграции и доставки (CI/CD), что позволяет командам разработчиков быстро реагировать на изменения и обновлять приложение с минимальными перерывами в работе.
Uber использует микросервисы для управления биллингом, расчетом стоимости поездки и диспетчеризации. Это позволяет им разрабатывать, тестировать и развертывать изменения в одной части системы без риска для других функций.
А, например, в нашей компании мы сейчас занимаемся обновлением одного из крупных порталов для врачей и фармацевтов. Ранее он был написан в монолите и уже очень сильно устарел. Мы освежили дизайн всего приложения, чтобы он соответствовал современным представлениям об UX/UI. Разбили его на отдельные логические блоки: админ-панель, личный кабинет, новостная лента, нотификации, аутентификация, логи и мониторинг, умный поиск, каталог обучений и сами обучения, база врачей, клинические случаи и пр. Также мы протипизровали весь код и покрыли весь важные функционал тестами.
Какими преимуществами обладает микросервисная архитектура?
В процессе масштабирования ПО разработчики сталкиваются со сложностями, которые как раз микросервисы могут эффективно решить.
Например, в одном из недавних проектов Proexpert у нас в INETstudio у нас были проблемы – редкий выход обновлений, сильная связанность кодовой базы и архитектуры. Раньше мы ждали пятницы, чтобы собрать все обновления и начать катить их в продашкн, ожидая всевозможных проверок валидации, тестов, сборки и самого деплоя около 1 часа (если повезет и на проде все будет в порядке, т.к. одна малейшая непредвиденная ошибка заставляла повторять весь ритуал заново). Сейчас мы можем заливать обновления сколько угодно раз в день, ожидая всего около 5-6 минут.
Внедрение микросервисов позволило эффективно распределить задачи и автономно поддерживать различные команды, это ускорило процесс достижения поставленных целей и улучшило инкрементную поставку ценности для клиентов.
Благодаря микросервисам также становится возможным более гибкое масштабирование команд и географии регионов. Разделение сервисов по линиям владения улучшает управляемость, упрощает процесс обновления кода и ускоряет циклы релизов за счет непрерывной интеграции и непрерывной доставки (CI/CD). Команды могут свободно экспериментировать с новыми идеями и быстро откатываться к предыдущим версиям при возникновении ошибок, что уменьшает риски и увеличивает оперативность реагирования на изменения.
Недостатки микросервисной архитектуры
Когда мы перешли от небольшого количества монолитных баз кода к множеству распределенных систем и служб, которые теперь составляют основу наших продуктов, возникла непредвиденная сложность. Поначалу нам не удавалось добавлять новые возможности с прежней скоростью и уверенностью. Микросервисы могут сделать процесс разработки сложнее и привести к его разрастанию — быстрому и неуправляемому росту. Иногда бывает сложно определить, как различные компоненты связаны друг с другом, кто владеет конкретным программным компонентом или как избежать вмешательства в работу зависимых компонентов. С помощью проекта Proexpert мы создали общие функциональные возможности, которые станут основой существующих и будущих продуктов. Если ваша компания разрабатывает только один продукт, микросервисы могут и не понадобиться.
В каких случаях лучше использовать микросервисную архитектуру?
Микросервисы идеально подходят для управления крупномасштабными приложениями с обширным функционалом. Amazon перешел от монолитной архитектуры к микросервисам, чтобы управлять огромным ассортиментом продуктов и сложной логистикой. Разделение функций на отдельные сервисы, такие как управление заказами, управление инвентарем и рекомендации, позволило Amazon улучшить организацию и ускорить внедрение нововведений.
Микросервисы выгодны для приложений с изменчивыми или непредсказуемыми рабочими нагрузками. Netflix использует микросервисы для обработки колеблющегося количества потокового трафика от миллионов пользователей по всему миру. Отдельное масштабирование сервисов для рекомендаций, кэширования и потоковой передачи контента позволяет обеспечивать надежную производительность в пиковые часы.
Микросервисы отлично подходят для приложений с сложными доменными моделями. Они позволяют соотносить каждый сервис с конкретной подобластью предметной области, что улучшает распределение обязанностей и инкапсуляцию. Это обеспечивает модульность и независимость развития отдельных компонентов, что способствует лучшей масштабируемости и управляемости.
Микросервисы предоставляют возможность использовать различные технологии и фреймворки для каждого компонента системы. Это позволяет командам выбирать наиболее подходящие инструменты для каждой задачи, оптимизируя процесс разработки и обеспечивая лучшую производительность. Twitter перешел к использованию микросервисов, что позволило различным командам выбирать стек технологий, наиболее подходящий для их сервисов. Например, одни сервисы могут использовать Scala, другие — Java, в зависимости от их специфических требований и предпочтений разработчиков.
В чем разница масштабирования монолитных и микросервисных архитектур?
Ключевые сервисы для масштабирования такие:
- Docker — это платформа для контейнеризации приложений, которая позволяет упаковать приложение с его окружением в контейнер, который можно легко переносить и развертывать. Это особенно полезно в микросервисных архитектурах, где каждый сервис может быть запущен в своем собственном контейнере.
- Kubernetes — это система оркестрации контейнеров, которая автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями. Она подходит для управления микросервисами на большом количестве серверов.
- Prometheus — это система мониторинга и оповещения, а Grafana — платформа для аналитики и мониторинга. Обе эти технологии часто используются вместе для мониторинга микросервисов и визуализации их работы.
В монолитах часто используются традиционные серверы или виртуальные машины. Для управления масштабированием могут применяться инструменты автоматизации, такие как Puppet, Chef или Ansible. В монолитах масштабирование преимущественно вертикальное, что означает добавление ресурсов (ЦПУ, память) к существующему серверу. Это может привести к дорогостоящим апгрейдам и ограниченной гибкости.
В микросервисных архитектурах используются Docker, Kubernetes, Istio для контейнеризации и оркестрации. Prometheus и Grafana применяются для мониторинга. Масштабирование в микросервисах горизонтальное, это позволяет добавлять или удалять экземпляры сервисов в зависимости от нагрузки, увеличивать эффективность и снижать затраты на инфраструктуру.
Опубликовано 27.04.2024
