Микросервисная архитектура подсистемы «Расписание занятий РГЭУ (РИНХ)»

Буланов Р.В.1, Долженко А.И.2
1 Ростовский государственный экономический университет "РИНХ"
2 Ростовский государственный экономический университет (РИНХ)

Статья в журнале

Информатизация в цифровой экономике (РИНЦ)
Том 1, Номер 4 (Октябрь-декабрь 2020)

Цитировать:
Буланов Р.В., Долженко А.И. Микросервисная архитектура подсистемы «Расписание занятий РГЭУ (РИНХ)» // Информатизация в цифровой экономике. – 2020. – Том 1. – № 4. – С. 141-152. – doi: 10.18334/ide.1.4.113371.

Эта статья проиндексирована РИНЦ, см. https://elibrary.ru/item.asp?id=48224530

Аннотация:
В статье обосновывается целесообразность разработки информационной подсистемы «Расписание занятий РГЭУ (РИНХ)» на основе микросервисной архитектуры, проводится оценка качества эффективности микросервисов. Описываемый процесс разработки и развертывания подсистемы производится в интегрированной среде PyCharm и на платформе контейнеризации приложений Docker соответственно. Основная концепция разработки базируется на создании информационной подсистемы расписания и последующего развертывания на технологической платформе Docker.

Ключевые слова: микросервис, микросервисная архитектура, нейронные сети, самоорганизующиеся карты Кохонена, разработка, развертывание, представление, ргэу

JEL-классификация: C45



Введение

Выбор конкретной архитектуры информационной системы является важной задачей для команды разработчиков и предприятия в целом, т.к. она влияет на эффективность и качество ИС. Большинство веб – систем и приложений на данный момент проектируются на основе монолитной архитектуры, которая требует много времени для создания, внесения изменений и развертывания программ. Используя микросервисную архитектуру, конкретный веб – сервис может быть разработан, модифицирован и развернут в течение короткого промежутка времени, не затрагивая область действия других процессов или служб [9]. Эти легковесные и слабосвязанные сервисы имеют различную эффективность в некоторых программных средах и нуждаются в сравнении и автоматизированной оценке.

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

Также проводится сравнение качества эффективности микросервисов в различных средах программирования: Apache, Docker и Kubernetes. Автоматизированная оценка сред выполняется с учетом тестируемых данных, в результате которого получаем конкретный результат на основе набора весов, что позволит выбрать наиболее эффективную среду для реализации подсистемы расписания.

Постановка требований для классификации

Для осуществления сравнения сред развертывания тестовые данные делятся на три класса, каждый из которых имеет конкретные характеристики: время ожидания http-запроса, http-ответа, степень нагрузки и количество модулей в системе. Разработка автоматизированной классификации выполняется на основе построения нейронной сети и самоорганизующихся карт Кохонена [6]. Реализация осуществляется с использованием среды разработки Jupyter Notebook [3], которая позволяет разработать программное решение.

Алгоритм построения самоорганизующихся карт Кохонена

Данный алгоритм выполняется в определенной последовательности [13]:

1. Инициализация веса каждого нейрона;

2. Выбор вектора случайным образом из набора обучающих данных ;

3. Проверка каждого нейрона и определение весов, которые наиболее похожи на входной вектор. Нейрон – победитель обозначаем как Лучшая Подходящая Единица (BMU) и определяется по формуле:

,

где с – BMU и функция измерения расстояния;

4. Корректировка весов происходит следующим образом: с учетом веса вектора нейрона в момент времени обновленный вектор веса определяется как:

Где – выборочное наблюдение, случайно взятое из входных данных, функция соседства, которая центрирована в нейроне – победителе , и – скорость обучения на каждой итерации;

5. Затем вычисляется окрестность BMU. Количество соседей уменьшается со временем по формуле:

Где – ширина соседнего ядра, которое также уменьшается с итерациями;

6. Повтор шага 2 для N – итераций.

Реализация карты и проведение исследования

Для создания сети Кохонена необходимо подготовить тестовые данные. Рассматриваемый набор данных хранит в себе критерии эффективности работы микросервисов, который имеет представление в виде одной таблицы, сохраненной в csv – формате с разделителями в виде запятых. Фрагменты исходных данных представлены в таблице 1.

Таблица 1 – Исходные данные работы микросервисов

Номер теста
Время ожидания http-запроса (с.)
Ожидание http-ответа (с.)
Степень нагрузки на сервис
Количество модулей в системе ( %)
Название системы контейнеризации
1
4.6
3.5
1.7
0.2

Kubernetes
2
5.4
3.0
1.6
0.1
3
4.2
2.7
1.8
0.2






63
6.5
2.8
4.6
1.5

Docker
64
5.7
2.8
4.5
1.3
65
6.3
3.3
4.7
1.6







173
6.0
3.0
5.1
2.2
Apache
174
7.7
3.0
6.5
2.3
175
6.2
2.5
5.1
2.4
После подготовки данных и обучения модели проводится анализ сервисов, реализованных в конкретных системах контейнеризации при помощи самоорганизующихся карт Кохонена [7]. Результирующие карты представлены на рисунке 1, 2 и 3.



Рисунок 1 – U – матрица для представленной сети
Рисунок 2 – «Карта хитов» для представленной сети

Рисунок 3 – Сокращение размерности измерений для представленной сети

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

Второй рисунок представляет «Карту хитов» для рассматриваемой сети. Он представляет частоту раз, при которой каждая единица карты или нейрон была BMU для каждого входного регистра. Это позволяет сравнить важность каждой единицы в плоскости компонентов и найти нейрон – победитель.

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

Третий рисунок демонстрирует уменьшение количества измерений до двух и визуализацию полученных результатов [1]. Изображение наглядно показывает, что составляющие класса 1 (apache) наиболее отличается от класса 3 (kubernetes), и что класс 2 (docker) пересекается с компонентами класса 1 и класса 3.

В соответствии с полученным результатом можно сделать вывод, что микросервисы, реализованные с помощью систем управления Apache и Kubernetes, имеют существенные различия в эффективности и работоспособности. В свою очередь, система контейнеризации Docker перенимает некоторые черты рассмотренных систем, и это дает нам возможность говорить о том, что данный продукт можно использовать на практике для построения качественной архитектуры подсистемы расписания [3].

Постановка требований для подсистемы

Ставя перед собой задачу удовлетворения потребностей студентов, преподавателей и обслуживающего персонала РГЭУ, были выделены следующие функциональные потребности для информационной подсистемы:

Для студента:

● представление расписания занятий для учебной группы (общее, на четную/нечетную недели);

● представление расписания занятий для учебной группы на определенную дату;

● представление расписания контрольных мероприятий (зачет/экзамен) для учебной группы (общее/на определенную дату).

Для преподавателя:

● представление расписания занятий для преподавателя;

● предоставление расписания контрольных мероприятий (зачет/экзамен) для преподавателя (общее/на определенную дату).

Для обслуживающего персонала:

● занятость аудитории на определенную дату и время;

● информация о расписании преподавателей;

● информация о нахождении преподавателя в аудитории.

Проектирование и разработка подсистемы

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

Для разрабатываемых микросервисов было выделено отдельное представление view в базе данных. Взаимодействие и заполнение вышеупомянутой базы было выполнено с помощью механизмов REST API. Таким образом, автозаполнение базы данными формата JSON выполняется благодаря составленным REST – запросам [2]. На рисунке 4 изображена архитектура информационной подсистемы.

1.png

Рисунок 4 – Архитектура микросервисного приложения «Расписание занятий РГЭУ (РИНХ)»

Архитектура и функциональная составляющая подсистемы.

Работоспособность информационной подсистемы определяется еѐ архитектурой. Благодаря такой архитектурной особенности, как модульность, подсистема может состоять из большого количества микросервисов [10]. Поэтому немаловажным вопросом при разработке микросервисного приложения является определение границ выполняемых функций каждого микрослужбы, т.к. это влияет на их количество, и соответственно на архитектуру всей подсистемы.

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

2.png

Рисунок 5 – Микросервисная архитектура информационной подсистемы «Расписание занятий РГЭУ (РИНХ)»

Каждый микросервис должен соответствовать ограниченному контексту бизнес-логики, т.к. архитектура постоянно меняется по мере изменений бизнес – требований [8].

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

При разработке информационной подсистемы расписания был использован язык программирования Python, веб – фреймворк Django, язык разметки HTML и JavaScript, каскадная таблица стилей CSS [4, 11]. На рисунке 6 представлена UML – диаграмма зависимости модели Django (Django Model Dependency Diagram) микросервиса Stud_shedule. На ней можно увидеть основные модели и связи между ними, с которыми оперирует данная микрослужба.

3.png

Рисунок 6 – Диаграмма зависимости модели Django микросервиса Stud_shedule

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

Для управления контейнером, в котором находится образ подсистемы, необходимо запустить графический интерфейс Kitematic, который автоматически приводит в рабочее состояние инструмент виртуализации Docker Machine.

Для успешного входа необходимо авторизация на централизованном ресурсе Docker Hub, который выполняет работу с платформой Docker и еѐ компонентами. На рисунке 7 представлена главная страница графического интерфейса Kitematic, на котором видно список контейнеров, которые готовы к запуску.

4.png

Рисунок 7 – Графический интерфейс Kinematic

После развертывания информационной подсистемы «Расписание РГЭУ (РИНХ)» студенты, преподаватели, а также обслуживающий персонал могут узнать расписание занятий университета. На рисунке 8 представлена главная страница сайта информационной подсистемы.

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

Рисунок 8 – Главная страница сайта

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

Рассматриваемая информационная подсистема отображает как можно изменить текущую архитектуру путем разбиения еѐ на ряд микрослужб, которые выполняют минимальную, но эффективную работу.


Источники:

1. Айвазян С.А., Бухштабер В.М., Енюков И.С., Мешалкин Л.Д. Прикладная статистика: классификация и снижение размерности. / Т.3. - М.: Финансы и статистика, 1989. – 607 c.
2. Басс Л., Клементс П.. Кацман Р. Архитектура программного обеспечения на практике. / 2-е изд., перераб. и доп. - СПб.: Питер, 2012. – 662 c.
3. Веттигли Д. Минималистичная реализация самоорганизующихся карт. Платформа разработки программного обеспечения GitHub. [Электронный ресурс]. URL: https://github.com/JustGlowing/minisom.
4. Головатый А. Подробное руководство Django. / 2-е изд., перераб. и доп. - СПб.: Символ-Плюс, 2010. – 552 c.
5. Кохонен Т. Самоорганизующиеся карты. - Москва: Бином. Лаборатория знаний, 2017. – 522 c.
6. Манжула В.Г., Федяшев Д.С. Фундаментальные исследования. , 2011. – 108-114 c.
7. Мирошниченко И.И. Анализ и моделирование бизнес-процессов. / Учебное пособие. - Ростов-на-Дону: ИПК РГЭУ (РИНХ), 2016. – 140 c.
8. Ньюмен С. Создание микросервисов. - СПБ.: Питер, 2016. – 304 c.
9. Фаулер М. Микросервисы. Martinfowler.com. [Электронный ресурс]. URL: https://martinfowler.com/articles/microservices.htm.
10. Федоров Д.Ю. Основы программирования на примере языка Python. - СПб.: СПбГЭУ, 2018. – 176 c.
11. Шполянская И.Ю. Информационные системы в экономике: проектирование и использование. / Учебное пособие. - Ростов-на-Дону: Изд-во РГЭУ (РИНХ), 2011. – 125 c.

Страница обновлена: 16.08.2022 в 15:22:52