РАЗРАБОТКА АРХИТЕКТУРЫ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДЛЯ ОБМЕНА МУЗЫКАЛЬНЫМИ РЕСУРСАМИ

Музыкальный рынок – один из ключевых и быстрорастущих секторов мировой экономики, влияющий на культуру, общество и финансы. По данным Global Music Report 2024 (IFPI), его объем достиг 28,6 млрд долларов, увеличившись на 10,2% с 2022 года. Аналитики Goldman Sachs в отчете “Music In The Air” прогнозируют среднегодовой рост в 7,6% до 2030 года [2].

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

Для удобства саунд-продюсеров нужны платформы, которые позволяли бы распространять подобные музыкальные ресурсы как на бесплатной, так и на коммерческой основе.

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

Перед проектированием архитектуры информационной системы (ИС), необходимо описать процессы, которые в ней происходят. На рисунке 1 представлена UML диаграмма вариантов использования [3].

Рисунок 1. Диаграмма вариантов использования

Для разработки ИС обмена музыкальными ресурсами была выбрана микросервисная архитектура. Она позволяет масштабировать отдельные компоненты в зависимости от нагрузки, независимо обновлять и развертывать сервисы, оперативно реагируя на изменения требований. В отличие от монолитной и традиционной сервис-ориентированной архитектуры, микросервисы повышают устойчивость системы: сбой одного сервиса не влияет на работу остальных.

При проектировании ИС было выявлено семь микросервиса для обеспечения бизнес-логики, а также были использованы некоторые паттерны, которые применяются при микросервисной разработке:

• API-шлюз (API Gateway) – обеспечивает единую точку входа для клиентов, позволяя перенаправлять запросы на нужные микросервисы;
• внешняя конфигурация (External Configuration) – обеспечивает хранение всех конфигураций во внешнем хранилище, обеспечивая отделение процесса сборки от среды выполнения, уменьшая риски безопасности;
• обнаружение сервисов на стороне сервера (Server-Side Service Discovery) – обеспечивает определение местонахождения микросервисов, что важно в условии работы в виртуализированных средах, где их расположение и количество экземпляров меняется динамически.

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

Для обмена сообщений между микросервисами также понадобится брокер, а для предоставления пользовательского интерфейса – фронтенд-приложение.

Данные, с которыми требуется взаимодействовать микросервису, необходимо хранить в базах данных и файловых хранилищах, причем для поддержания автономности микросервисов следует соблюдать паттерн «База данных на сервис» (Database Per Service), суть которого заключается в предоставлении каждому сервису собственного хранилища данных.

Для наглядного отображения структуры системы, способов её развертывания и взаимосвязей между сервисами была построена диаграмма развертывания (Deployment Diagram) [3]. Она представлена на рисунке 2.

Рисунок 2. Диаграмма развертывания

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

При проектировании схемы применялась методология ER [4]. На рисунке 3 представлена построенная схема баз данных.

Рисунок 3. ER-диаграмма

В результате выполнения работы была спроектирована архитектура ИС для обмена музыкальными ресурсами с применением паттернов микросервисной разработки. Разработанная архитектура может быть использована для создания модульной, гибкой и масштабируемой ИС.