Централізоване керування музичними сервісами



Стаття | Article    

Download

Centralized management of music services

Bohomol Roman

Igor Sikorsky Kyiv PolytechnicInstitute

Kyiv, Ukraine

Annotation. The purpose of the article is to review the available ways to solve the problem, highlight their advantages and disadvantages and model an architectural solution that combines all the advantages, and will not contain the disadvantages of the reviewed analogues. The best solution for the implementation of this task is a software product created on the basis of the client - the server architecture of the server part, which is implemented using a microservice approach.

Keywords: music services, client - server architecture, microservices, music content management.

Анотація. Мета статті – переглянути наявні способи вирішення завдання, виділити їхні переваги і недоліки і змоделювати архітектурне рішення, яке об’єднує всі переваги, а також не буде містити недоліків оглянутих аналогів. Найкращим рішенням для реалізації даного завдання являється програмний продукт створений на основі клієнт – серверної архітектури серверна части-на якої реалізована за допомогою мікросервісного під-ходу.

Ключові слова: музичні сервіси, клієнт – серверна архітектура, мікросервіси, управління музичним контентом.

Прослуховування аудіо-композицій з кожним роком стає все важливішою частиною сучасного життя, а способи доступу до аудіо контенту з кожним роком стають простішими.

В межах еволюції передачі аудіо-даних можна виділити декілька стадій розвитку: етап превалювання фізичних носіїв для запису файлів електронного формату на кінцевій машині користувача (компакт-дисків) та етап розповсюдження онлайн-доступу.

Недоліки дисків досить численні та полягають у необхідності зберігання даних, нестійкості до пошкоджень, незручності використання, а також можливості втрати даних. До того ж, протягом певного часу тенденцією було зберігання композицій на машині користувача, що було обумовлено лімітованими ресурсами інтернету. В результаті це призвело до появи низки недоліків, які були пов’язані із неможливістю вчасного отримання новинок музики в момент їх виходу та появи на ринку і пошуку існуючої композиції. Дані недоліки породили сервіси з прослуховування музичних композицій онлайн. Даний підхід є зручним для користувача, але в ході розвитку ресурсів такого типу та збільшенням їх кількості виникла проблема забезпечення централізованого доступу до сервісів.

Для визначення шляхів вирішення цих недоліків розглянемо існуючі сервіси на прикладі Spotify, Apple Music, YouTube Music. Музика може бути переглянута або відсортована (знайдена) завдяки можливості пошуку з використанням різних параметрів, таких як виконавець, альбом, жанр, список відтворення. Для користувача надається можливість створення і редагування списків програвання. Проте, наявність платних підписок, необхідність переключатись між різними сервісами породжує завдання централізованого управління в межах міжсервісної взаємодії та агрегації аудіо контенту користувача.

Для побудови програмного рішення необхідно проаналізувати існуючі сервіси, а саме формат взаємодії з ними. В якості джерела контенту для подальшого централізованого управління та агрегації. Аналізуючи документацію роботи API(Application Programming Interface)[1] вищезгаданих сервісів можна зробити висновок, що дані сервіси мають схожий тип авторизації за допомогою відкритого протоколу OAuth 2.0[2], який дозволяє третій стороні надавати права обмеженого доступу до ресурсів користувача без необхідної передачі логіна і пароля.

Для агрегації і централізованого управління музичних сервісів було виділено ряд загальних ознак і функцій, які притаманні кожному із вищезгаданих сервісів таких як: YouTube Music, Deezer Spotify, що відіграють основну роль по взаємодії з музичним контентом. Під час огляду існуючих рішень було знайдено наступні додатки: Soundiiz і Musconv.

Додаток Soundiiz, реалізований за допомогою веб-орієнтованої архітектури, об’єднує близько тридцяти музичних сервісів і реалізовує алгоритми передачі музичних даних між потоковими платформами. До основних можливостей даного додатку можна віднести синхронізацію списків відтворення за допомогою якої можна централізовано керувати створенням, видаленням, редагуванням музичного контенту всіх сервісів. Також виконана можливість імпорту та експорту даних за допомогою файлів з розширенням M3U, XSPF, TXT, CSV, URL посилання та ін.

MusConv – платформа яка об’єднує в собі більш ніж 30 музичних сервісів, має багато спільних можливостей із Soundiiz, а саме синхронізацію музичних списків, експорт і імпорт даних. Додаток має і суттєву перевагу над Soundiiz, тому що має своє графічне вікно користувача (десктоп) і є доступним для більшості сучасних пристроїв.

Серед переваг даних рішень можна виділити зручність створення нових списків відтворення, адже додається можливість шаблонного завантаження файлів e вказаному форматі і їх програмна обробка (парсинг). Ці файли створюються за допомогою популярних музичних плеєрів, що дозволяє користувачеві відмовитись від ручного вводу інформації, а також надає можливість парсингу даних за допомогою URL-посилання. Серед недоліків можна виділити платну підписку для кожного із продуктів, відсутність віконного додатку під ОС Windows, Linux у Soundiiz, який міг би спростити доступ користувачів до сервісу. Також при великому навантажені на дані ресурси можливе «зависання» програми на деякий час, для того аби не призвести даних незручностей для користувача накладаються обмеження по кількості створених треків в одному із списку відтворень.

Відповідно до проведеного огляду було встановлено переваги та недоліки існуючих систем. В відповідності до наявних недоліків постає завдання по реалізації аналогу існуючих рішень, що забезпечить поєднання переваг та мінімізує кількість недоліків. Виходячи з огляду аналогів завдання на реалізацію програмного засобу складається з написання системи, що міститиме в якості представлення для користувача графічний віконний додаток. Дана система повинна поєднувати всі переваги сервісів, а саме: можливість автоматичного завантаження музичних композицій на основі завантаження спеціалізованого формату файлів, які створюються за допомогою аудіо-програвачів з різним розширенням, можливість отримання списку відтворення за допомогою URL-посилання, надати змогу користувачеві для вільного і та можливість пошуку композиції в наслідок вводу тексту, який буде зчитано і знайдено відповідний трек у кожному із сервісів. Також потрібно уникнути недоліків, які будуть спровоковані за умови обробки великого обсягу даних: наявність суттєвого та помітного зниження швидкості відклику. Важливим аспектом є наявність платної підписки, яка накладає багато суттєвих обмежень по зручності користування.

Для того щоб створити комплексне програмне рішення в межах описаної вище задачі, необхідно визначити загальний тип міжкомпонентної взаємодії в межах побудови архітектурного рішення, виходячи з критерію про наявність декількох пристроїв в одного користувача та значної кількості кінцевих користувачів сервісу, залишаються наступні архітектурні рішення: клієнт-серверна архітектура [3], Сервіс-орієнтована архітектура (SOA, англ. Service-oriented architecture) [4].

Клієнт-серверну архітектуру можна сприймати як концепцію інформаційної мережі, де головна частина ресурсів знаходиться на серверах, які обслуговують своїх клієнтів. Дана архітектура складається із наступних компонентів:

1) Набір серверів, які обробляють запити клієнтів.

2) Набір клієнтів, що звертаються до серверної частини системи.

3) Рівень комунікації, що базується на мережевих протоколах взаємодії та забезпечує обмін інформацією між компонентами системи, а саме клієнтами та серверами.

Сервіс-орієнтована архітектура(SOA) – модульний підхід для розробки програмного забезпечення, в якому компоненти розподілені в різних вузлах мережі, які є слабоповя’заними між собою, а також мають стандартизовані інтерфейси для взаємодії за стандартизованими протоколами рис. 1.

Рис. 1. Структура SOA

Програмні комплекси, які розроблені на основі сервіс – орієнтованої архітектури, реалізуються як набір веб-служб, взаємодіючих зачасту про протоколу SOAP [5].

Один із варіантів сервіс – орієнтованої архітектури – мікросервісна архітектура.

Архітектурний стиль мікросервісів – це підхід, коли єдиний додаток реалізовується як сукупність невеликих, самодостатніх, незалежних, не тісно зв’язаних сервісів, що спілкуються між собою за допомогою набору наступних протоколів: HTTP, gRPC, AMQP. Кожен сервіс побудований навколо певних бізнес-потреб і є відповідальним за якийсь конкретний бізнес-процес та розгортається незалежно один від одного за допомогою повністю автоматизованого середовища [6]. Для реалізації кожного сервісу в межах мікросервісної архітектури може бути використана одна із орієнтованих під дану задачу технологій, що надає можливість при створенні в межах окремо взятого сервісу абстрагуватись від технологій розробки та відповідних мов програмування за допомогою яких були реалізовані інші сервіси. Кожен сервіс як окремий компонент мікросервісної архітектури може містити взаємодію з різними типами джерел даних, без привязки до конкретного типу в межах всієї архітектури. Даний підхід має наступний список переваг:

1) Спрощення доповнення існуючого, та модернізації функціоналу за допомогою додавання окремого компоненту в архітектуру чи зміни існуючого відповідно.

2) Можливість абстрагування від існуючих компонентів архітектури, що дозволяє незалежно змінювати логіку поведінки окремо взятої архітектурної одиниці.

3) Відмовостійкість, що забезпечується можливістю розгортання нового екземпляру архітектурної одиниці(сервісу) у випадку його відмови.

У відповідності до специфікації технічного завдання на розробку та специфіки і обмежень, переваг та недоліків кожного з видів архітектурних підходів, було прийняте рішення про реалізацію взаємодії клієнтської сторони додатку з сервером в межах клієнт серверної архітетури та реалізацію серверної частини на основі мікросервісної архітектури. Загальна схема компонентів системи спроектована та продемонстрована на рис. 2.

Рис. 2. Схема роботи системи

Розглянемо серверний компонент архітектури. Виходячи з критерію завантаженості класу подібних підсистем серверне рішення по агрегації контенту та його отриманню, було спроектоване на основі мікросервісної архітектури, що забезпечує можливість горизонтального та вертикального масштабування [7] кінцевого рішення в відповідності до навантаження в поточний момент часу. Взаємодія в межах мікросервісного рішення побудована з використанням шини даних, що забезпечує централізоване управління міжсервісним трафіком та гарантує його отримання екземпляром конкретного мікросервісу. Шина даних є вхідною точкою в механізм між сервісної комунікації та відповідає за побудову маршрутів для мережевих пакетів.

Для отримання обмеженого захищеного доступу до даних користувача в кожному із музичних сервісів на клієнтській частині додатку необхідно реалізувати авторизацію на основі протоколу OAuth2.0, який підтримує кожен із сервісів, за допомогою якого буде надано маркер доступу (access token), який в свою чергу надаватиме можливість виконувати дії по обробці даних без безпосередньої участі користувача у даному процесі.

ТЕХНІЧНЕ РІШЕННЯ

Для реалізації спроектованих архітектурних рішень було проаналізовано наявні технології, на основі яких можна розробити програмний продукт в межах обумовленої архітектури. Було розглянуто перелік технологій, що надають інструментарій по реалізації міжклієнтської взаємодії в межах клієнт – серверної архітектури програмного рішення такі як JAVA, .NET. На основі порівняння технологій [8] WPF і Swing, а саме на основі характеристик ресурсозатратності по швидкодії, оперативній пам’яті, та складності реалізації. Результати порівняння продемонстровано на рис.3.

Рис. 3. Порівняння швидкодії WPF та Swing

Було прийняте рішення по реалізації застосунку на основі платформи .NET, як оптимальної по співвідношенню вище перерахованих критеріїв. Дана платформа включає в себе наступні переваги:

1) Забезпечення узгодженого об'єктно-орієнтованого середовища програмування для локального збереження і виконання об'єктного коду, для локального виконання коду, розподіленого в інтернеті, або для віддаленого виконання.

2) Забезпечення середовища виконання коду, що мінімізує конфлікти при розгортанні програмного забезпечення та управлінні версіями.

3) Забезпечення єдиних принципів розробки для різних типів додатків, таких як додатки Windows і веб-додатки.

Станом на сьогодні в межах платформи .NET для реалізації графічної клієнтської частини виділяють технології WPF і WinForms.

WinForms – технологія для створення графічного інтерфейсу користувача. Доступ до елементів інтерфейсу відбувається за допомогою обгортки Win32 API в керованому коді [9].

Технологія WPF (Windows Presentation Foundation) є частиною платформи .NET і являє собою підсистему для побудови графічних інтерфейсів.

При створенні додатків на основі WinForms за відображення елементів управління і графіки відповідали такі частини ОС Windows, як User32 і GDI+[10], то додатки WPF забезпечують побудову графіки застосунку за допомогою технології DirectX. У цьому полягає ключова особливість побудови графічного відображення (рендеринга) в WPF. Використовуючи WPF, значна частина роботи по відображенні графіки, виконується графічним процесором на відеокарті, що також дозволяє скористатися апаратним прискоренням графіки.

Аналізуючи описані вище переваги та наведене порівняння даної технології з аналогами, було прийнято рішення обрати технологію WPF для розробки графічного інтерфейсу користувача.

Для реалізації серверної частини додатку в межах архітектурного рішення, на даний момент часу виділяють наступний набір технологій Spring (Java), ASP.NET Core (C#) , GGI (C++). Розглянемо дані технології більш детально.

Технологія Java Server Pages (JSP) [11] є компонентом єдиної технології створення застосувань що базуються на J2EE, з використанням web інтерфейсу. Дана технологія аналогічна до ASP Web Forms, на разі її застосування обмежене підтримкою вже існуючих проектів. На зміну даній технології прийшло рішення в вигляді фреймворку Spring, що містить розмежування логіки та представлення. Причому даний фреймворк побудований з урахуванням принципів S.O.L.I.D., що надає гнучкості коду в межах архітектури додатку. Відповідно до порівняльної характеристики фреймворків наведена на рис. 4., фреймворк spring швидший, а також забезпечує архітектурно коректний підхід до реалізації серверного застосування.

Рис. 4 Порівняння фреймворків

Також наявна широко використовувана технологія CGI (загальний інтерфейс шлюзу), яка спеціально застосовується для створення динамічних веб-сторінок. Відповідно до технології CGI, НТТР запит, який містить посилання на динамічну сторінку, в момент опрацювання веб-сервером, генерує новий процес і запускає потрібну прикладну програму. Технологія CGI для розробки веб-додатків можна використовувати скрипти наприклад Python, Perl, Tcl. Відповідним недоліком такого підходу є відсутність можливості побудови складного рішення в межах архітектури поточного серверного застосування.

Однією із найновіших технологій для розробки веб-додатків – ASP.NET Core. Дана технологія є альтернативою розвитку платформи ASP.NET. ASP.NET Core може працювати поверх крос-платформної середовища .NET Core, яке може бути розгорнуте на основних популярних операційних системах: Windows, Mac OS, Linux, що забезпечує можливість створення кросс-платформених рішень.

Порівнюючи технології СGI та ASP.NET Core [12] можна дійти до висновку, що СGI є складна в реалізації та містить високий поріг для входу спеціалістів, а також не надає можливості побудови коректного архітектурного рішення, що є ключовим фактором для реалізації підсистем даного класу.

Порівняння швидкості опрацювання одного і того самого запиту серверним рішенням реалізованим на GGI та ASP.Net зображено на рис 5.

Рис. 5 порівняння швидкодії реалізацій серверних рішень CGI та ASP.NET CORE

В межах огляду було зроблено порівняння технологій Spring і ASP.NET Core [13] по критеріям швидкості перетворення структури даних у послідовність бітів (серіалізація) результати якого наведено на рис. 6.

Рис. 6 Порівняння швидкодії серіалізації структур даних на базі ASP.NET Core та системи на базі Spring

На основі наведених порівнянь технологій по набору вказаних критеріїв, таких як швидкість обробки запиту, ресурсоємність в межах оперативної пам’яті та процесорного навантаження, а також складності реалізації поставленого завдання за допомогою технології було прийняте рішення про оптимальність використання технології .net core для побудови серверного рішення в межах мікросервісної архітектури для обумовленого технічного завдання на розробку.

ВИСНОВКИ

Під час написання статті було оглянуто завдання централізованого управління музичними сервісами і проаналізовано існуючі аналоги для вирішення поставленої задачі. Під час огляду рішень було виявлено ряд недоліків, які були пов’язані з платною підпискою і накладанням обмежень на користувача, а також можливе навантаження на систему під час обробки великої кількості даних.

Для вирішення завдання було змодельоване комплексне архітектурне рішення, складовими частинами якого є клієнт – серверна архітектура в межах взаємодії клієнтського додатку з сервером системи та рішення на основі мікросервісної архітектури для серверної частини застосунку в відповідності до вказаних вимог та критеріїв.

Під час огляду технічного рішення для реалізації поставленої задачі було проаналізовано і порівняно технології, мови програмування за критеріями швидкодії системи і часових затрат для написання даного продукту. В результаті порівняння було зроблено висновок, про вибір платформи .net core та технологій ASP.NET Core для реалізації кожного мікросервісу в межах серверу та технології WPF для реалізації клієнтського застосунку.

ЛІТЕРАТУРА

  1. https://www.mulesoft.com/resources/api/what\-is\-an\-api (дата звернення 05.05.2020).
  2. https://oauth.net/2/ (дата звернення 06.05.2020).
  3. https://www.w3schools.in/what\-is\-client\-server\-architecture/ (дата звернення 10.05.2020).
  4. https://martinfowler.com/articles/microservices.html (дата звернення 10.05.2020).
  5. https://searchapparchitecture.techtarget.com/definition/SOAP\-Simple\-Object\-Access\-Protocol (дата звернення 11.05.2020).
  6. https://www.safetydetectives.com/blog/what\-is\-rogue\-security\-software\-and\-how\-to\-protect\-against\-it/\(дата звернення 11.05.2020).
  7. http://dspace.nbuv.gov.ua/handle/123456789/161488\(дата звернення 11.05.2020).
  8. https://www.codeproject.com/Articles/92812/Benchmark\-start\-up\-and\-system\-performance\-for\-Net\(дата звернення 14.05.2020).
  9. https://en.wikibooks.org/wiki/C%2B%2B\_Programming/Code/API/Win32\(дата звернення 14.05.2020).
  10. https://docs.microsoft.com/en\-us/windows/win32/gdiplus/\-gdiplus\-overview\-of\-gdi\-\-about\(дата звернення 14.05.2020).

  11. https://www.tutorialspoint.com/jsp/jsp\_overview.htm (дата звернення 15.05.2020).
  12. https://ela.kpi.ua/bitstream/123456789/27860/1/Vovk\_magistr.pdf (дата звернення 15.05.2020).

  13. https://www.techempower.com/benchmarks/ (дата звернення 20.05.2020).
May 30, 2020