RoleAssignmentsSystem

Стек технологий

1. Язык программирования: Java 17
2. Фреймворк: Spring Boot
   • Spring Data JPA: для работы с базой данных.
   • Spring Security: для аутентификации и защиты API.
   • Spring Kafka: для обмена сообщениями через Kafka.
3. Система управления зависимостями и сборки: Gradle
4. База данных: PostgreSQL
5. Документация API: Swagger
6. Логирование: SLF4J с Logback
7. Контейнеризация: Docker
8. Микросервисная архитектура: независимые сервисы для пользователей и ролей

---

Инструкция по запуску

1. Установка зависимостей:

• Убедитесь, что установлены Java 17 и Gradle.
• Установите PostgreSQL и Kafka (если используется локально).

2. Конфигурация базы данных:

• Откройте файл application.properties каждого микросервиса (например, usermanager, rolemanager).
• Настройте параметры базы данных:

  spring.datasource.url=jdbc:postgresql://localhost:5432/your_database
  spring.datasource.username=your_username
  spring.datasource.password=your_password

3. Запуск Kafka:

• Запустите Kafka на локальном сервере или настройте соединение через application.properties.

4. Запуск приложения:

• Выполните команду для каждого микросервиса:

  ./gradlew bootRun

5. Документация API:

• После запуска приложения перейдите по адресам:
  • Координатор: http://localhost:7070/swagger-ui.html
  • Менеджер пользователей: http://localhost:8080/swagger-ui.html
  • Менеджер ролей: http://localhost:9090/swagger-ui.html

6. Тестирование:

• Запуск тестов с помощью Gradle:

  ./gradlew test

---

Авторизация и уровни доступа

Пользователь по умолчанию

По умолчанию, в системе для всех модулей создан пользователь с правами администратора:

• Логин: admin
• Пароль: admin
• Данный пользователь имеет доступ ко всем эндпоинтам системы и полные права.

Система поддерживает различные уровни доступа в зависимости от роли пользователя.

1. Менеджер пользователей (usermanager)

• В модуле usermanager реализованы различные уровни доступа в зависимости от роли пользователя:
  • Администратор: имеет полный доступ ко всем эндпоинтам.
  • Обычный пользователь: доступ ограничен в соответствии с его правами.

2. Менеджер ролей (rolemanager)

• По умолчанию в модуле rolemanager существуют два типа пользователей:
  • Администратор: имеет полный доступ ко всем эндпоинтам.
  • Модератор: имеет доступ только к GET-запросам.

3. Координатор (coordinator)

• Модуль coordinator имеет аналогичные настройки, как и rolemanager:
  • Администратор: имеет полный доступ ко всем эндпоинтам.
  • Модератор: имеет доступ только к GET-запросам.

---

Описание микросервисов

1. Менеджер пользователей (usermanager)

• Модель данных:
  User с полями id, username, email, password, createdAt, updatedAt, и accessLevel.
• Пароль: шифруется с помощью Spring Security.
• REST API:
  • GET /api/users — получить всех пользователей.
  • GET /api/users/{id} — получить пользователя по ID.
  • POST /api/users — создать пользователя.
  • PUT /api/users/{id} — обновить пользователя.
  • DELETE /api/users/{id} — удалить пользователя.
• Валидация:
  • Проверка на уникальность имени пользователя и email.
  • Валидация email и пароля.

2. Менеджер ролей (rolemanager)

• Модель данных:
  Role с полями id, name, description.
• REST API:
  • GET /api/roles — получить все роли.
  • GET /api/roles/{id} — получить роль по ID.
  • POST /api/roles — создать роль.
  • PUT /api/roles/{id} — обновить роль.
  • DELETE /api/roles/{id} — удалить роль.
• Валидация:
  • Название роли проверяется на уникальность.

3. Координатор (coordinator)

• Модель данных:
  UserRole содержит идентификаторы пользователя и роли.
• REST API:
  • GET /api/users/{userId}/roles — получить роли пользователя.
  • POST /api/users/{userId}/roles/{roleId} — назначить роль пользователю.
  • DELETE /api/users/{userId}/roles/{roleId} — удалить роль у пользователя.

---

Архитектура

Микросервисная архитектура:

• Приложение разделено на 3 микросервиса:
  • Менеджер пользователей (usermanager)
  • Менеджер ролей (rolemanager)
  • Координатор (coordinator) для взаимодействия между сервисами
• Отдельные базы данных: для каждого микросервиса используется своя база данных с собственной схемой.

Слои приложения:

• Контроллеры: обработка запросов API.
• Сервисный слой: бизнес-логика.
• Репозитории: взаимодействие с базой данных.

---

Тестирование

• Unit-тесты: покрывают сервисный слой для проверки бизнес-логики.
• Интеграционные тесты: проверяют работу REST API.
• Postman Collection: Successful_Post_Tests
  • Эта коллекция состоит из успешных POST-запросов к каждому сервису, предназначена для демонстрации работоспособности приложения. Она позволяет быстро убедиться в корректном функционировании сервисов и их взаимодействии.

---

Паттерны проектирования

• Микросервисная архитектура: REST Layered System.
• Репозиторий (Repository): изоляция работы с базой данных.
• DTO (Data Transfer Object): для сокращения объема передаваемых данных.
• Mapper: централизованная логика преобразования данных.
• Adapter для Kafka: унифицированный интерфейс для взаимодействия с Kafka.

---

Оправданность выбранных решений

Почему микросервисная архитектура?

• Модульность и гибкость: микросервисы можно разрабатывать и развёртывать независимо.
• Устойчивость: сбой одного микросервиса не влияет на работу других.
• Масштабируемость: отдельные компоненты можно масштабировать независимо.

Почему Kafka?

• Асинхронное взаимодействие: разгрузка HTTP-запросов.
• Отказоустойчивость: сообщения сохраняются и могут быть обработаны позже.
• Масштабируемость: легко добавлять новые микросервисы.
• Высокая производительность: поддержка распределенной обработки сообщений.

---

Возможности масштабирования

• Горизонтальное масштабирование: запуск нескольких экземпляров микросервисов.
• Автономное масштабирование: разное количество экземпляров для разных микросервисов в зависимости от нагрузки.
• Разделение баз данных: каждая база данных разгружается за счет распределения нагрузки между сервисами.
• Kafka: позволяет разгрузить систему за счет асинхронного обмена сообщениями.