АННОТАЦИЯ 3
Перечень условных обозначений 3
Введение 4
1 Актуализация текущего состояния систем 6
1.1 Проблемы текущих систем ТГУ 6
1.2 Анализ контекстов систем 8
1.3 Обновленное разделение системы на сервисы 11
2 Выбор подходов и практик для решения проблем текущих систем 15
2.1 Пожелания к новой системе 15
2.2 Инструментарий 16
2.2.1 ASP.NET Core 17
2.2.2 Entity Framework Core 18
2.2.3 DAPR 18
2.3 Архитектурный подход 20
2.4 Структура кодовой базы системы 23
2.4.1 Пакет Common 25
2.4.2 Шаблон микросервиса 27
2.4.3 Шаблон макросервиса 29
3 Проектирование и разработка прототипа системы 31
3.1 Пакет Common 33
3.2 Сервис файлов 35
3.3 Сервис профилей 39
4 Подведение итогов 46
Заключение 48
Литература
В Томском Государственном университете используются множество информационных систем для управления, формализации и автоматизации его процессов. Одним из самых значимых процессов в данной организации являются процессы, связанные с учебной деятельностью.
В ТГУ используются системы как от сторонних поставщиков, так и собственные разработки. 3 самых крупных системы собственной разработки - ТГУ.Аккаунты, Личный кабинет студента ТГУ, ТГУ.Сотрудники - существуют более 8 лет, в течение которых постоянно дорабатывались. В отделе, который ответственный за разработку этих систем, сменилось несколько команд. С течением времени накапливались проблемы: недостаточное документирование кода и мотивации принятых решений, недостаточное покрытие кода тестами, или в некоторых случаях, нетестируемый код, неудачные архитектурные решения по интеграции между приложениями, которые сделали систему крайне уязвимой к кратковременным сетевым сбоям, устаревший фреймворк, который имеет зависимости от проприетарной ОС Windows Server, зависимость сервисов от проприетарной СУБД MS SQL Server, отсутствие средств трассировки распределенных запросов, проблемы с безопасностью и проверкой прав доступа. Все эти факторы привели к тому, что работать с кодовой базой становилось все сложнее, а внесение изменений требует все больше времени на проверку и может задеть совершенно неожиданные компоненты.
В конце 2023 года от нескольких подразделений университета поступил запрос на оценку трудозатрат по реализации внушительного набора объемных функций в указанных системах. Из-за описанных выше проблем, запрошенный функционал было невозможно реализовать в полной мере за вменяемые сроки. Выход из ситуации команда разработки видела в перепроектировании существующих сервисов с использованием распределенной архитектуры, а в процессе проектирования учесть реализацию нового функционала. Также этот подход поможет решить проблему зависимости от проприетарной ОС и СУБД, которые не входят в список рекомендованного ПО ФСТЭК России.
Для решения описанных проблем было решено начать разработку новой системы, которая объединит возможности упомянутых существующих систем. Однако, разработка такой системы представляет из себя огромный объем работы, а команда разработки не имеет опыта разработки распределенных систем подобного масштаба, поэтому чтобы получить представление о разработке системы требуемого масштаба и отработать подходы для работы над новой распределенной системой, было решено в первую очередь разработать прототип такой распределенной системы, что является целью данной выпускной квалификационной работы.
Для реализации данной цели были выделены следующие задачи:
1) Выбрать инструменты и архитектурные подходы для упрощения работы над новой системой.
2) Разработать прототип новой системы.
3) На основе разработки прототипа сделать выводы о выбранных подходах и инструментах.
Решению поставленных задач посвящена данная выпускная квалификационная работа.
В результате проделанной работы былопределен архитектурный подход для проектирования и разработки новой системы, разработаны шаблоны проектов микросервиса и макросервиса, которые будут использоваться командой при разработке системы; спроектированы и разработаны сервисы профилей и файлов, которые были реализованы с использованием шаблонов макросервиса и микросервиса соответственно; с использование фреймворка DAPR разработанные сервисы образуют прототип системы, который позволил проверить возможности выбранных инструментов, продемонстрировать сценарий межсервисного взаимодействия и простоту его имплементации в системе.
В данный момент прототип используется для проверки более сложных сценариев, связанных с распределенными транзакциями. Перед командой стоят задачи: определиться с необходимостью и возможностью использования компонента Workflow, предоставляемого DAPR, для управления распределенными транзакциями; сделать выбор системы авторизации запросов; сделать выбор компонента API Gateway.
Все поставленные задачи были выполнены, а цель работы достигнута.
