Выбираем между монолитом и микросервисами
До 2022 года бизнесу был доступен большой объем ИТ-решений и инструментов по всем основным типам информационных систем: от ERP до программного обеспечения для кассовых аппаратов. За прошедшие два года многое ПО перестало быть доступно или возникли сложности с развитием используемых решений. В такой ситуации рано или поздно каждая компания задает типичный вопрос: «Критически важное для нашего бизнеса приложение больше не выполняет свои задачи, что делать?»
Выбирай сердцем
Самый частый ответ: «Давайте напишем свой программный продукт, разумеется, с применением микросервисной архитектуры — получим масштабируемое, надежное и гибкое решение». Но микросервисы, несмотря на заслуженную популярность, не являются панацеей для любой ИТ-задачи. Это лишь один из способов реализации бизнес-требований.
Микросервисы гибки и легко масштабируются. Они предлагают независимую схему развертывания, свободу в выборе стека разработки и используемых технологий, возможность адаптироваться под изменяющиеся требования бизнеса.
Однако есть и минусы: сложности интеграции микросервисов между собой, особенности мониторинга и трассировки, управления данными. Затраты на разработку будут в среднем в 2-–3 раза выше, чем стоимость привычного инструмента. Причем только за первый год разработки, вывода в промышленную эксплуатацию и организацию первой линии поддержки.
На старт, внимание, монолит
Монолитные системы проще в разработке, тестировании и развертывании. Монолит позволяет быстрее достигать результатов благодаря простой и целостной структуре. Если заказчик хочет оперативно получить рабочее приложение, именно монолитная архитектура станет оптимальным выбором. Она упрощает процесс разработки и развертывания, что особенно важно на начальных этапах проекта.
Однако по мере роста и усложнения приложения рано или поздно наступает момент, когда монолитная структура становится неэффективной. В этой точке возникает необходимость либо перейти на микросервисы, либо оставаться в рамках монолита, жертвуя скоростью разработки. Принятое в такой момент решение часто определяет дальнейшую судьбу проекта.
Между тем, остаться в парадигме монолита в свое время решили многие известные и даже «насквозь цифровые» компании — ретейлер Walmart и онлайн-маркетплейс Etsy. Они выбрали путь так называемых модульных монолитов — формата, вобравшего лучшее из двух миров.
Модульный путь в светлое будущее
Модульный подход к монолиту предполагает определение ключевых компонентов приложений с последующим выделением блоков данных, обслуживающих различные задачи. Далее от монолита отчуждается сервис, который нужно масштабировать и развивать, — таких независимых от монолита модулей может быть несколько, при этом монолитное ядро сохраняется нетронутым.
Модульный подход предоставляет возможность масштабировать и модернизировать приложение, сохраняя его целостность и непрерывность работы, что и позволило перечисленным компаниям успешно пройти через цифровую трансформацию без серьезных потрясений.
Один из первых примеров в свое время представила компания Amazon Prime. Парадокс: крупнейший стриминговый видеосервис, в средах которого микросервисы получили огромный импульс к развитию, вернулся к монолитной архитектуре. Переход позволил компании сэкономить значительные средства: оператор стал тратить на ИТ в 4 раза меньше, чем в микросервисной парадигме.
По нашему опыту, около 40% инфраструктурных ресурсов обычно тратится на простую поддержку работы микросервисов — так называемый микросервисный налог, — включая трассировку, обработку сетевого трафика и т. д., что может сделать использование этой архитектуры экономически невыгодным.
«Модулизация» монолита
Вот некоторые подходы и инструменты, которые помогают провести модулизацию монолита.
Domain-Driven Design (DDD)
DDD помогает разбить приложение на домены и поддомены, что позволяет лучше структурировать код и выделять независимые модули. Основные концепции DDD, такие как агрегаты, сущности, репозитории и сервисы, разрешают организовать код таким образом, чтобы каждый домен мог развиваться независимо.
Компоненты и пакеты
Использование компонентов и пакетов позволяет разделить приложение на более мелкие части, которые могут быть разработаны, протестированы и развернуты независимо. Такие компоненты могут быть опубликованы в репозиториях и применяться другими частями приложения.
Модулизация на уровне базы данных
Разделение базы данных на схемы или базы данных для каждого модуля. Это помогает уменьшить зависимость между модулями и упрощает управление данными.
Модульные фреймворки
Существует ряд фреймворков и инструментов, поддерживающих модульный подход:
- OSGi (Open Service Gateway initiative) используется для создания модульных приложений на Java. Позволяет загружать, выгружать и обновлять модули без остановки всего приложения.
- Spring Boot и Spring Cloud позволяют разрабатывать микросервисы и интегрировать их в монолитное приложение. Spring помогает легко разбить приложение на независимые модули, способные взаимодействовать между собой через REST API или message broker, а Spring Modulith, появившийся в октябре 2022 года и с тех пор активно развивающийся, может сразу разрабатывать приложение в парадигме Modular Monolith («Модульный Монолит»). Использование одного и того же фреймворка семейства Spring позволяет гибко управлять архитектурой и максимально переиспользовать бизнес-логику при переходе от монолита к микросервисам.
- Maven/Gradle — это системы сборки, предлагающая организовать проект в виде набора модулей, каждый из которых имеет свои зависимости и артефакты. Это помогает структурировать код и упрощает управление зависимостями.
API Gateway и API Management
Использование API Gateway для маршрутизации запросов к различным модулям и API Management для управления доступами и контрактами. Это помогает разделить монолит на логические части, которые могут независимо развиваться и масштабироваться и скрывать «внутреннюю кухню» монолита представляя его еще одним микросервисом с точки зрения интеграции внутри приложения.
«Модулизация» на уровне пользовательского интерфейса
Выделение отдельных модулей на уровне фронтенда, например, с использованием микрофронтендов. Это позволяет разделить приложение на независимые части, каждая из которых отвечает за свою функциональность.
Нет «серебряной пули»
Ни микросервисы, ни монолиты не являются универсальным решением для всех случаев. Выбор архитектуры не вопрос моды. Это стратегическое решение, которое должно базироваться на анализе конкретных бизнес-требований, доступных ресурсов и сроков выполнения проекта.
Основные сценарии выбора архитектуры:
- Стихийное масштабирование в B2C: микросервисы лучше справляются с быстро меняющимися нагрузками.
- Быстрый старт с ограниченным бюджетом: монолитная архитектура позволяет быстро получить работающий продукт.
- Предсказуемая нагрузка: модульный монолит обеспечит стабильность и легкость в управлении.
- Использование готовых библиотек и решений как основы для готовой микросервисной платформы: не стоит изобретать велосипед, если сроки разработки для вас в приоритете.
В целом следует понимать, что все ИТ-архитектуры — это плавно сменяющие друг друга форматы, поскольку отрасль развивается по спирали. Поэтому придется пройти несколько циклов «микромонолитов» и «макромикросервисов».
Затем вычислительные мощности преодолеют еще один качественный порог, включая более активное применение ИИ, и микросервисы как модный и передовой подход уступят место гораздо более перспективным архитектурам, которые будут делать все то же самое, но еще быстрее, эффективнее и удобнее для пользователя.
Главное при разработке — понимать основные бизнес-домены, отслеживать изменения бизнес-стратегии компании, адаптировать архитектурные шаблоны и решения «до», а не «после» и идти в фарватере технологических трендов, отметая хайповые решения.
Опубликовано 18.12.2024