Для решения проблем бизнеса, использующего интернет-технологии, автоматизируются процессы, на которые идут большие временные и финансовые затраты. В данной статье рассматривается разработка приложения с микросервисной архитектурой и его внедрение для автоматизации работы отдела маркетинга компании.
Ключевые слова : микросервисы, приложение, автоматизация, интернет-технологии, интернет-магазин.
Актуальность и проблематика
В современном мире интернет-технологии развиваются большими темпами. С каждым годом растет количество пользователей глобальной сети Интернет и постоянно увеличиваются объемы обрабатываемой информации. Все это приводит к развитию интернет-ресурсов, масштабированию их серверной части и автоматизации рутинных процессов.
Для решения проблем бизнеса, использующего интернет-технологии, автоматизируются процессы, на которые идут большие временные и финансовые затраты. В данной статье рассматривается разработка приложения и его внедрение в интернет-магазин компании, занимающейся розничной продажей мебели и аксессуаров для дома. Данное приложение предназначено для автоматизации работы по информированию клиентов отдела маркетинга компании в рамках проекта по развитию и поддержке электронной торговой площадки (интернет-магазина) компании-заказчика.
Реализация приложения основана на микросервисной архитектуре. Это вариант сервис-ориентированной архитектуры программного обеспечения, направленный на взаимодействие насколько это возможно небольших, слабо связанных и легко изменяемых модулей — микросервисов [1].
Применение микросервисной архитектуры расширило возможности масштабирования и позволило добиться большей отказоустойчивости приложения. Части приложения (микросервисы) могут функционировать на разных серверах и написаны на разных языках программирования. Обычно при разработке модульных приложений используются системы автоматизации развертывания, которые способствуют быстрой разработке и внедрению новых возможностей в приложение. Автоматизация развертывания особенно характерна для крупных проектов со сложными системами.
Микросервисная архитектура имеет ряд недостатков. Из-за сложности разработки и поддержания согласованности компонентов, часто такой вариант архитектуры встречается именно в средних и больших проектах. И для его реализации привлекаются квалифицированные специалисты.
Выбор архитектуры программного обеспечения
Существует много вариантов реализации архитектуры программного обеспечения. У каждой из них есть свои плюсы и минусы. Выбор того или иного варианта зависит от задач, которые будет решать приложение.
Интернет-магазин заказчика имеет монолитную архитектуру. Все приложение работает в едином контексте на одном сервере. При дальнейшем развитии функционала системы встал вопрос об отказоустойчивости, распределении ресурсов и быстроте разработки.
Монолитная архитектура — классическая архитектура приложения, когда весь функционал не разделен на отдельные блоки, а находится в единой связанной системе. Конечно, монолитные приложения могут иметь модульную структуру, содержать отдельные пространства имен, классы и наборы функций. Но они не разделены на изолированные блоки, которые могут работать отдельно друг от друга [3].
Разработка и внедрение приложения направлено на добавление нового функционала в системе. Рассматривалось два варианта разработки и внедрения функционала. Например, добавление в качестве модуля непосредственно в саму систему. В таком случае модуль будет представлять собой необходимое количество классов, функций и шаблонов, интегрированных в интернет-магазин заказчика. Или добавление в качестве отдельного приложения, которое функционирует независимо от основного сайта.
Монолитной архитектуре часто противопоставляют микросервисную, так как они следуют обычно противоположным аспектам. Создание и внедрение модуля в качестве отдельного приложения — это и есть подход сервис-ориентированной архитектуры.
В случае микросервисной архитектуры приложение состоит из более мелких приложений, каждое из которых функционирует отдельно в своем контексте. Эти составные части (микросервисы) приложения взаимодействуют друг с другом по сети, например посредством протокола передачи данных HTTP. Микросервисы могут функционировать как на одном, так и на разных серверах.
Каждый микросервис направлен на решение конкретной задачи. Приложение может иметь и более сложную структуру. Очень часто несколько микросервисов, задачи которых лежат в одной области, собирают в один большой сервис. Так формируется целая структура приложения. Она может состоять из нескольких сервисов, которые в свою очередь состоят из более мелких частей, направленных уже на решение определенных задач [4].
Иными словами, мы инкапсулируем (заключаем данные и функционал в оболочку) определённые контексты приложения в модули, которые могут функционировать как на одном сервере, так и на нескольких. Данные и функционал микросервиса изолированы от других микросервисов [2].
Результаты сравнения монолитной и миросервисной архитектуры представлено в таблице 1.
Таблица 1
Сравнение монолитной и микросервисной архитектуры
|
Архитектура Критерий |
Монолит |
Микросервисы |
|
Масштабируемость |
Масштабировать весь проект в целом намного сложнее |
Возможность независимого масштабирования отдельных модулей |
|
Зависимость компонентов |
Полностью либо средне зависимы |
Независимы |
|
Согласованность |
При монолитной архитектуре проще поддерживать согласованность кода, обрабатывать ошибки и т. д. |
Сложнее поддерживать согласованность компонентов из-за децентрализованной структуры |
|
Сложность разработки и сопровождения |
Ниже, чем при разработке микросервисов |
За счет большого количества применяемых технологий и особенностей архитектуры, выше |
|
Отказоустойчивость |
Обычно ниже, чем у приложений с микросервисной архитектурой |
Выше за счет децентрализации приложения |
|
Возможность использования компонентов отдельно от всей системы |
Нет. Либо нужны доработки. |
Есть |
|
Ресурсы при пиковых нагрузках |
Приходится подключать дополнительные сервера |
Возможность создания очереди для обработки при пиковых нагрузках |
При развитии функционала системы было решено уделять много внимания отказоустойчивости, распределении ресурсов и быстроте разработки приложения. Микросервисная архитектура подходит лучше всего для средних и крупных приложений, в которых важно использование разных стеков технологий, возможность независимого масштабирования и распределение нагрузки. Поэтому было решено разрабатывать и внедрять новый функционал с точки зрения микросервисной архитектуры и интегрировать его с интернет-магазином на отдельном сервере. Это позволит не нагружать основное приложение (интернет-магазин) работой с большим объемом информации по клиентам.
Проектирование приложения «Информирование клиентов »
Приложение (далее сервис) реализовано на микросервисной архитектуре. Оно состоит из нескольких независимых частей: интерфейса, бэкенд-части и базы данных. Архитектура всей системы после внедрения сервиса представлена на рисунке 1.
Рис. 1. Архитектура интернет-магазина после внедрения сервиса «Информирования клиентов»
Рис. 2. Схема структуры ПО интернет-магазина после внедрения сервиса
На рисунке 2 представлена схема интегрированного в интернет-магазин сервиса «Информирование клиентов», состоящего из двух микросервисов: фронтенд (административная панель) и бэкенд (серверная логика для работы с информацией). Объединение двух частей в единый сервис довольно абстрактно, сделано это только для видимого разграничения контекста самих микросервисов.
Административная панель — это клиентская часть сервиса «Информирования клиентов» в которой контент-менеджер или администратор может производить необходимые настройки, менять шаблоны писем, управлять базой данных с адресами клиентов.
Второй микросервис, это бэкенд-часть «Информирования клиентов». Представляет собой логику работы с данными, не имеет интерфейса и закрыт для пользователей. В нем ведется работа с данными, например выборка группы клиентов из базы данных. В отличие от административной панели, здесь идет тесная работа с базой данных. Любой входящий запрос подразумевает получение обработанной информации. Алгоритм работы микросервиса в общем случае следующий:
1) обработка входящего запроса (валидация входящих параметров);
2) отбор информации из базы данных на основе полученных параметров;
3) работа над отобранными данными (сортировка, суммирование);
4) отправка ответа с полученными данными и кодом состояния.
Данный микросервис взаимодействует с сайтом и административной панелью сервиса «Информирования клиентов». При регистрации в интернет-магазине нового пользователя, информация о его аккаунте фиксируется не только в базе данных (БД) интернет-магазина, но и отправляется в сервис, где записывается в БД уже самого сервиса.
У основного приложения (интернет-магазина) и у каждого микросервиса есть специальные клиенты, которые позволяют отдельным частям взаимодействовать друг с другом. Клиент — это аппаратный или программный компонент вычислительной системы, посылающий запросы серверу. Программа, являющаяся клиентом, взаимодействует с сервером, используя определённый протокол. Она запрашивает с сервера какие-либо данные, обрабатывает данные непосредственно на сервере, запускает на сервере новые процессы и т. п. [5]
Разработка приложения «Информирование клиентов »
Разработка приложения выполнена в кросс-платформенной интегрированной среде разработки «PHPStorm», которая предоставляет удобные инструменты для одновременной работы с системами контроля версий, локальным проектом и проектом на сервере. Для разработки и тестирования сервиса создано тестовое окружение: настроен отдельный сервер и созданы репозитории. Вся разработка проведена на тестовом сервере отдельно от production-сервера с интернет-магазином. Для тестирования взаимодействия с основным приложением (интернет-магазином) вместо production-сервера использовался тестовый сервер с копией основного приложения. Пример реализации метода «addUserData» представлен на рисунке 3.
Рис. 3. Пример программной реализации метода класса «MessagesClient» для отправки информации после регистрации пользователя
Класс «MessagesClient» находится на стороне интернет-магазина и нужен для отправки информации по аккаунту пользователя после его регистрации. На рисунке 4 представлен пример реализации класса-модели для работы с информацией по статусам сообщений.
Рис. 4. Пример программной реализации модели для работы с информацией по статусам сообщений
Все взаимодействия с базой данных в реализованном сервисе происходят с помощью дополнительного слоя абстракций — моделей. Они позволяют работать с данными как с объектами классов (связывают базы данных с концепциями объектно-ориентированных языков программирования). На рисунке 5 представлен для примера вид реализации административной панели.
Рис. 5. Вид реализации административной панели раздела для управления темами
Тестирование приложения «Информирование клиентов»
Тестирование приложения проводилось на том же сервере, где и была выполнена разработка. Характеристики сервера:
1) сервер nginx;
2) версия php 7.1;
3) версия mysql 5.7;
4) версия node js 12.13.0;
5) версия yarn 1.19.1;
6) оперативная память 16гб;
7) жесткий диск 50гб.
Для тестирования массовой рассылки с помощью разработанного приложения использовалось API специального SMTP-сервиса « mailtrap.io » . Он позволяет разработчикам тестировать рассылки без отправки сообщений на реальные email-адреса. Для фиксации результатов использовалась бесплатная версия системы мониторинга веб-приложений New Relic. С помощью нее производилось отслеживание запросов, выполняющихся в системе.
Среднее время, затрачиваемое на получение информации по клиентам (1000 записей): 3,8 секунд.
Среднее время, затрачиваемое на отправку сообщений на 1000 адресов: 15,7 секунд.
Среднее время выполнения работы по информированию 1000 клиентов до автоматизации: 20 минут.
В итоге после автоматизации удалось снизить временные затраты более чем в 20 раз.
Заключение
В рамках задачи по поддержке электронной торговой площадки компании-заказчика было создано и успешно внедрено в тестовой среде приложение, автоматизирующее процессы по информированию клиентов. Благодаря автоматизации удалось снизить временные затраты на информирование клиентов сотрудников отдела маркетинга компании-заказчика более чем в 20 раз. Приложение внедрено в качестве отдельного сервиса с микросервисной архитектурой. Это позволяет не нагружать дополнительно основное приложение (интернет-магазин) и расширяет возможности дальнейшего его масштабирования. После завершения всех испытаний в тестовой среде, сервис будет внедрен в production-среду компании-заказчика.
Литература:
- Микросервисная архитектура [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/Микросервисная_архитектура (дата обращения 30.03.2021).
- Архитектура микросервисов [Электронный ресурс]. URL: https://habr.com/ru/company/mailru/blog/320962/ (дата обращения 30.03.2021).
- Осипов Дмитрий Борисович Проектирование программного обеспечения с помощью микросервисной архитектуры // Вестник науки и образования. 2018. № 5 (41).
- Микросервисы, Microservices (перевод статьи) [Электронный ресурс]. URL: https://habr.com/ru/post/249183/ (дата обращения 30.03.2021).
- Клиент (информатика) [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/Клиент_(информатика) (дата обращения 30.03.2021).
