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

АННОТАЦИЯ

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

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

Возрастающие требования к современным корпоративным веб-приложениям, такие как возможность предоставление программного  интерфейса (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