• 17 сентября 2024
• #

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

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

Монолитная архитектура

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

Главная особенность монолитов — это единство. Единство кодовой базы, процессов развертывания, компонентов. То есть, все функции приложения собраны в одном репозитории, и это сильно упрощает управление кодом и его версиями. Приложение разворачивается целиком, это упрощает процесс деплоя и обновления, а компоненты системы управляются централизованно, что упрощает мониторинг и контроль.

Преимущества монолитной архитектуктуры:

1. Простота разработки: все компоненты находятся в одном месте и тесно связаны, поэтому разработчикам не нужно учитывать межсервисное взаимодействие. Писать и тестировать код проще
2. Высокая производительность: так как все компоненты находятся в одном месте и в рамках одного процесса, отсутствие сетевых вызовов между компонентами системы позволяет достичь высокой производительности
3. Единое управление: легче управлять и контролировать одну кодовую базу, чем множество разрозненных сервисов
4. Понятная структура: для новых разработчиков проще вникнуть в проект, так как вся логика находится в одном месте

Звучит уже убедительно и монолиты кажутся по всем параметрам подходящим решением, неправда ли? К сожалению, недостатков тоже хватает:

1. Масштабирование: масштабировать монолиты — сложно. И нерационально. Так как все наши компоненты связаны воедино, то когда требуется дополнительные ресурсы лишь для одной части — увеличить придется мощность всего приложения. Это может привести к совершенно нерациональному использованию мощностей
2. Ненадежность: ошибка в одном компоненте может привести к сбою всей системы. В этом, пожалуй, состоит главная “боль”
3. Трудности обновления: любые изменения требуют полной пересборки и развертывания приложения, что может привести к простою
4. Ограниченная гибкость: сложно внедрять новые технологии и подходы, так как это может затронуть всю систему

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

Каким именно свойствам должна отвечать Cloud native инфраструктура?

Первое — это возможность эксплуатации, простыми словами, это возможность управления жизненным циклом приложения или системы с помощью внешних инструментов. Второе — возможность наблюдения. Сюда относится наличие механизмов получения текущего состояния и производительности. В-третьих — это эластичность, которая позволяет увеличивать или уменьшать приложение в размерах в рамках доступных ресурсов и в зависимости от нагрузки. Следующее свойство — это отказоустойчивость, гарантирующая быстрое и автоматическое восстановление в случае падений. И последнее свойство — это динамичность, включающая в себя быстрые развертывания (деплой), итерации и изменения конфигураций.

Как видите, монолитная архитектура по многим своим параметрам не отвечает признакам CNCF, а, значит, для сложных и современных проектов навряд ли может использоваться.

Что же такое микросервисная архитектура?

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

Преимущества микросервисной архитектуры:

1. Гибкость разработки: разные команды могут работать над различными микросервисами параллельно, что ускоряет процесс разработки 
2. Независимое развертывание: обновление одного микросервиса не требует остановки и перезапуска всей системы
3. Устойчивость: ошибка в одном микросервисе не приводит к сбою всей системы, что повышает общую надежность
4. Масштабируемость: можно масштабировать только те части системы, которые испытывают высокую нагрузку, что оптимизирует использование ресурсов

Недостатки микросервисной архитектуры: 

1. Сложность управления: управление большим количеством микросервисов требует развитой системы оркестрации, мониторинга и логирования
2. Сетевые задержки: взаимодействие между микросервисами через сеть может снизить производительность, при недостаточной мощности инфраструктуры
3. Высокие требования к инфраструктуре: для эффективного управления микросервисами требуется развитая инфраструктура, в том числе системы контейнеризации (например, Docker) и оркестрации (например, Kubernetes)
4. Трудности тестирования: тестирование распределенной системы сложнее, так как нужно учитывать взаимодействие между сервисами

Вот мы и разобрались в двух сторонах одной инфраструктурной монеты. Но прежде, чем сделать выбор, какую инфраструктуру лучше использовать в вашем следующем проекте, нужно учесть множество факторов. Давайте сравним несколько сфер применения каждой архитектуры, чтобы рассмотреть, какие архитектурные подходы предпочитают компании в России, основываясь на нашем DevOps-опыте проектирования и поддержки различных инфраструктур. 

Для каких проектов подойдет монолитная архитектура?

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

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

И, конечно, это legacy-инфраструктуры (унаследованные инфраструктуры), так как заниматься обновлением или миграцией legacy-системы – дело трудоемкое и неблагодарное. В некоторых случаях (не всегда), лучше не трогать монолитную архитектуру и, со временем, поэтапно, сделать рефакторинг системы, или добавить, по необходимости, микросервисы.

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

Кому подходит микросервисная архитектура?

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

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

Конечно, микросервисы отлично взаимодополняют друг друга с практиками CI/CD (это комбинация непрерывной интеграции от англ. continuous integration и непрерывной доставки от англ. continuous delivery). Дело в том, что каждый сервис можно разрабатывать, тестировать и развертывать отдельно от остальных, что позволяет быстрее проходить все этапы работы и ускоряет выход продукта на рынок. Данный подход поддерживает гибкую и ориентированную на DevOps-культуру разработки, способствуя более частому и быстрому выходу релизов. 

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

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

Кейс нашего клиента

Компании, работающие в динамично развивающихся секторах, таких как FoodTech, особенно нуждаются в гибкой и масштабируемой IT-инфраструктуре. Рассмотрим кейс такой компании и объясним, почему микросервисная архитектура является для неё оптимальным решением.

DATA FOOD предоставляет экосистему IT-продуктов для сферы доставки еды, автоматизируя процесс от заказа до доставки. Их сервисами пользуются многие крупные сети, такие как Суши.Маркет и Лаваш, с более чем 600 торговыми точками в 200 городах.

Текущая инфраструктура компании включает два клиентских приложения, написанных на React и взаимодействующих с бэкэндом через API Gateway, а также одно монолитное клиентское приложение на React, работающее напрямую с бэкэндом. Запросы от клиентских приложений и сайтов обрабатывает платежный шлюз на Nginx, а все инструменты разработчиков и клиентские приложения размещены в облаках — TimeWeb и Yandex.Cloud, что обеспечивает гибкость и масштабируемость этой части системы, а весь бэкофис располагается на собственных серверах в Омске.

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

Таким образом, микросервисная архитектура идеально подходит для компании DATA FOOD, работающей в динамично развивающемся секторе FoodTech. Преимущества, такие как улучшенная масштабируемость, повышенная надежность, быстрота развертывания и улучшенное управление, позволяют компании эффективно справляться с пиковыми нагрузками и обеспечивать высокий уровень обслуживания клиентов. Стабильная работа экосистемы IT-продуктов DATAFOOD напрямую поддерживает успешное функционирование множества других компаний, что делает микросервисную архитектуру важным составляющим инструментом для развития всей цепочки связанных бизнесов.

Заключение

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

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