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

Введение

Выбор конкретной архитектуры информационной системы является важной задачей для команды разработчиков и предприятия в целом, т.к. она влияет на эффективность и качество ИС. Большинство веб – систем и приложений на данный момент проектируются на основе монолитной архитектуры, которая требует много времени для создания, внесения изменений и развертывания программ. Используя микросервисную архитектуру, конкретный веб – сервис может быть разработан, модифицирован и развернут в течение короткого промежутка времени, не затрагивая область действия других процессов или служб [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 – Исходные данные работы микросервисов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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