Островский_ВКР_презентация (2)

1.

Разработка онлайн-платформы для взаимодействия
клиентов и исполнителей
Платформа HomeMatch · Выпускная квалификационная работа
МГТУ им. Н. Э. Баумана
Факультет: Робототехника и комплексная автоматизация (РК)
Кафедра: Системы автоматизированного проектирования (РК6)
Группа: РК6-76Б
Автор: Островский Антон Романович
Руководитель: Пивоварова Н. В.
Москва, 2025
HomeMatch · Островский А.Р. · РК6-76Б
1 / 11

2.

2
Проблематика рынка ремонта
Рынок ремонта — «чёрный ящик» для заказчика
87% заказчиков
столкнулись с некачественным ремонтом
До 50% переплат
из-за отсутствия независимой проверки
смет
Нет ответственности
агрегаторы не отвечают за результат
работ
Существующие решения и их пределы
• YouDo, Profi.ru, Яндекс.Услуги — только поиск, без контроля качества
• ПИК-Ремонт, Саморемон — «под ключ», дорого, без гибкости
• Thumbtack, TaskRabbit — рейтинги, но без участия в процессе
HomeMatch · Островский А.Р. · РК6-76Б
2 / 11

3.

3
Цель работы и задачи
Цель
Разработка серверной части платформы HomeMatch — посредника, обеспечивающего безопасное и прозрачное взаимодействие
заказчиков и исполнителей на всём цикле заказа.
Задачи
• анализ рынка и конкурентов, формирование функциональных требований
• проектирование системной архитектуры (UML, ERD, Use Case)
• реализация серверной части на FastAPI + PostgreSQL + SQLAlchemy
• разработка подсистемы анкетирования с ветвлением
• интеграция чатов (OpenIM) и векторного поиска (Qdrant + RuCLIP)
• развёртывание в Docker за Nginx с TLS
HomeMatch · Островский А.Р. · РК6-76Б
3 / 11

4.

4
Функциональные требования и Use Case
Функциональные требования
Use Case (упрощённо)
• регистрация и авторизация по SMS
• оформление заказа через анкету с ветвлением
Регистрация / вход
• просмотр карточек исполнителей
• отклик исполнителя на заказ
Создание заказа
• обмен сообщениями (чат)
• выставление отзывов и рейтингов
• визуальный поиск по проектам
• административное управление анкетами
Заказчи
к
Просмотр карточки исполнителя
Отклик на заказ
Обмен сообщениями
Исполни
тель
Оставить отзыв
Управление анкетами
Админ
HomeMatch · Островский А.Р. · РК6-76Б
Подробно: сценарий «Создание заказа» — слайд 8
4 / 11

5.

5
Системная архитектура
Ключевые решения
Клиент (браузер)
Фронтенд-сервер
Nginx
SPA-приложение
отдельная машина, статика +
SSR
reverse proxy · TLS · Let's Encrypt
Все клиентские запросы → HTTPS → Nginx :443 (TLS-терминация)
/api → :8000
• Фронтенд — отдельный сервер, нет
доступа к БД
• Общение только по HTTP REST API
• Nginx: TLS-терминация (Let's Encrypt +
Certbot)
• 3 поддомена: api, im, im-admin
FastAPI
(асинхронный
backend)
FastAPI
(асинхронный
backend)
• Все секреты — в переменных
окружения
монолит
с модульной
структурой,
единый
единая
кодовая
база, монолит
с модульной
деплой
структурой
• Два независимых окружения: dev и
prod
PostgreSQL
Redis
Qdrant
OpenIM
основная БД (бизнесданные)
кэш, коды подтверждения,
TTL
векторная БД (RuCLIP)
внешний чат-сервер
Внутренняя Docker-сеть · сервисы общаются по HTTP/TCP без выхода наружу
HomeMatch · Островский А.Р. · РК6-76Б
5 / 11

6.

6
Модули бэкенда и обоснование монолита
11 доменных модулей (DDD)
Монолит — осознанный выбор
auth
users
executors
регистрация, SMS, JWT, сессии
профили заказчиков
карточки исполнителей
• быстрый старт, низкий порог входа
• гибкость при частых правках требований
• одна транзакционная граница в PostgreSQL
executor_profile
orders
order_temp
• простая отладка и единый деплой
кабинет исполнителя
заказы, статусы, жизненный цикл
черновики заказов
• меньше инфраструктурных затрат
anketa
review
chat
анкеты с ветвлением
отзывы и рейтинги
надстройка над OpenIM
rec
files
векторный поиск (Qdrant)
единое хранилище метаданных
Готов к эволюции:
• модульная структура — кандидаты на вынос:
• – chat (уже фактически внешний)
• – rec (свой стор)
В каждом модуле: модели SQLAlchemy · схемы Pydantic · APIRouter · сервисный слой
HomeMatch · Островский А.Р. · РК6-76Б
6 / 11

7.

7
Нестандартные подсистемы: Qdrant и OpenIM
Qdrant — векторная БД
RuCLIP → эмбеддинги изображений и текстов → Qdrant
OpenIM — внешний чат-сервер
Что даёт «из коробки»:
• хранение и доставка сообщений
Изображение
RuCLIP
Qdrant
• групповые и личные диалоги, пуш-уведомления
• собственный сервер и админ-панель
• REST API для интеграции
Почему не pgvector:
• спроектирован под ANN-поиск, индекс HNSW из коробки
• масштабируется независимо от основной БД
• не нагружает транзакционный пул PostgreSQL
• payload-фильтрация за один запрос (теги, гео, категории)
Роль моего backend:
• гибкие коллекции под разные типы эмбеддингов
• регистрация пользователей в OpenIM
• создание диалога по бизнес-событию (отклик)
• управление правами доступа к чатам
• связь chat_id с сущностями платформы
Своё писать = 3-4 месяца. OpenIM решает задачу за 1-2 недели интеграции.
HomeMatch · Островский А.Р. · РК6-76Б
7 / 11

8.

8
Подсистема анкетирования и сценарий «Создание заказа»
Модель: анкета — конфигурация, не код
Frontend
Вопрос 1
FastAPI
PostgreSQL
GET /anketa/active
Какой тип ремонта?
= косметический
UML Sequence: «Создание заказа»
SELECT anketa + questions +
transitions
= капитальный
Вопрос 2
Вопрос 3
Стены: какой тип
отделки?
Стяжка: какой тип
основания?
rows
200 OK: структура анкеты
POST /order/create (ответы +
бюджет)
validate
validate (Pydantic)
(Pydantic)
INSERT Order + answers (TX)
Сущности в БД
• anketa (со статусом active/archive)
order_id
• question, question_type, hint
• answer_option
201 Created: order_id
• anketa_question (связь + next_question_id)
• answer_option_question (ветвление + next_question_id)
HomeMatch · Островский А.Р. · РК6-76Б
8 / 11

9.

9
Проектирование подсистемы чата
Чат — тонкая надстройка над OpenIM
• обмен сообщениями идёт напрямую client ↔ OpenIM
• мой backend не транзитит сообщения
UML Sequence: «Отклик исполнителя → чат»
Исполнитель
FastAPI
PostgreSQL
OpenIM
POST /order/{id}/respond
• backend регистрирует участников в OpenIM
INSERT
order_executor
• backend создаёт диалог по бизнес-событию (отклик)
ok
• backend хранит привязку: order ↔ chat_id
• backend управляет правами: кто может писать кому
register_users (если не созданы)
user_ids
create_conversation(user_a, user_b)
chat_id
200 OK: chat_id
Выигрыш такого разделения:
• масштабирование чата независимо от платформы
UPDATE
order_executor SET
chat_id
далее: общение напрямую с OpenIM
• минимум кода для поддержки в моём backend
HomeMatch · Островский А.Р. · РК6-76Б
9 / 11

10.

10 Среда разработки и развёртывание
Среда разработки
Docker Compose · 5 контейнеров + Nginx на хосте
• Python 3.11
Nginx (на хосте)
:80 / :443 · TLS-терминация · поддомены api · im · im-admin
• FastAPI (async) + Pydantic
• SQLAlchemy 2.x (async) + Alembic
• PostgreSQL · Redis · Qdrant
fastapi_app
postgres
redis
qdrant
openim
• Docker · Docker Compose
FastAPI :8000
PostgreSQL :5432
Redis :6379
Qdrant :6333
OpenIM :10000
• Nginx + Certbot (Let's Encrypt)
• Git: две ветки — main (prod) и dev (разработка)
внутренняя Docker-сеть (изолированная)
• Два окружения: тестовый и основной сервер
• Секреты — в переменных окружения, не в репозитории
Деплой:
• git pull
• docker-compose down && docker-compose up --build -d
• docker exec fastapi_app alembic upgrade head
• systemctl restart nginx
HomeMatch · Островский А.Р. · РК6-76Б
10 / 11

11.

11 Результаты работы
• Спроектирована и реализована серверная часть HomeMatch
• Построена системная архитектура: клиент-сервер + монолит с модульной структурой
• Реализовано 11 доменных модулей бэкенда (DDD)
• Разработана подсистема анкетирования с ветвлением и версионированием
• Интегрированы OpenIM (чаты) и Qdrant + RuCLIP (векторный поиск)
• Спроектирована реляционная БД и описаны ERD-схемы
• Развёрнут стек в Docker Compose, настроен Nginx с TLS
Практическая значимость
Спасибо
за внимание!
Готов ответить
на вопросы
Получен функционирующий прототип, готовый к опытной эксплуатации и поэтапному развитию:
мобильное приложение, ML-лента рекомендаций, эволюционный вынос подсистем в микросервисы.
HomeMatch · Островский А.Р. · РК6-76Б
11 / 11