Эволюция архитектурных стилей при разработке информационных систем: от монолитных приложений к микросервисной архитектуре



Архитектура приложения является краеугольным камнем в разработке программного обеспечения (далее ПО), определяя структуру того, как его основные компоненты взаимодействуют друг с другом. Существуют различные подходы к проектированию архитектуры приложения, наиболее распространенными являются монолитный и микросервисный подходы, которые и будут рассматриваться в данной статье. Выбор подходящей архитектуры критичен, так как он в полной мере влияет на масштабируемость, управляемость и поддержку ПО [1]. Правильный выбор обеспечивает легкость внесения изменений, развития и обслуживания продукта, в то время как неподходящая архитектура может привести к сложностям на всех этапах поддержки системы.

Ключевые слова: микросервисная архитектура, монолитная архитектура, программное обеспечение (ПО), информационная система (ИС), программный продукт (ПП).

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

Монолитная архитектура представляет собой традиционный подход к разработке приложений, где все элементы приложения, включая пользовательский интерфейс, бизнес-логику и базу данных, интегрированы в один программный блок [3]. Монолитная архитектура используется с самых ранних этапов развития программного обеспечения, начиная примерно с 1960-х годов. Это был доминирующий подход в разработке ПО в течение многих лет. Он естественным образом развивался по мере роста компьютерных технологий и стал основой для многих систем. Со временем монолитная архитектура стала более структурированной и приняла вид многоуровневой (многослойной) архитектуры [1]. Здесь приложение делится на отдельные слои, каждый из которых выполняет определенную функцию. Часто выделяют следующие слои [1, 2]:

— Слой представления (Presentation Layer): отвечает за взаимодействие с пользователем, представляя данные и интерпретируя команды пользователя;

— Слой бизнес-логики (Business Logic Layer): содержит всю логику обработки данных приложения, правила и алгоритмы обработки информации;

— Слой доступа к данным (Data Access Layer): обеспечивает доступ к базе данных, реализует операции по чтению и записи данных;

Схематичное представление взаимодействия уровней многослойной монолитной архитектуры системы представлено на рисунке 1 [6].

Рис. 1. Схема взаимодействия уровней системы в монолитной многослойной архитектуре информационной системы

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

Несмотря на разделение по слоям, модули в такой архитектуре по-прежнему остаются тесно связанными и сильно зависящими друг от друга, из чего и вытекают главные недостатки такого подхода:

— Трудности в обновлении и поддержке: Любое изменение, даже совсем незначительное, может потребовать пересборки и развертывания всего приложения — потеря достаточного количества времени при исправлении ошибок и тестировании [1];

— Ограничения в технологическом стеке: Монолитные приложения часто ограничены одной технологией или платформой, что снижает гибкость и возможности интеграции с новыми технологиями;

— Проблемы с отказоустойчивостью: если выйдет из строя какой-то один из компонентов, то продолжать работу в привычном режиме не сможет и вся система [2];

— Сложности с привлечением новых разработчиков к существующему проекту: если для добавления какого-то нового функционала нужно привлечь нового разработчика/команду разработки, ранее не имевшего дела с разрабатываемой системой, то потребуется немало времени, чтобы вникнуть в код, так как со временем код сильно разрастается, границы между модулями стираются и появляется много неочевидных связей [2];

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

Проблемы, возникающие в монолитной архитектуре, привели к развитию микросервисного подхода [2]. Микросервисная архитектура представляет собой парадигму проектирования и реализации программных продуктов. Одной из главных причин появления подобного подхода, по нашему мнению, стало желание бизнеса и разработчиков снизить сложность управления проектов по реализации масштабных программных систем. Достижение поставленной цели удалось осуществить посредством применения принципа «разделяй и властвуй», смысл которого при рассмотрении обозначенной проблемы сводится к разделению одной программы (сервиса) на множество относительно мелких и независимых, но остающихся самодостаточных программ сервисов, то есть микросервисов.

Микросервисная архитектура начала набирать популярность в 2000-х годах, особенно с развитием облачных вычислений и необходимостью в более гибких, масштабируемых и устойчивых системах. Этот подход стал широко применяться в индустрии после 2010 года, когда компании, такие как Netflix, Amazon и eBay, начали активно реализовывать и продвигать микросервисные архитектуры в своих крупномасштабных веб-приложениях [2].

В рамках данного подхода микросервис рассматривается как обособленная часть целой системы, при этом он не теряет свойство самостоятельности, сохраняя смысл существования в отрыве от глобального продукта, деталью которого он является [7]. На практике это выражается в наличии у каждого отдельного микросервиса наличия собственных интерфейсов взаимодействия, хранилищ данных и даже словарей предметной области [4]. Таким образом достигается своеобразное соблюдения принципа единственной ответственности (SRP) из SOLID, что открывает возможность повторно использовать один и тот же микросервис в продуктах. Пример схемы типичного микросервисного приложения приведен на рисунке 2 [6].

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

Приложение, в основу архитектуру которого заложены микросервисы, как правило, обладает следующими положительными свойствами [8]:

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

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

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

Однако, как и любой подход в области разработки ПО, микросервисная архитектура не является решением всех проблем и имеет свои недостатки [5].

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

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

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

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

Исследование востребованности специалистов по работе с типами архитектур

Чтобы ответить на вопрос — какая из архитектур (монолитная/микросервисная) наиболее востребована сегодня на рынке разработки ПО, нами было проведено соответствующее исследование. В качестве источника данных был использован сайт по подбору персонала — hh.ru [9].

По состоянию на 12.12.2023 на данном сайте насчитывалось порядка 1289 вакансий, содержащих среди требований к сотрудникам требование — «знание монолитной архитектуры ПО». В то же время, количество вакансий, содержащих среди требований к сотрудникам требование — «знание микросервисной архитектуры ПО» составило 2175.

Рис. 3. Соотношение количества вакансий по запросу «Монолит» и «Микросервис» в специализации «Программист, разработчик»

Таким образом, как видно из приведённой диаграммы (см рис 3), на настоящий момент спрос на IT специалистов, обладающих знаниями и навыками по работе с микросервисной архитектурой, превышает спрос на специалистов, обладающих знаниями и навыками по работе с монолитной архитектурой. Эти данные демонстрируют возрастающую важность микросервисной архитектуры в современной IT-индустрии и потенциальное снижение интереса к монолитным системам.

Заключение

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

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

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

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

Литература:

1. Гольчевский Ю. В., Ермоленко А. В. Актуальность использования микросервисов при разработке информационных систем // Вестник Сыктывкарского университета. Серия 1. Математика. Механика. Информатика. 2020. № 2 (35). URL: https://cyberleninka.ru/article/n/aktualnost-ispolzovaniya-mikroservisov-pri-razrabotke-informatsionnyh-sistem (дата обращения: 03.12.2023).
2. Кабарухин А. П. Выгоды перехода от монолитной к микросервисной архитектуре приложения // Проблемы Науки. 2022. № 1 (170). URL: https://cyberleninka.ru/article/n/vygody-perehoda-ot- monolitnoy-k-mikroservisnoy-arhitekture-prilozheniya (дата обращения: 03.12.2023).
3. Шибанов С. В., Фишбейн А. И. Обзор и оценка возможных архитектур средств контроля достоверности данных в многоуровневых клиент- серверных информационных системах // НиКа. 2011. №. URL: https://cyberleninka.ru/article/n/obzor-i-otsenka-vozmozhnyh-arhitektur-sredstv- kontrolya-dostovernosti-dannyh-v-mnogourovnevyh-klient-servernyh- informatsionnyh (дата обращения: 04.12.2023).
4. Velepucha V., Flores P. A survey on microservices architecture: Principles, patterns and migration challenges //IEEE Access. — 2023.
5. Taibi D. et al. Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages //Proceedings of the XP2017 Scientific Workshops. — 2017. — С. 1–5. (дата обращения: 04.12.2023).
6. Электронный ресурс. — Режим доступа: https://triptonkosti.ru/18-foto/shema-mikroservisnoj-arhitektury.html (дата обращения: 03.12.2023).
7. Microservices a definition of this new architectural term. — Текст: электронный // martinFowler: [сайт]. — URL: https://martinfowler.com/articles/microservices.html (дата обращения: 08.12.2023).
8. Li S. et al. Understanding and addressing quality attributes of microservices architecture: A Systematic literature review //Information and software technology. — 2021. — Т. 131. — С. 106449. (дата обращения: 09.12.2023).
9. HeadHunter (2023). [Электронный ресурс]. URL: https://hh.ru. Дата обращения: [12.12.2023].