Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: Научного журнала «Студенческий» № 18(18)

Рубрика журнала: Информационные технологии

Скачать книгу(-и): скачать журнал часть 1, скачать журнал часть 2

Библиографическое описание:
Зяблов Д.В., Кот А.А. ПРИМЕНЕНИЕ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ ПРИ РАЗРАБОТКЕ КОРПОРАТИВНЫХ ВЕБ-ПРИЛОЖЕНИЙ // Студенческий: электрон. научн. журн. 2017. № 18(18). URL: https://sibac.info/journal/student/18/87616 (дата обращения: 29.03.2024).

ПРИМЕНЕНИЕ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ ПРИ РАЗРАБОТКЕ КОРПОРАТИВНЫХ ВЕБ-ПРИЛОЖЕНИЙ

Зяблов Дмитрий Валерьевич

магистрант, кафедра ПИКС БГУИР,

Беларусь, г. Минск

Кот Андрей Алексеевич

магистрант, кафедра ПИКС БГУИР,

Беларусь, г. Минск

АННОТАЦИЯ

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

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

 

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

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

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

Уровень бизнес-логики - уровень набор компонентов, которые отвечают за обработку данных, полученных от уровня представления, непосредственно взаимодействует с уровнем доступа к данным, может быть реализован с помощью технологий Java EE, ASP.NET.

Уровень доступа к данным - хранит модели данных, используемых сущностей  в рамках бизнес-логики приложения, отвечает за мониторинг транзакций и поддерживает консистентное состояние данных. Для большинства корпоративных веб-приложений основная часть логики уровня доступа к данным сосредоточена в СУБД (Система управления базами данных) таких, как MySQL, Oracle и PostgreSQL.

Между тем, корпоративные веб-приложения стремительно эволюционируют, становятся распрелёнными, могут предоставлять определенную функциональность и использоваться в составе другого веб-приложения с помощью веб-сервисов, основанных на протоколах REST, SOAP и XML-RPC. Это приводит к тому, что корпоративные веб- приложения с монолитной архитектурой испытывают сложности с наличием уязвимостей в безопастности из-за участия в процесах множества систем, испытвают сложности с реализацией асинхронной связи между приложениями, испытывают потребность в сложных механизмах управления транзакциями при взаимодействиях между логически раздельными системами и их уровнями.

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

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

– сложно или практически невозможно изменить технологический стек веб-приложения во время разработки.

– необходимость полного обновления системы при изменении незначительных деталей приложения;

– если веб-приложение аварийно завершает работу, то весь функционал недоступен для пользователей;

– сложности при масштабировании;

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

Структурная схема монолитной архитектуры веб-приложения представлена на рисунке 1.

 

Рисунок 1. Структурная схема монолитной архитектуры веб-приложения

 

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

Структурная схема микросервисной архитектуры веб-приложения представлена на рисунке 2.

 

Рисунок 2. Структурная схема микросервисной архитектуры веб-приложения

 

Концепция декомпозиции сложной системы корпоративного веб-приложения на микросервисы - это способ создания  веб-приложения в виде набора небольших сервисов, каждый из которых исполняется как отдельный процесс, который обменивается данными, используя либо синхронные протоколы, такие как HTTPs(HTTP) или асинхронные протоколы, такие как AMQP.

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

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

Следует отметить, что микросервисы - это разновидность сервис-ориентированной архитектуры (SOA), применяемая для формирования распределенных программных систем при разработке корпоративных веб-приложений. На данный момент микросервисы постепенно становятся стандартом развития корпоративных программных систем.

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

– использование различных языков программирования и программных средств, оптимальных для реализации каждого микросервиса;

– взаимозаменяемость микросервисов;

– независимость микросервисов друг от друга, каждый микросервис может быть развернут независимо от других служб;

– упрощение процесса  масштабирования разрабатываемого веб- приложения;

– организация микросервисов как модулей вокруг отдельных функций;

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

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

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

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

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

Пригодность для приложений: Микросервисная архитектра необязательно подходит для каждого корпоративного веб-приложения. Изменение кода, уже существующего веб-приложения с монолитной архитектурой, также представляет собой трудоёмкую задачу.

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

–  понимание принципов работы с событийными приложениями без централизованного хранения рабочих данных;

–  убедиться, что логика приложения не зависит от сохранения состояния  -  это необходимо для того, чтобы реализовать ощутимые преимущества быстрого масштабирования;

– учесть возможные побочные эффекты при работе с асинхронной связью;

– учесть ограничения на обработку ошибок при использовании HTTPs(HTTPs) протоколов, в отличие от внутреннего взаимодействия.

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

 

Список литературы:

  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_fauler_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

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.