Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Правительство Российской Федерации

Федеральное государственное автономное образовательное учреждение высшего образования

Национальный исследовательский университет «Высшая школа экономики»

Нижегородский филиал

Факультет информатики, математики и компьютерных наук

Базовая кафедра группы компаний MERA

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

На тему:

Исследование подходов построения микросервисной архитектуры на примере создания музыкального стримингового приложения

Выполнил Яковенко М.А.

Студент группы №15ПИ

Научный руководитель

Доцент Г.В. Шаров

Нижний Новгород, 2019 г.



Оглавление

• Введение
• Актуальность темы
• Проблематика
• Цели и задачи работы
• Глава 1. Теоретическая часть
• Определение сущности микросервисов
• Установление отличий микросервисной архитектуры от монолитной
• Основные компоненты микросервисной архитектуры
• Config Service
• Discovery Service
• Gateway Service
• Log Service
• Circuited Breaker
• Health Check API
• Определение различных подходов коммуникации в микросервисах
• Бессвязный
• Point-to-Point
• API Gateway
• Message Broker
• Shared Database
• Глава 2. Практическая часть
• Основные требования к приложению
• Инструменты
• Аналоги
• Архитектура приложения
• Модель
• Очереди сообщений
• Back-end
• Artist Service
• Album Service
• Song Service
• User Service
• History Service
• Like Service
• Comment Service
• Image Service
• Music Service
• Session Service
• Search Service
• Prediction Service
• Log Service
• Gateway Service
• Config Service
• Front-end
• Функционал, который был реализован
• Руководство пользователя
• Заключение
• Список использованной литературы
• Приложение


Введение

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

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

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

Актуальность темы

Актуальность выбранной темы, посвященной архитектуре микросервисов, объясняется необходимостью создания больших веб-приложений, способных справляться с увеличенной нагрузкой, обладать способностью быстро и безошибочно масштабироваться. Столкнувшись с подобной необходимостью, многие компании постепенно начинают переносить свои проекты на микросервисную архитектуру, способную хотя бы отчасти удовлетворить вышеуказанным требованиям.

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

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

Проблематика

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

Цели и задачи работы

Целями данной работы являются:

1. Изучение общей концепции микросервисной архитектуры;

2. Систематизация полученных данных;

3. Установление отличий микросервисной архитектуры от монолитной;

4. Определение основных компонентов микросервисной архитектуры;

5. Определение второстепенных компонентов микросервисной архитектуры;

6. Определение подходов коммуникации микросервисов друг с другом;

7. Проектирование музыкального стримингого приложения на основе микросервисов как пример практической реализации основной концепции микросервисной архитектуры и ее функционала. Формулирование требований;

8. Создание архитектуры музыкального стримингового приложения на основе микросервисного подхода;

9. Реализация back-end части музыкального стримингового приложения при помощи технологий: Spring Framework, RabbitMQ, MongoDB, Redis;

10. Реализация front-end части музыкального стримингового приложения при помощи технологий: HTML5, Angular, CSS3, Node.js.

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

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

1. Формулирование требований к системе;

2. Создание архитектуры, основанной на микросервисах;

3. Разработка back-end части;

4. Разработка front-end части.



Глава 1. Теоретическая часть

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

Определение сущности микросервисов

В настоящее время существует несколько определений микросервисов, которые по своей сути сходятся в том, что микросервисы представляют собой архитектурный стиль построения приложений на основе набора независимо разрабатываемых и слабо связанных между собой сервисов, каждый из которых отвечает за конкретную задачу функционала. При этом коммуникация между сервисами осуществляется посредством простого и доступного программного интерфейса (API). Подобную точку зрения при определении микросервисов разделяют Мартин Фаулер и Джеймз Льюис, британские авторы книг и статей, а также публичных докладов по архитектуре программного обеспечения, в своей статье «Микросервисы: определение нового термина в области архитектуры», рассматривая микросервисную архитектуру как подход к разработке отдельного приложения, основанный на наборе небольших сервисов, каждый из которых работает в рамках собственного процесса, и взаимодействующих посредством легковесных механизмов, как правило, протокола HTTP. При этом авторы статьи подчеркивают, что указанные сервисы построены вокруг бизнес-потребностей и развертываются на независимой основе с использованием полностью автоматизированной среды [2].

Микросервисы являются разновидностью сервисно-ориентированной архитектуры (service-oriented architecture, SOA), которая в свою очередь представляет собой модульный подход к разработке программного обеспечения, при котором распределенные, слабо связанные компоненты приложения предоставляют услуги другим компонентам через коммуникационный протокол, обычно по сети. Принципы работы сервисно-ориентированной архитектуры заключаются в их независимости от продукта, поставщика или применяемой технологии. Микросервисы являются продолжением данной концепции с тем дополнением, что компоненты микросервисов представлены в виде максимально мелких, независимых частей.

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

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

Микросервисы также предоставляют гибкость и в использовании технологий ввиду своей независимости друг от друга. Так, например, можно использовать разные фреймворки или языки программирования при создании одного и того же приложения. Микросервисы представляют собой гибкую методологию обновления приложений: при добавлении нового функционала или обновлении старого обновлению подлежат лишь определенные сервисы. Каждый сервис есть маленькое приложение, но в совокупности все сервисы, из которых состоит приложение, составляют большую и сложную систему.

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

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

Установление отличий микросервисной архитектуры от монолитной

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

При сравнении двух подходов стоит в первую очередь отметить, что микросервисы создавались как одна из альтернатив монолитной архитектуры в рамках SOA, в которой размер кодовой базы как один из основных элементов был изменен: в монолитной архитектуре кодовая база собрана в одном месте, в то время как в микросервисах она распределена по разным репозиториям при соблюдении соответствия каждого сервиса своему репозиторию, что способствует облегчению понимания кода. Время сборки монолитного приложения прямо зависит от его размера: чем больше размер приложения, тем больше потребуется времени для его сборки. При применении микросервисного подхода каждый сервис собирается отдельно, что частично усложняет задачу по причине необходимости выполнения большого количества сборок, но в то же время в микросервисной архитектуре уменьшение размера каждого отдельного сервиса влияет на время, потраченное на сборку как отдельного модуля, так и всего приложения в целом. При создании монолитного приложения разработчикам необходимо точно определиться с технологическим стеком. Так, в случае разработки веб-приложения предстоит выбрать по одному фреймворку и языку программирования для back-end и front-end частей. При применении микросервисного подхода каждый сервис может быть написан на любом программном языке, а для его создания может быть использован любой фреймворк. В процессе развертывания приложения, основанного на монолитной архитектуре, небольшие изменения одной из частей влекут за собой повторное развертывание всего приложения в целом, в то время как приложение, построенное на микросервисах, требует повторного развертывания лишь того сервиса, который претерпел изменения. Приложение, созданное на основе монолитной архитектуры, имеет низкий уровень отказоустойчивости всей системы и практически не способно минимизировать ущерб от сбоя в работе какой-то отдельной части системы, в то время как приложение, созданное на основе микросервисов, благодаря разделенной на различные сервисы структуре способно сводить ущерб от сбоя в работе одного или нескольких сервисов до минимума за счет подобного разделения и независимости функционала.

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

Основные компоненты микросервисной архитектуры

Паттерн микросервисной архитектуры несет в себе набор более мелких паттернов, часть из которых является важной и неотъемлемой частью самой архитектуры. Эти паттерны включают в себя:

1. Config Service

2. Discovery Service

3. Gateway Service

4. Log Service

5. Circuited Breaker

6. Health Check API

Config Service

Config Service представляет собой отдельный сервис конфигурации, в котором хранятся конфигурационные файлы всех микросервисов. Целью подобного перемещения конфигурации является упрощение работы с сервисами, поскольку наличие конфигурации в одном месте обеспечивает их быструю настройку и переносимость. Нагрузка на сам сервис варьируется в зависимости от приложения, но в целом можно сказать, что нагрузка возникает только при старте всей системы и масштабировании отдельных сервисов. Данный паттерн также предоставляет возможность запуска системы в различных средах без потребности в её изменении или повторной компиляции. В случае отказа данного сервиса остальные сервисы должны иметь запасной вариант конфигурации.

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

Discovery Service

Discovery Service представляет собой паттерн, функционал которого дает возможность сервисам “видеть” друг друга посредством сбора информации о всех сервисах и предоставления ее по запросу. Такая информация должна содержать имя сервиса и его адрес.

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

1. Client-side service discovery, который объединяется с клиентом или имплементируется отдельно на стороне клиента;

2. Server-side service discovery, который имплементируется на стороне сервера.

Gateway Service

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

Log Service

Паттерн Log Service подразумевает имплементацию сервиса, который занимается сбором и аккумулированием логов от всех микросервисов следующим образом: микросервисы сами высылают свои логи (logs) паттерну или собирают свои логи и по запросу, полученному от данного сервиса, отправляют их последнему. Хранение логов осуществляется с использованием специальной базы данных временных рядов, которая хранит логи во временном порядке.

Circuited Breaker

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

Health Check API

Предназначением паттерна Health Check API является мониторинг жизненной активности сервисов. Данный паттерн подразумевает имплементацию в каждом сервисе в виде конечной точки API (например, /health). Под жизненной активностью понимается активность и исправность самого сервиса, зависимостей и базы данных. Имплементация данного паттерна может быть использована такими сервисами как Discovery service, в частности, для целей мониторинга, сервисом Gateway Service, который может использовать Health Check API для проверки доступности сервиса и настройки логики дальнейших действий в случае обнаружения неисправностей, сервисом Circuited Breaker, который может использовать указанный паттерн для определения необходимости запуска имитации данного сервиса.

Определение различных подходов коммуникации в микросервисах

Микросервисное приложение -- это набор отдельных, слабо связанных между собой сервисов, которые взаимодействуют друг с другом посредством простого, строго определенного интерфейса. Такое взаимодействие может осуществляться несколькими способами:

1. Бессвязный;

2. Point-to-Point;

3. API Gateway;

4. Message Broker;

5. Shared Database.

Бессвязный

Данный подход подразумевает отсутствие связи между микросервисами. Каждый микросервис взаимодействует через Gateway Service с клиентом и не требует дополнительной логики, для которой необходимо взаимодействие с другими сервисами. При таком подходе части модели конкретного приложения, распределенного по сервисам, обладают наибольшей атомарностью по указанной выше причине.

Point-to-Point

Point-to-Point представляет собой способ связи микросервисов, базирующийся на использовании REST API. При таком способе сервисы “ходят” друг к другу при помощи обычных HTTP запросов, для чего создается специальный рабочий функционал. Сервисы могут либо напрямую направлять запросы друг другу, имея данные об адресах, либо через адрес, полученный от Discovery Client. К достоинствам данного подхода можно отнести простоту имплементации, к недостаткам- ограничения, связанные с HTTP протоколом, в частности, ограниченный набор запросов и необходимость установки заголовков безопасности для предотвращения проникновения сторонних сервисов. Относится к антипаттернам.

API Gateway

Данный подход повторяет идею Point-to-Point, но если при применении последнего взаимодействие между сервисами осуществляется не напрямую, то при его имплементации API Gateway служит единой начальной точкой маршрутизации, через которую все сервисы шлют свои запросы. К достоинствам указанного подхода можно отнести отсутствие необходимости знать адрес другого сервиса, централизация коммуникации. Недостатком является, как и в случае с Point-to-Point, использование HTTP протокола и уменьшение производительности за счет наличия proxy в лице Gateway Service.

Message Broker

Message Broker подразумевает использование специальных программных модулей или программ, созданных для передачи сообщений между сервисами с использованием специальных протоколов, например, таких как Advanced Message Querying Protocol, в результате чего подключение сервисов к Message Broker осуществляется напрямую или через Discovery Service. При этом коммуникация между микросервисами осуществляется через отправку сообщения в специальном формате (например, в формате строки или JSON), а получение сообщений - в зависимости от определенного типа сообщений, на прием которых настроен тот или иной сервис. К плюсам данного подхода можно отнести высокую степень отказоустойчивости, возможность передавать сообщения, не зная точного адреса получателя. Буферизация сообщений Message Broker позволяет сохранять сообщения в случае отказа одного из сервисов, к недостаткам - сложность имплементации и вытекающее из этого использование уже готовых программ, поддержка их функционала.

Shared Database

Shared Database - способ коммуникации, позволяющий использовать базы данных или хранилища «ключ-значение» между несколькими микросервисами. Крис Ричардсон, известный американский архитектор программного обеспечения и автор книги «Шаблоны микросервисов», в своей статье «Pattern: shared database» относит к преимуществам данного способа коммуникации следующие:

· возможность использования разработчиком знакомых и прямолинейных ACID свойств транзакций для усиления функции согласованности данных;

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

К недостаткам:

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

· согласование времени рабочего цикла по причине того, что при обращении к одной и той же базе данных все сервисы могут мешать друг другу;

· одна и та же база данных не может удовлетворять требованиям к хранению данных и доступу, предъявляемым всеми сервисами [5].



Глава 2. Практическая часть

Практическая часть данной работы заключается в создании веб-приложения, имплементирующего микросервисный подход к построению приложений. Таким приложением является музыкальное стриминговое приложение, построенное на основе использования всех основных паттернов микросервисной архитектуры, а также способов коммуникации между сервисами Message Broker и Gateway API.

Основные требования к приложению

1. Пользовательские требования:

a. Приложение должно содержать несколько страниц, из которых доступной для незарегистрированных пользователей является только страница приветствия.

b. Страница приветствия содержит ссылку на переход на страницу входа (регистрации).

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

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

e. Главная страница, на которой должны быть реализованы следующие функции:

· поиск композиций;

· открытие меню;

· открытие меню пользователя;

· просмотр наиболее популярных исполнителей и альбомов, отобранных по времени загрузки и популярности (в зависимости от количества набранных лайков);

· переход на страницы альбомов или исполнителей, внесенных в списки наиболее популярных;

· создание плейлиста объемом 10 композиций на основе пользовательских предпочтений, сформированных по жанрам музыки (создается в самом плеере).

f. Страница наиболее популярных исполнителей и альбомов должна содержать списки двух видов, отсортированных по времени и по количеству набранных лайков. Такие списки должны быть частично скрыты и содержать не более 5 элементов. При раскрытии указанных списков количество элементов, содержащихся в каждом таком списке, может быть увеличено до 10.

g. Страница регистрации (входа на сайт).

h. Меню пользователя содержит ряд кнопок, таких как кнопка вызова всплывающего окна (pop-up), в котором можно редактировать имя пользователя; кнопка перехода на страницу истории данного пользователя, состоящую из прослушанных альбомов, истории лайков и комментариев; кнопка перехода на страницу управления, которая позволяет создавать и редактировать альбомы; кнопка выхода из аккаунта.

i. Страница управления созданным пользователем списком исполнителей, с которой осуществляется просмотр страниц выбранных исполнителей. Данная страница содержит кнопки удаления (возможен множественный выбор) и создания новых страниц исполнителей. Для редактирования конкретного исполнителя необходимо щелкнуть кнопкой мыши по имени данного исполнителя в списке.

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

j. Страница управления альбомами исполнителя включает в себя список альбомов последнего, а также содержит функционал создания, редактирования и удаления альбомов. При нажатии на кнопку создания исполнителя появляется всплывающее окно, которое служит для создания и редактирования альбомов.

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

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

m. Страница результатов поиска включает в себя результаты, представленные в виде двух списков: список исполнителей и список альбомов.

2. Технические требования:

a. Приложение должно представлять собой веб-сервис с front-end (web) и back-end;

b. Back-end должен быть написан на языке Java (версия SE 11) при помощи универсального фреймворка Spring Framework и программного брокера сообщений RabbitMQ. В качестве JVM должна выступать Open9J, а в качестве средства сборки - Apache Maven.

c. Приложение должно работать под Windows 10 (x64).

d. Данные должны храниться в базах данных (технология MongoDB) и в хранилищах «ключ-значение» (технология Redis).

e. Запуск должен осуществляется либо через Maven, либо посредством технологии Docker.

f. Для front-end части должны быть использованы язык верстки HTML5, язык каскадных стилей CSS3, TypeScript и фреймворк Angular.

g. Front-end запускается на программной платформе Node.js.

Инструменты

1. Java 11 (версия 11.0.1);

2. Open9J;

3. Maven (версия 3.5.3);

4. TypeScript (версия 3.4);

5. Spring Framework (версия 5.1.6. RELEASE);

6. Spring WebFlux

7. RabbitMQ (версия 3.7.13);

8. Zookeeper (версия 3.4.13);

9. Spring Cloud Gateway (версия 1.3.1);

10. Node.js (версия 10.15.3 LTS);

11. Angular (версия 7.2.12);

12. HTML5;

13. CSS3;

14. MondoDB (версия 4.0.8);

15. Redis (версия 5.0.4).

Spring Framework - фреймворк, используемый для создания приложений на нескольких языках программирования, в том числе языке Java. Данный фреймворк включает в себя такие подфрейморки как Spring Cloud, Spring Data, Spring WebFlux и Spring Security, которые также использованы для написания приложения.

Angular - фреймворк, используемый при создании SPA приложений с помощью языка TypeScript.

Zookeeper - Discovery Service.

Spring Cloud Gateway - фреймворк для создания Gateway Service.

RabbitMQ - message broker, предоставляющий возможность отправки сообщений в виде очередей. Является одним из способов взаимодействия между микросервисами.

Node.js - технология для запуска JS кода вне браузера.

MongoDB - основная база данных проекта, используемая для хранения неструктурированных данных.

Redis - размещаемое в памяти хранилище «ключ-значение», используемое для промежуточных буферов (cache) и просто временных данных.

Аналоги

К числу аналогов создаваемого приложения можно отнести веб-сервисы, основанные на микросервисной архитектуре, такие как Amazon, популярный онлайн-ритейлер, и Netflix, онлайн-площадка для просмотра медиа-контента. По своему тематическому содержанию разработанное приложение сходно с YouTubeMusic и Spotify, музыкальными стриминговыми сервисами, основанными на микросервисах.

В Netflix количество микросервисов превышает 16000. При разработке данного сервиса (Netflix) было создано множество фреймворков и утилит, которые были выведены в Open Source и использованы при создании приложения, упомянутого в настоящей работе, в том числе фреймворки и утилиты, на основе которых был разработан Spring Cloud Gateway.

Архитектура приложения

Архитектура приложения включает в себя набор микросервисов, взаимодействующих друг с другом через фреймворк Spring Cloud Gateway (Gateway Service), RabbitMQ (Message Broker), веб-интерфейс, написанный на языке TypeScript, являющийся основным языком для фреймворка Angular. Каждый сервис обладает своей базой данных (MongoDB), в которой хранится та часть модели, с которой работает сам сервис. Все сервисы подключаются к Zookeeper (Discovery Service).

Данное приложение включает в себя:

1. Back-end

a. Artist Service;

b. Album Service;

c. Song Service;

d. User Service;

e. History Service;

f. Like Service;

g. Comment Service;

h. Image Service;

i. Music Service;

j. Session Service;

k. Search Service;

l. Prediction Service;

m. Log Service;

n. Gateway Service;

o. Config Service;

2. Front-end

Модель

Модель представлена несколькими сущностями:

1. Album - сущность альбома. Привязана к определенному музыканту и включает в себя следующие элементы:

a) Id - идентификатор альбомов. Служит для обозначения конкретного альбома. Является уникальным элементом, генерируется на сервере. Тип представлен в виде UUID.

b) Name - имя альбома, не является уникальным элементом. Тип данных - строка, ограничение 256 символов.

c) ArtistId - идентификатор исполнителя, которому этот альбом принадлежит. Не является уникальным элементом. Тип данных- UUID.

d) Date - дата создания альбома. При создании сущности по умолчанию проставляется текущая дата.

e) Genre - список жанров, к которым относится данный альбом. Не является обязательным полем. Тип данных -список строк.

2. Artist - сущность исполнителя. Привязана к конкретному пользователю. Состоит из следующих элементов:

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

b) Name - имя исполнителя. Не является уникальным, но в то же время обязательным для заполнения полем. Тип данных- строка. Ограничение по символам - 256.

c) URL - уникальный путь пользователя. Используется на клиентской стороне (front-end) для упрощения перехода к выбранному исполнителю. Тип данных -строка, ограничение по символам - 256.

d) Date - дата создания исполнителя. По умолчанию устанавливается текущая дата.

e) UserId - идентификатор пользователя, создавшего данную сущность. Не является уникальным элементом. Тип данных- UUID.

f) Location - название локации. Тип данных - строка. Ограничение по символам - 256.

g) Links - список сторонних ссылок на исполнителя. Указанный элемент не является обязательным или уникальным. Тип данных - Map.

3. Comment - сущность комментария. Включает в себя следующие элементы:

a) Id - уникальный идентификатор комментария. Тип данных UUID.

b) AlbumId - идентификатор альбома, под которым был оставлен комментарий. Тип данных UUID.

c) UserId - идентификатор пользователя, который оставил комментарий. Тип данных UUID.

d) Message - текст комментария. Тип данных - строка, ограничение по количеству символов 300.

4. HistoryElement - сущность, относящаяся к истории. Содержит ссылки

на пользователя и на прослушанный им альбом. Включает в себя следующие элементы:

a) Id - уникальный идентификатор истории. Тип данных UUID.

b) AlbumId - идентификатор альбома, прослушанный пользователем. Тип данных UUID.

c) UserId - идентификатор пользователя, который прослушал альбом. Тип данных UUID.

5. Like - сущность, относящаяся к лайку. Является набором из двух ссылок: ссылки на альбом, которому поставили лайк, и ссылки на пользователя, который поставил лайк. Включает в себя следующие элементы:

a) Id - уникальный идентификатор лайка. Тип данных- UUID.

b) AlbumId - идентификатор альбома, которому поставили лайк. Тип данных UUID.

c) UserId - идентификатор пользователя, который поставил лайк. Тип данных UUID.

6. Prediction - сущность, служащая для генерации плейлиста для пользователя на основе жанровых предпочтений последнего. Включает в себя:

a) Id - идентификатор для обозначения данной сущности. Присваивается каждой конкретной композиции. Являясь уникальным элементом, генерируется на сервере. Тип представлен в виде UUID.

b) UserId - идентификатор пользователя, для которого создается плейлист. Не является уникальным элементом. Тип данных - UUID.

c) Genre - название жанра, который будет использоваться для генерации плейлиста. Тип данных- строка.

d) numberOfListenings - количество прослушанных альбомов, относящихся к определенному жанру (поле genre). Тип данных - long.

7. Song - сущность музыкальной композиции. Привязана к альбому и включает в себя следующие элементы:

a) Id - идентификатор для обозначения музыкальных композиций. Присваивается каждой конкретной композиции. Являясь уникальным элементом, генерируется на сервере. Тип представлен в виде UUID.

b) Name - название композиции. Не является уникальным элементом. Тип данных - строка, ограничение по количеству символов 256.

c) AlbumId - идентификатор альбома, которому данная композиция принадлежит. Не является уникальным элементом. Тип данных -UUID.

8. User - сущность пользователя. Включает в себя следующие элементы:

a) Id - идентификатор пользователя. Является уникальным элементом. Тип данных- UUID.

b) Name - имя пользователя. Является уникальным элементом. Тип данных -строка, ограничение 256 символов.

c) LastActivity - дата последней активности пользователя.

Очереди сообщений

Для коммуникации между микросервисами посредством RabbitMQ (Message Broker) создаются следующие очереди сообщений:

1. user-delete-query - очередь сообщений, которые генерирует User Service при удалении пользователей. Служит для каскадного удаления сущностей, привязанных к данному пользователю. В разработанном приложении удаляет всех исполнителей, которые были созданы удаляемым пользователем.

2. artist-delete-query - очередь сообщений, которые генерирует Artist Service. Служит для каскадного удаления сущностей, привязанных к данному пользователю. В разработанном приложении удаляет все альбомы, которые были привязаны к данному исполнителю.

3. album-delete-query - очередь сообщений, которые генерирует Album Service. Служит для каскадного удаления сущностей, привязанных к данному альбому. В разработанном приложении удаляет все музыкальные композиции, которые привязаны к данному альбому.

4. history-add-query - очередь сообщений, которые генерирует History Service. Служит для информирования Prediction Service о новом прослушанном альбоме.

Back-end

Artist Service

Artist Service - сервис, созданный на Spring Framework. Ориентирован на работу с сущностями исполнителей.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/artist - создание сущности исполнителя;

2. PUT api/artist - редактирование сущности исполнителя;

3. DELETE api/artist - удаление исполнителя;

4. GET api/artist/{id} - получение исполнителя по его уникальному идентификатору id;

5. GET api/artist/name/{name} - получение исполнителей по их именам;

6. GET api/artist/url/{url} - получение исполнителя по его уникальному пути.

Внутренний API включает в себя следующие HTTP запросы:

1. GET api/internal/artist/{id} - проверка существования данного исполнителя по его идентификатору id;

В случае удаления сущности исполнителя в RabbitMQ направляется сообщение, состоящее из id удаленного исполнителя. Используется очередь RabbitMQ artist-delete-queue.

Данный сервис является слушателем следующих очередей из RabbitMQ:

1. user-delete-query.

Album Service

Album Service - сервис, созданный на Spring Framework и ориентированный на работу с сущностями альбомов.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/album - создание сущности альбома;

2. PUT api/album - редактирование сущности альбома;

3. DELETE api/album - удаление альбома;

4. GET api/album/{id} - получение альбома по его уникальному идентификатору id;

5. GET api/album/name/{name} - получение альбомов по их именам;

6. GET api/album/artist/{id} - получение альбомов по id исполнителя, к которому данные альбомы относятся.

Внутренний API включает в себя следующие HTTP запросы:

1. GET api/internal/album/{id}- проверка существования данного альбома по его идентификатору id;

2. GET api/internal/album/ids- получение альбомов по их id;

3. GET api/internal/album/genre- получение альбомов по их жанру, выступающего в качестве параметра поиска.

В случае удаления сущности альбома в RabbitMQ направляется сообщение, состоящее из id удаленного альбома. Используется очередь RabbitMQ album-delete-queue.

Данный сервис является слушателем следующих очередей из RabbitMQ:

1. artist-delete-query.

Song Service

Song Service - сервис, созданный на Spring Framework и ориентированный на работу с сущностями музыкальных композиций.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/song - создание сущности музыкальной композиции;

2. PUT api/song - редактирование сущности музыкальной композиции;

3. DELETE api/song - удаление музыкальной композиции;

4. GET api/song/{id} - получение музыкальной композиции по ее уникальному идентификатору id;

5. GET api/song/name/{name} - получение музыкальных композиций по их именам;

6. GET api/song/album/{id} - получение музыкальных композиций по id альбома.

Внутренний API включает в себя следующие HTTP запросы:

1. GET api/internal/song/{id} - проверка существования данной композиции по ее идентификатору id.

В случае удаления сущности композиции в RabbitMQ направляется сообщение, состоящее из id удаленного композиции. Используется очередь RabbitMQ song-delete-queue.

Данный сервис является слушателем следующих очередей из RabbitMQ:

1. album-delete-query.

User Service

User Service - сервис созданный на Spring Framework и ориентированный на работу с сущностями пользователей.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. PUT api/user - редактирование пользователя;

2. DELETE api/user - удаление пользователя;

3. GET api/user/{id} - получение пользователя по его уникальному идентификатору id;

4. GET api/user/name/{name} - получение пользователя по его имени.

Внутренний API включает в себя следующие HTTP запросы:

1. GET api/internal/user/{id}- проверка существования данного пользователя по его id;

2. POST api/internal/user - создание пользователя.

В случае удаления сущности пользователя в RabbitMQ направляется сообщение, состоящее из id удаленного пользователя. Используется очередь RabbitMQ user-delete-queue.

History Service

History Service - сервис, ориентированный на работу с историей прослушивания пользователей. В истории записывается только прослушанные альбомы.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/history - добавление элемента истории;

2. GET api/history/user/{id} - получение истории по уникальному идентификатору пользователя;

3. GET api/user/album/{id} - получение количества прослушиваний данного альбома пользователями;

Данный сервис является слушателем следующих очередей из RabbitMQ:

1. album-delete-query;

2. user-delete-query.

Like Service

Like Service - сервис, целью которого является работа с сущностями лайков. Данный сервис должен отслеживать установку лайка и сохранять его в виде сущности Like.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/like - добавление лайка;

2. DELETE api/like - удаление лайка;

3. GET api/like/album/{id} - получение лайков, поставленных пользователем альбому с данным идентификатором id;

4. GET api/like/user/{id} - получение лайков, поставленных пользователем с данным id;

5. GET api/like/top - получение топов.

Данный сервис является слушателем следующих очередей из RabbitMQ:

1. album-delete-query;

2. user-delete-query.

Comment Service

Comment Service - сервис, ориентированный на работу с комментариями, оставляемыми пользователями под альбомами.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/comment - добавление комментария;

2. DELETE api/comment - удаление комментария;

3. GET api/comment/album/{id} - получение комментариев к альбому с данным id;

4. GET api/comment/user/{id} - получение комментариев данного пользователя.

Данный сервис является слушателем следующих очередей из RabbitMQ:

1. album-delete-query;

2. user-delete-query.

Image Service

Image Service - сервис, отвечающий за работу с изображениями (формат изображения PNG, размер не более 100Mb). Изображения хранятся в файловой системе в виде директорий Artist и Album. Имена изображениям задаются в зависимости от id их сущностей.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/image/artist/{id} - добавление или изменение изображения исполнителя по его идентификатору id;

2. POST api/image/album/{id} - добавление или изменение изображения альбома по его идентификатору id;

3. GET api/image/album/{id} - получение изображения альбома по данному id;

4. GET api/image/artist/{id} - получение изображения исполнителя по данному id.

Music Service

Music Service - сервис, главная задача которого заключается в предоставлении API для загрузки музыкальных композиций (формат mp3, размер не более 200 Mb). Сервис также предоставляет возможность стриминга.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/music/{id} - загрузка музыки по id;

2. GET api/music/{id} - получения файла композиции по id.

Session Service

Session Service - сервис, отвечающий за безопасность и авторизацию пользователей. На данный сервис приходит поступающий через Gateway Service запрос от клиента при входе или регистрации в приложение. Сервис Session Service посылает запрос в User Service с целью проверки существования пользователя, и, если пользователя не существует, то такой создается. На следующем этапе создается сессия для данного пользователя.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. POST api/session/login - вход пользователя;

2. POST api/session/register - выход пользователя.

Search Service

Search Service - сервис, отвечающий за функцию поиска. Сам процесс поиска заключается в посылке запросов к другим сервисам и аккумулировании поступающих ответов, которые отправляются клиенту. Все кэшированные запросы хранятся в Redis не более одной минуты.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. GET api/search/artist/{searchLine} - поиск исполнителей по запросу;

2. GET api/search/album/{searchLine} - поиск альбомов по запросу.

Prediction Service

Prediction Service - микросервис, отвечающий за генерацию плейлистов, формируемых на основе предпочтений пользователей. При составлении плейлиста используются альбомы, хранящиеся в истории, а в случае, если в истории отсутствуют какие-либо альбомы, то пользователю предлагаются случайные варианты.

Внешний API сервиса включает в себя следующие HTTP запросы:

1. GET api/generate/{userId} - генерирует плейлист для пользователя с данным id.

Log Service

Log Service - сервис, отвечающий за сбор логов со всех сервисов. В качестве фреймворка используется Spring Cloud Sleuth.

Gateway Service

Gateway Service - прокси-сервис, отвечающий за внешнее взаимодействие. В основе сервиса лежит фреймворк Spring Cloud Gateway.

Config Service

Config Service - сервис, который содержит всю конфигурацию и является имплементацией Config Service паттерна.

Конфигурация хранится в файлах формата yml.

Front-end

Front-end часть проекта представляет собой SPA приложение, написанное на языке TypeScript при помощи фреймворка Angular. Приложение состоит из следующих модулей:

1. App Module;

2. Sharing Module;

3. Playlist Module;

4. Artist Module;

5. Album Module;

6. Tops Module;

7. Search Module;

8. Player Module;

9. Song Module;

10. Generating Module;

11. Comments Module;

12. History Module;

13. User Module;

14. Like Module;

15. Management Module;

16. Help Module;

17. Service Module;

Каждому модулю соответствует определённая задача. В частности, этой задачей может быть взаимодействие с определённым микросервисом (например, Artist Module взаимодействует с Artist Service через Gateway Service).

Визуальная часть front-end выполнена при использовании языков HTML5 и CSS3.

Функционал, который был реализован

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

Руководство пользователя

Настоящее приложение представляет собой сервис с веб-интерфейсом. При запуске приложения появляется страница приветствия, которая включает в себя наименование, приветствие и кнопку входа в систему (см. рисунок 1).

При нажатии на кнопку входа в систему осуществляется переход на страницу входа и регистрации. Данная страница содержит два поля ввода данных: имени и пароля.



Рисунок 1 - Страница приветствия

Процессы регистрации и входа не отличаются друг от друга: в случае если пользователь не зарегистрирован на данном ресурсе, то ему для регистрации достаточно ввести свои имя и пароль в вышеуказанные поля. Аналогичным образом происходит процесс входа в систему, который сводится к вводу пользователем своих данных (см. рисунок 2).

Рисунок 2 - Вид страницы входа и регистрации

При входе в систему становится доступной главная страница (см. рисунок 3).

Рисунок 3 - Вид главной страницы

Поиск композиции, альбома или исполнителя осуществляется через запрос, отправляемый при заполнении поля “Search”. Новый плейлист может быть сгенерирован при использовании функции “Get New”. В нижней части страницы представлены наиболее популярные исполнители и альбомы, количество которых не превышает пяти, отсортированные по количеству лайков. При выборе одного из них открывается страница исполнителя или альбома соответственно. Выбрав кликом мыши имя исполнителя, находящееся под альбомом, пользователь переходит на страницу данного исполнителя. При нажатии на кнопки “more…” напротив наиболее популярных исполнителей и альбомов осуществляется переход на страницы указанных категорий.

На каждой странице, кроме страницы приветствия, доступны такие компоненты как поисковая строка, меню и кнопка всплывающего меню. При активации кнопки меню с левой стороны страницы открывается само меню (см. рисунок 4).



Рисунок 4 - Меню

При нажатии на кнопку “Home” осуществляется переход на главную страницу, а при нажатии на кнопку “Tops” - переход на страницы наиболее популярных исполнителей и альбомов в зависимости от времени их загрузки или количества лайков. Кнопка “History” служит для открытия страницы истории данного пользователя. При нажатии на кнопку “Edit Name” открывается pop-up для редактирования имени пользователя. При нажатии на кнопку “Music Lab” осуществляется переход на страницы редактирования исполнителей, созданных данным пользователем.

Рисунок 5 - Страница исполнителя

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

...