Scientific journal

Scientific Review. Technical science

ISSN 2500-0799

ПИ №ФС77-57440

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

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

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

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

Материалы и методы исследования

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

Результаты исследования и их обсуждение

Традиционный подход к разработке веб-приложений, как правило, подразумевает использование монолитной архитектуры приложения, когда оно разрабатывается в виде единого блока. При таком подходе зачастую используется трехуровневая клиент-серверная архитектура, при которой веб-приложение состоит из трех основных частей: клиентская часть, серверная часть и база данных. Серверная часть веб-приложения занимается обработкой HTTP-запросов, получает и изменяет данные в базе данных, а также заполняет HTML-страницы, которые затем отправляются на клиентскую часть. Именно серверная часть веб-приложения представляет собой монолитную структуру, и любые изменения в ней требуют создания и развертывания новой версии данного приложения [1, с. 42]. В данном случае вся логика запроса обрабатывается в единственном процессе. Это означает, что внедрение новой технологии повлечёт за собой необходимость модернизации всего приложения. При этом масштабировать монолитное веб-приложение придется целиком, даже если это необходимо только для одного модуля приложения (рис. 1) [2].

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

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

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

Помимо независимого масштабирования продукта (рис. 2), каждый сервис также обеспечивает жесткие границы модулей, делая при этом возможной разработку сервисов на разных языках программирования [1, с. 43].

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

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

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

Использование одного хранилища разными сервисами возможно в случае, если службы идентичны друг другу, но их базы данных никак не взаимодействуют друг с другом [3, с. 123; 4, с. 116].

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

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

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

Архитектура интернет-магазина включает в себя такие микросервисы, как «Order», «Customer» и «Catalog». Причем каждый сервис обладает собственной базой данных и содержит в себе классы, которые являются его составными частями (рис. 5).

Создание заказа подразумевает проверку кредитного лимита клиента: веб-приложение не должно допустить его превышения при размещении нескольких заказов. При использовании классического монолитного подхода таблицы «Customers» и «Orders» располагались бы в одной базе данных, и в таком случае наиболее простым решением обеспечения согласованности данных являлось бы применение транзакций (листинг 1).

Листинг 1. Транзакция проверки кредитного лимита клиента

BEGIN TRANSACTION

…

SELECT credit_limit FROM customers WHERE customer_id = ?

…

SELECT order_total FROM orders WHERE customer_id = ?

…

INSERT INTO ORDERS …

COMMIT TRANSACTION

Однако применение такого подхода в сочетании с микросервисами не представляется возможным в силу изолированности таблиц «Customers» и «Orders», находящихся в разных базах данных и ми-
кросервисах.

По этой же причине возникают неудобства с реализацией запросов к базе данных. Применение оператора JOIN, предназначенного для выполнения операции соединения данных из двух или более таблиц, становится невозможным (листинг 2).

Листинг 2. JOIN-запрос на поиск недавно зарегистрированных клиентов

SELECT * FROM customers c

INNER JOIN orders o ON c.customer_id = o.customer_id

WHERE c.register_date > ?

Решением вышеперечисленных проблем микросервисной архитектуры может стать использование таких событийно-ориентированных подходов, как Event Sourcing и Command Query Responsibility Segregation (далее – CQRS). Под событийно-ориентированным подходом подразумевают парадигму архитектуры программного обеспечения, способствующую порождению, обнаружению, потреблению событий и реакции на них. При таком подходе ядром веб-приложения становятся события, создаваемые для запуска и обмена данными между сервисами. Сервисы, в свою очередь, отслеживают определенные события и реагируют на них. Cервис, создавший событие, не знает, какой именно сервис его отслеживает. Таким образом реализуется слабая связанность микросервисов, способствующая обеспечению согласованности данных веб-приложения и упрощению его масштабирования.

Событийно-ориентированный подход Event Sourcing подразумевает сохранение цепочки изменений, вносимых в состояние веб-приложения. Таким образом, сохраненная последовательность может быть использована как указатель актуального состояния приложения или, например, как список возникших событий [5]. При использовании указанного подхода можно добиться высокой степени децентрализации чтения и изменения данных.

В Event Sourcing указателем актуального состояния веб-приложения является агрегат. Агрегатом называют набор элементов предметной области, нераздельно связанных друг с другом (рис. 6). Чтобы получить его актуальное состояние, необходимо запустить загрузку событий и их исполнение. Изменение агрегата требует создания определенного события, которое включает в себя логику изменения какой-либо части агрегата. При этом сам агрегат и его состояние не будут сохранены [5].

В качестве примера рассмотрим применение механизма Event Sourcing для сервиса «Order». В данном случае сервис не будет хранить заказы в виде строки в таблице «Orders», вместо этого будет сохранена последовательность событий для каждого агрегата «Order». Например, такие события, как «Order created», «Order confirmed», «Order shipped» и «Order delivered», будут находиться в определенной таблице «Events» (таблица).

Столбцы Event_id, Event_type и Event_data содержат в себе идентификатор, тип и описание события, столбцы Aggregate_id и Aggregate_type, в свою очередь, являются идентификаторами агрегата.

Применение архитектурного паттерна Event Sourcing имеет целый ряд преимуществ, главное из которых состоит в том, что события гарантированно публикуются при изменении агрегата, что существенно помогает в построении микросервисной архитектуры, управляемой событиями.

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

Однако все перечисленные преимущества архитектурного паттерна Event Sourcing не способны избавиться от проблемы осуществления запросов к базе данных. В её решении может помочь применение паттерна CQRS.

CQRS представляет собой архитектурный шаблон, разделяющий процедуры чтения и обновления хранилища данных. Использование данного паттерна подразумевает разбиение веб-приложения на командную и запросную составляющие. В таком случае командная составляющая будет работать с командами для создания, чтения, обновления и удаления агрегатов. Запросная же составляющая будет задействована в обработке запросов, например POST или GET-запросов [5].

Рассмотрим пример применения паттерна CQRS для интернет-магазина (рис. 7). Сервисы «Customer» и «Order» вынесем в командную составляющую веб-приложения – теперь они будут представлять API-интерфейсы создания и обновления данных о клиентах и их заказах. В свою очередь сервис «Viewing customers» будет располагаться в запросной составляющей веб-приложения, представляя собой API-интерфейс получения данных о клиентах интернет-магазина. Данный сервис будет наблюдать за событиями, которые исполняются командной составляющей веб-приложения, а также заниматься обновлением данных в хранилище интернет-магазина.

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

Заключение

Динамично развивающийся подход к разработке веб-приложений на основе микросервисов позволяет создавать отказоустойчивые веб-приложения, которые довольно просто масштабировать и обслуживать. А такая особенность, как разбиение через сервисы, помогает увеличить скорость и эффективность разработки приложения за счет деления участников команды по конкретным бизнес-задачам. Однако следует принимать во внимание возможные трудности применения микросервисной архитектуры, главным образом связанные с поддержанием согласованности данных. Эффективным способом решения этой проблемы можно считать совместное использование архитектурных паттернов Event Sourcing и CQRS, позволяющих реализовывать различные виды запросов в микросервисной архитектуре, повышая при этом производительность и безопасность всего веб-приложения.