CC BY
45УДК 004.41
Танатканова А.К.
студентка 4 курса, специальности Информатика Костанайский государственный университет им. А.Байтурсынова
(Казахстан, г. Костанай)
ПРИМЕНЕНИЕ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ ПРИ РАЗРАБОТКЕ
КОРПОРАТИВНЫХ ВЕБ-ПРИЛОЖЕНИЙ
Аннотация: Данная статья посвящена вопросам целесообразности применения микросервисной архитектуры при разработке корпоративных веб-приложений. Рассмотрены причины возникновения, актуальность применения и основные особенности микросервисной архитектуры.
Ключевые слова: монолитная архитектура, микросервисная архитектура, веб-приложение, масштабируемость, микросервисы.
Возрастающие требования к современным корпоративным веб-приложениям, такие как возможность предоставление программного интерфейса (API), интеграция с другими веб-приложениями через различные веб-службы, обработка большого количества запросов, масштабируемость, обеспечение необходимой скорости доступа к информации, обеспечение высокой надёжности с точки зрения информационной безопасности, исключение и минимизация рисков утечки корпоративных данных, приводят к тому, что корпоративные веб-приложения с монолитной архитектурой становятся неудобными в разработке, сложно тестируются и вводятся в эксплуатацию с большими временными задержками.
В уточнении выше сказанному, корпоративные веб-приложения с монолитной архитектурой, как правило, представляют из себя приложения с 3-х уровневой архитектурой, где каждый уровень отвечает за формирование определённого представления для пользователя, обработку бизнес-логики приложения, обеспечения доступа к данным.
Уровень представления - уровень, с которым взаимодействует пользователь, включает компоненты пользовательского интерфейса, такие как CSS- стили, статически html - страницы, JavaScript код. Главная функция уровня представления - это отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте бизнес-логики.
Уровень бизнес-логики - уровень набор компонентов, которые отвечают за обработку данных, полученных от уровня представления, непосредственно взаимодействует с уровнем доступа к данным, может быть реализован с помощью технологий Java EE, ASP.NET.
Уровень доступа к данным - хранит модели данных, используемых сущностей в рамках бизнес-логики приложения, отвечает за мониторинг транзакций и поддерживает консистентное состояние данных. Для большинства корпоративных веб-приложений основная часть логики уровня доступа к данным сосредоточена в СУБД (Система управления базами данных) таких, как MySQL, Oracle и PostgreSQL.
Между тем, корпоративные веб-приложения стремительно эволюционируют, становятся распределёнными, могут предоставлять определенную функциональность и использоваться в составе другого веб-приложения с помощью веб-сервисов, основанных на протоколах REST, SOAP и XML-RPC. Это приводит к тому, что корпоративные веб-приложения с монолитной архитектурой испытывают сложности с наличием уязвимостей в безопасности из-за участия в процессах множества систем, испытывают сложности с реализацией асинхронной связи между приложениями, испытывают потребность в сложных механизмах управления транзакциями при взаимодействиях между логически раздельными системами и их уровнями.
Особое внимание следует уделить к возрастающим требованиям к повышению гибкости и улучшению масштабируемости корпоративного веб-приложения, слабосвязанности его программных компонентов и возможность построения сложных систем путем интеграции сервисов от различных производителей независимо от используемых языков программирования и технологий.
Основные недостатки монолитной архитектуры:
- сложно или практически невозможно изменить технологический стек веб-приложения во время разработки.
- необходимость полного обновления системы при изменении незначительных деталей приложения;
- если веб-приложение аварийно завершает работу, то весь функционал недоступен для пользователей;
- сложности при масштабировании;
Монолитная архитектура корпоративных веб-приложений не позволяет быстро и оперативно реагировать на изменения требований к бизнес-логике веб-приложения.
Микросервисная архитектура родилась из монолитной архитектуры. Главное отличие микросервисной архитектуры от монолитной - использование микросервисов, специализированных программ (модулей) для выполнения бизнес-логики корпоративного веб-приложения.
Концепция декомпозиции сложной системы корпоративного веб-приложения на микросервисы - это способ создания веб-приложения в виде набора небольших сервисов, каждый из которых исполняется как отдельный процесс, который обменивается данными, используя либо синхронные протоколы, такие как HTTPs(HTTP) или асинхронные протоколы, такие как AMQP.
Микросервисы могут разрабатываться и развертываться независимо друг от друга. Каждый микросервис может имеет свою собственную базу данных, чтобы быть отделенной от других служб. Микросервисы инкапсулируют определённый функционал системы и создаются исходя из особенностей предметной области корпоративного веб-приложения.
Следует отметить, что микросервисы - это разновидность сервис-ориентированной архитектуры (SOA), применяемая для формирования распределенных программных систем при разработке корпоративных веб-приложений. На данный момент микросервисы постепенно становятся стандартом развития корпоративных программных систем.
Основные преимущества микросервисной архитектуры :
- использование различных языков программирования и программных средств, оптимальных для реализации каждого микросервиса;
- взаимозаменяемость микросервисов;
- независимость микросервисов друг от друга, каждый микросервис может быть развернут независимо от других служб;
- упрощение процесса масштабирования разрабатываемого веб- приложения;
- организация микросервисов как модулей вокруг отдельных функций;
Каждый микросервис - это небольшая монолитная программа, которая выполняет
свою функцию. В корпоративных веб-приложениях с микросервисной архитектурой можно добавлять любое количество новых микросервисов, расширяя функциональность системы.
Микросервисная архитектура устраняет вышеназванные недостатки монолитной архитектуры корпоративных веб-приложений, обеспечив изоляцию и минимизацию изменений системы, ускорение разработки приложений. Важно учитывать, что система на базе микросервисной архитектуры больше подвержена ошибкам из-за использования сети передачи данных для взаимодействия между микросервисами, что приводит к дополнительным издержкам при обработке пользовательских запросов и сложнее реализовать общее поведение для всех микросервисов (авторизация запросов, агрегация данных).
Подводя итоги, прежде чем принять решение о разработке корпоративного веб-приложения на базе микросервисной архитектуры, необходимо проанализировать перечисленные ниже факторы.
Новые технологические шаблоны: Микросервисы - это совершенно иной подход к разработке корпоративных веб-приложений. Они требуют наличия нового множества сопутствующих компонентов, так как основаны на сетевом взаимодействии, необходимые технологии для обнаружения микросервисов, координация нагрузки, управление модулями и среды ведения журналов, уже существуют, однако их нужно собрать воедино, что требует значительных затрат времени на экспериментирование, наработку соответствующих навыков и обучение разработчиков.
Список литературы:
1. Микросервисы, SOA и API: друзья или враги? - [Электронный ресурс]. URL: https: //www.ibm.com/developerworks/ru/library/1601 _clark-trs/index.html
2. Архитектура корпоративных программных приложений - [Электронный ресурс]. URL:
http://www.ooart.ru/uploads/book/arhitektura_korporativnyh_programmnyh_prilozhenij_fau ler_m.pdf
3. Сервисы, архитектура и унаследованные системы - [Электронный ресурс]. URL: https://www.osp.ru/os/2014/08/13043486/
4. Микросервисы- [Электронный ресурс]. URL: https://habrahabr.ru/post/249183/
5. Архитектура распределённых приложений - [Электронный ресурс URL: https: //www. itweek. ru/infrastructure/article/detail. php?ID=66147
6. Архитектура современных Web-приложений- [Электронный ресурс]. URL: http://compress.ru/article.aspx?id=10951
