Dmitry
8d3d4cd1f7
Some checks are pending
Backend CI / test (push) Waiting to run
Backend CI / build (push) Blocked by required conditions
Mobile App CI / test (push) Waiting to run
Mobile App CI / build-android (push) Blocked by required conditions
Mobile App CI / build-ios (push) Blocked by required conditions
Web App CI / test (push) Waiting to run
Web App CI / build (push) Blocked by required conditions
Deploy Mnemo Cards / Deploy Backend (push) Waiting to run
Deploy Mnemo Cards / Deploy Web App (push) Blocked by required conditions
Deploy Mnemo Cards / Final Verification (push) Blocked by required conditions
Deploy Telegram Bot / Deploy Telegram Bot (push) Waiting to run
543 lines
No EOL
19 KiB
Markdown
543 lines
No EOL
19 KiB
Markdown
---
|
||
name: Микросервисная архитектура Mnemo Cards
|
||
overview: План разделения монолитного backend на микросервисы с учетом независимого деплоя, разных технологий и организации команды. Используется гибридный подход к базам данных.
|
||
todos:
|
||
- id: analyze_dependencies
|
||
content: Проанализировать зависимости между модулями и создать карту зависимостей
|
||
status: pending
|
||
- id: design_api_gateway
|
||
content: Спроектировать API Gateway для маршрутизации запросов к микросервисам
|
||
status: pending
|
||
- id: create_shared_jwt_lib
|
||
content: Создать shared библиотеку для валидации JWT токенов
|
||
status: pending
|
||
- id: plan_database_migration
|
||
content: Спланировать миграцию базы данных (схемы/отдельные БД)
|
||
status: pending
|
||
- id: extract_auth_service
|
||
content: Выделить Auth Service как первый микросервис
|
||
status: pending
|
||
- id: extract_payment_service
|
||
content: Выделить Payment Service как второй микросервис
|
||
status: pending
|
||
- id: setup_service_communication
|
||
content: Настроить коммуникацию между сервисами (синхронная/асинхронная)
|
||
status: pending
|
||
- id: setup_monitoring
|
||
content: Настроить мониторинг и логирование для микросервисов
|
||
status: pending
|
||
- id: create_docker_compose
|
||
content: Создать docker-compose для локальной разработки всех микросервисов
|
||
status: pending
|
||
---
|
||
|
||
# План разделения на микросервисы
|
||
|
||
## Анализ текущей архитектуры
|
||
|
||
Текущий монолит включает следующие доменные области:
|
||
|
||
1. **Authentication & User Management** - JWT, Telegram auth, пользователи
|
||
2. **Content Management** - Packs, Cards, Tests, Games
|
||
3. **Payments & Subscriptions** - YooKassa, Google Play, RuStore
|
||
4. **Statistics & Analytics** - User statistics, achievements, word statistics
|
||
5. **Admin Panel** - Админские функции
|
||
6. **Telegram Bot** - Бот для авторизации
|
||
7. **Cron Jobs & Background Tasks** - Фоновые задачи
|
||
|
||
## Предлагаемое разделение на микросервисы
|
||
|
||
### 1. **Auth Service** (Сервис аутентификации)
|
||
|
||
**Ответственность:**
|
||
|
||
- JWT токены (access/refresh)
|
||
- Регистрация/логин пользователей
|
||
- Telegram авторизация (генерация кодов)
|
||
- Управление пользователями (CRUD)
|
||
- ACL и авторизация
|
||
|
||
**База данных:**
|
||
|
||
- `users`, `auth`, `tokens`, `refresh_tokens`, `telegram_auth_codes`
|
||
|
||
**API Endpoints:**
|
||
|
||
- `/api/v2/auth/*` (register, login, refresh, logout, telegram)
|
||
- `/api/v2/users/*` (CRUD пользователей)
|
||
|
||
**Зависимости:**
|
||
|
||
- PostgreSQL (собственная схема)
|
||
- Telegram Bot API (для авторизации)
|
||
|
||
**Технологии:**
|
||
|
||
- Dart + Shelf (можно оставить или перейти на Go/Node.js)
|
||
|
||
**Особенности:**
|
||
|
||
- Критический сервис - должен быть высокодоступным
|
||
- Низкая задержка критична для всех запросов
|
||
|
||
---
|
||
|
||
### 2. **Content Service** (Сервис контента)
|
||
|
||
**Ответственность:**
|
||
|
||
- Управление паками карточек (CardPacks)
|
||
- Управление карточками (GameCards)
|
||
- Управление тестами (Tests)
|
||
- Управление играми (Games assets)
|
||
- Голоса карточек (CardVoices)
|
||
- Доступ к контенту (проверка прав доступа через Auth Service)
|
||
|
||
**База данных:**
|
||
|
||
- `card_packs`, `game_cards`, `card_pack_cards`, `card_voices`, `tests`, `tasks`
|
||
|
||
**API Endpoints:**
|
||
|
||
- `/api/v2/packs/*`
|
||
- `/api/v2/tests/*`
|
||
- `/api/v2/games/*`
|
||
- `/api/v2/voice/*`
|
||
|
||
**Зависимости:**
|
||
|
||
- PostgreSQL (собственная схема или shared с Payments для связей)
|
||
- Auth Service (проверка доступа через API или shared token validation)
|
||
|
||
**Технологии:**
|
||
|
||
- Dart + Shelf (можно перейти на Python/FastAPI для удобства работы с контентом)
|
||
|
||
**Особенности:**
|
||
|
||
- Статические файлы (изображения, аудио) - можно вынести в CDN/Storage
|
||
- Высокая нагрузка на чтение
|
||
|
||
---
|
||
|
||
### 3. **Payment Service** (Сервис платежей)
|
||
|
||
**Ответственность:**
|
||
|
||
- Обработка платежей через YooKassa
|
||
- Обработка IAP (Google Play, RuStore)
|
||
- Управление промокодами
|
||
- Управление скидками (discounts)
|
||
- Покупка паков
|
||
- Webhooks от платежных систем
|
||
|
||
**База данных:**
|
||
|
||
- `payments`, `promo_codes`, `discounts`, `subscriptions` (или отдельный сервис)
|
||
|
||
**API Endpoints:**
|
||
|
||
- `/api/v2/purchases/*`
|
||
- `/api/v2/promocodes/*`
|
||
- `/api/v2/discounts/*`
|
||
- `/api/webhooks/yookassa`, `/api/webhooks/google-play`, `/api/webhooks/rustore`
|
||
|
||
**Зависимости:**
|
||
|
||
- PostgreSQL (собственная схема)
|
||
- Auth Service (проверка пользователя)
|
||
- Content Service (информация о паках для покупки)
|
||
- YooKassa API, Google Play API, RuStore API
|
||
|
||
**Технологии:**
|
||
|
||
- Dart + Shelf или Node.js/TypeScript (удобная работа с webhooks)
|
||
|
||
**Особенности:**
|
||
|
||
- Высокие требования к безопасности
|
||
- Идемпотентность операций
|
||
- Обработка webhooks
|
||
|
||
---
|
||
|
||
### 4. **Subscription Service** (Сервис подписок)
|
||
|
||
**Ответственность:**
|
||
|
||
- Управление подписками пользователей
|
||
- Проверка активности подписки
|
||
- Фичи подписки
|
||
- Автопродление (через cron)
|
||
|
||
**База данных:**
|
||
|
||
- `subscriptions` (может быть shared с Payment Service на этапе миграции)
|
||
|
||
**API Endpoints:**
|
||
|
||
- `/api/v2/subscriptions/*`
|
||
|
||
**Зависимости:**
|
||
|
||
- PostgreSQL (собственная схема или shared с Payment)
|
||
- Auth Service (проверка пользователя)
|
||
- Payment Service (создание подписки через платеж)
|
||
|
||
**Технологии:**
|
||
|
||
- Dart + Shelf или отдельный микросервис
|
||
|
||
**Вариант:** Можно объединить с Payment Service на первом этапе, если логика тесно связана.
|
||
|
||
---
|
||
|
||
### 5. **Statistics Service** (Сервис статистики)
|
||
|
||
**Ответственность:**
|
||
|
||
- Статистика пользователей (user statistics)
|
||
- Статистика по словам (word statistics)
|
||
- Достижения (achievements)
|
||
- Сессии обучения (study sessions)
|
||
- Аналитика и отчеты
|
||
|
||
**База данных:**
|
||
|
||
- `user_datas`, `word_statistics`, `achievements`, `study_sessions`, `pack_progress`
|
||
|
||
**API Endpoints:**
|
||
|
||
- `/api/v2/users/me/statistics/*`
|
||
- `/api/v2/users/me/achievements`
|
||
- `/api/v2/users/me/sessions`
|
||
|
||
**Зависимости:**
|
||
|
||
- PostgreSQL (собственная схема или отдельная БД для аналитики - TimescaleDB/ClickHouse)
|
||
- Auth Service (проверка пользователя)
|
||
- Content Service (информация о паках/карточках)
|
||
|
||
**Технологии:**
|
||
|
||
- Dart + Shelf или Python (удобно для аналитики) или Go (высокая производительность)
|
||
|
||
**Особенности:**
|
||
|
||
- Высокая нагрузка на запись (tracking событий)
|
||
- Возможность использовать TimescaleDB для временных рядов
|
||
- Отложенная обработка данных (бэтчинг)
|
||
|
||
---
|
||
|
||
### 6. **Admin Service** (Админ панель)
|
||
|
||
**Ответственность:**
|
||
|
||
- Админская авторизация
|
||
- Управление контентом (CRUD паков, карточек)
|
||
- Аналитика для админов
|
||
- Управление пользователями
|
||
- Audit логирование
|
||
|
||
**База данных:**
|
||
|
||
- `audit` (отдельная таблица для логирования действий)
|
||
- Использует данные из других сервисов
|
||
|
||
**API Endpoints:**
|
||
|
||
- `/api/v2/admin/*`
|
||
|
||
**Зависимости:**
|
||
|
||
- Auth Service (проверка админ прав)
|
||
- Content Service (управление контентом)
|
||
- Payment Service (управление платежами)
|
||
- Statistics Service (аналитика)
|
||
|
||
**Технологии:**
|
||
|
||
- Dart + Shelf (можно оставить текущий стек)
|
||
|
||
**Особенности:**
|
||
|
||
- Агрегирует данные из нескольких сервисов
|
||
- Требует высоких прав доступа
|
||
|
||
---
|
||
|
||
### 7. **Telegram Bot Service** (Сервис Telegram бота)
|
||
|
||
**Ответственность:**
|
||
|
||
- Обработка команд Telegram бота
|
||
- Генерация кодов авторизации для веба
|
||
- Интеграция с Auth Service
|
||
|
||
**База данных:**
|
||
|
||
- Может использовать shared `telegram_auth_codes` или собственную
|
||
|
||
**API Endpoints:**
|
||
|
||
- `/api/v2/telegram-bot/*`
|
||
- Telegram Bot API webhook
|
||
|
||
**Зависимости:**
|
||
|
||
- Auth Service (создание/проверка кодов)
|
||
- Telegram Bot API
|
||
|
||
**Технологии:**
|
||
|
||
- Dart + Shelf или Node.js/TypeScript (удобные библиотеки для Telegram)
|
||
|
||
**Особенности:**
|
||
|
||
- Относительно изолированный сервис
|
||
- Может работать независимо
|
||
|
||
---
|
||
|
||
### 8. **Background Jobs Service** (Сервис фоновых задач)
|
||
|
||
**Ответственность:**
|
||
|
||
- Cron задачи (backup, проверка платежей, генерация промокодов, etc.)
|
||
- Асинхронная обработка задач
|
||
- Очереди задач (опционально)
|
||
|
||
**Зависимости:**
|
||
|
||
- Все остальные сервисы (для выполнения задач)
|
||
|
||
**Технологии:**
|
||
|
||
- Dart (текущий стек) или перейти на специализированное решение (Bull/BullMQ на Node.js, Celery на Python)
|
||
|
||
**Альтернатива:** Можно интегрировать в каждый сервис отдельно или использовать общий Job Queue (Redis + Worker).
|
||
|
||
---
|
||
|
||
## Стратегия миграции
|
||
|
||
### Фаза 1: Подготовка (1-2 недели)
|
||
|
||
1. **Выделить общие компоненты:**
|
||
|
||
- Общие DTO/models в `mnemo_cards_common`
|
||
- Shared database connection pool
|
||
- API Gateway (опционально, можно использовать nginx/kong)
|
||
|
||
2. **Создать API Gateway:**
|
||
|
||
- Единая точка входа для клиентов
|
||
- Маршрутизация к микросервисам
|
||
- Агрегация запросов (если нужно)
|
||
- Rate limiting, CORS
|
||
|
||
### Фаза 2: Выделение критических сервисов (2-4 недели)
|
||
|
||
**Приоритет 1: Auth Service**
|
||
|
||
- Выделить аутентификацию в отдельный сервис
|
||
- Создать JWT validation library для других сервисов
|
||
- Мигрировать пользователей
|
||
|
||
**Приоритет 2: Payment Service**
|
||
|
||
- Выделить платежи
|
||
- Изолировать webhooks
|
||
- Мигрировать платежные данные
|
||
|
||
### Фаза 3: Выделение остальных сервисов (4-8 недель)
|
||
|
||
**Приоритет 3: Content Service**
|
||
|
||
- Выделить управление контентом
|
||
- Вынести статические файлы в CDN/Storage
|
||
|
||
**Приоритет 4: Statistics Service**
|
||
|
||
- Выделить статистику
|
||
- Оптимизировать запись данных (бэтчинг)
|
||
|
||
**Приоритет 5: Остальные сервисы**
|
||
|
||
- Admin Service
|
||
- Telegram Bot Service
|
||
- Background Jobs Service
|
||
|
||
### Фаза 4: Оптимизация (ongoing)
|
||
|
||
- Разделение баз данных (Database per Service)
|
||
- Кэширование (Redis)
|
||
- Message Queue для асинхронной коммуникации
|
||
- Мониторинг и логирование (ELK, Prometheus)
|
||
|
||
---
|
||
|
||
## Схема коммуникации между сервисами
|
||
|
||
```mermaid
|
||
graph TB
|
||
Client[Web Client] --> Gateway[API Gateway]
|
||
|
||
Gateway --> AuthService[Auth Service]
|
||
Gateway --> ContentService[Content Service]
|
||
Gateway --> PaymentService[Payment Service]
|
||
Gateway --> SubscriptionService[Subscription Service]
|
||
Gateway --> StatisticsService[Statistics Service]
|
||
Gateway --> AdminService[Admin Service]
|
||
|
||
TelegramBot[Telegram Bot] --> AuthService
|
||
TelegramBot --> Gateway
|
||
|
||
PaymentService --> AuthService
|
||
PaymentService --> ContentService
|
||
SubscriptionService --> AuthService
|
||
SubscriptionService --> PaymentService
|
||
StatisticsService --> AuthService
|
||
StatisticsService --> ContentService
|
||
AdminService --> AuthService
|
||
AdminService --> ContentService
|
||
AdminService --> PaymentService
|
||
AdminService --> StatisticsService
|
||
|
||
BackgroundJobs[Background Jobs] --> AuthService
|
||
BackgroundJobs --> PaymentService
|
||
BackgroundJobs --> StatisticsService
|
||
|
||
AuthService --> AuthDB[(Auth DB)]
|
||
ContentService --> ContentDB[(Content DB)]
|
||
PaymentService --> PaymentDB[(Payment DB)]
|
||
SubscriptionService --> SubscriptionDB[(Subscription DB)]
|
||
StatisticsService --> StatisticsDB[(Statistics DB)]
|
||
```
|
||
|
||
---
|
||
|
||
## Рекомендации по базам данных (гибридный подход)
|
||
|
||
### Вариант 1: Shared Database на первом этапе
|
||
|
||
- Все сервисы используют одну БД, но разные схемы (namespaces)
|
||
- Упрощает миграцию
|
||
- Позволяет постепенно разделять
|
||
|
||
### Вариант 2: Database per Service (целевое состояние)
|
||
|
||
**Auth Service:**
|
||
|
||
- `auth_db` - users, tokens, refresh_tokens, telegram_auth_codes
|
||
|
||
**Content Service:**
|
||
|
||
- `content_db` - card_packs, game_cards, card_voices, tests, tasks
|
||
|
||
**Payment Service:**
|
||
|
||
- `payment_db` - payments, promo_codes, discounts
|
||
|
||
**Subscription Service:**
|
||
|
||
- `subscription_db` - subscriptions
|
||
|
||
**Statistics Service:**
|
||
|
||
- `statistics_db` - user_datas, word_statistics, achievements, study_sessions
|
||
- Или TimescaleDB для временных рядов
|
||
|
||
### Переходные связи:
|
||
|
||
Для связей между сервисами использовать:
|
||
|
||
- **API calls** - синхронная коммуникация (для проверки доступа, получения данных)
|
||
- **Event-driven** - асинхронная коммуникация (опционально, через message queue)
|
||
- **Shared IDs** - использование UUID для связи между сервисами
|
||
|
||
---
|
||
|
||
## Технологические рекомендации
|
||
|
||
### API Gateway
|
||
|
||
- **Kong** или **nginx** - для маршрутизации
|
||
- Или **Istio** для более сложных сценариев
|
||
|
||
### Service Mesh (опционально)
|
||
|
||
- **Istio** или **Linkerd** - для управления трафиком, безопасности, observability
|
||
|
||
### Message Queue (для асинхронной коммуникации)
|
||
|
||
- **Redis Pub/Sub** или **RabbitMQ** или **NATS**
|
||
- Для событий: payment_completed, user_registered, etc.
|
||
|
||
### Мониторинг
|
||
|
||
- **Prometheus + Grafana** - метрики
|
||
- **ELK Stack** (Elasticsearch, Logstash, Kibana) - логи
|
||
- **Jaeger** или **Zipkin** - distributed tracing
|
||
|
||
### Кэширование
|
||
|
||
- **Redis** - для кэширования токенов, контента, статистики
|
||
|
||
---
|
||
|
||
## Файлы, которые нужно будет изменить/создать
|
||
|
||
### Новые директории для микросервисов:
|
||
|
||
- `services/auth-service/`
|
||
- `services/content-service/`
|
||
- `services/payment-service/`
|
||
- `services/subscription-service/`
|
||
- `services/statistics-service/`
|
||
- `services/admin-service/`
|
||
- `services/telegram-bot-service/`
|
||
- `services/background-jobs-service/`
|
||
|
||
### Общие компоненты:
|
||
|
||
- `shared/jwt-validator/` - библиотека для валидации JWT
|
||
- `shared/database-migrations/` - миграции БД
|
||
- `shared/common-models/` - общие модели (уже есть в `mnemo_cards_common`)
|
||
|
||
### Конфигурация:
|
||
|
||
- `docker-compose.microservices.yml` - оркестрация всех сервисов
|
||
- `infrastructure/` - terraform/k8s конфигурации
|
||
|
||
---
|
||
|
||
## Критерии успешности разделения
|
||
|
||
1. ✅ Каждый сервис можно деплоить независимо
|
||
2. ✅ Сервисы могут использовать разные технологии
|
||
3. ✅ Отказ одного сервиса не ломает остальные
|
||
4. ✅ Легко масштабировать отдельные сервисы
|
||
5. ✅ Четкое разделение ответственности
|
||
6. ✅ Тестируемость каждого сервиса отдельно
|
||
|
||
---
|
||
|
||
## Риски и митигация
|
||
|
||
### Риск 1: Сложность отладки распределенной системы
|
||
|
||
**Митигация:** Использовать distributed tracing (Jaeger), централизованное логирование
|
||
|
||
### Риск 2: Сетевая задержка между сервисами
|
||
|
||
**Митигация:** Кэширование, асинхронная коммуникация где возможно, оптимизация API calls
|
||
|
||
### Риск 3: Консистентность данных между сервисами
|
||
|
||
**Митигация:** Event-driven архитектура, eventual consistency, saga pattern для транзакций
|
||
|
||
### Риск 4: Усложнение деплоя
|
||
|
||
**Митигация:** Docker Compose для разработки, Kubernetes для продакшена, CI/CD для каждого сервиса |