Архитектура

GetOLT — единое Spring Boot приложение, которое одновременно отдаёт веб-интерфейс, REST API, MCP-сервер и держит пул Telnet-сессий к OLT-устройствам. Никаких отдельных микросервисов: ровно один процесс, ровно одна БД. Разворачивается у вас, on-prem — учётные записи к OLT и данные абонентов не покидают периметр оператора.

Tech Stack

Слой	Технология
Backend	Spring Boot 3, Java 21
База данных	MySQL 8.0, HikariCP
ORM	Spring Data JPA, Hibernate
Frontend	Thymeleaf, Bootstrap 5, Vanilla JS
Безопасность	Spring Security, JWT, LDAP, опциональный 2FA
Кэш	Caffeine (in-memory)
Деплой	Docker, GitLab CI/CD

Поток данных

HTTP запрос
    ↓
Controller (REST/Web/MCP)
    ↓
Service Layer
    ↓
OLT-абстракция → Telnet-клиент → реальный OLT
    ↓
Repository → MySQL

Основные компоненты

Контроллеры

Веб-контроллеры рисуют Thymeleaf-страницы, REST-контроллеры обслуживают /api/v1/external/*, отдельный MCP-контроллер принимает JSON-RPC от LLM-агентов на /api/v1/external/mcp. Все три используют общий слой сервисов.

Сервисный слой

OltService — главная точка оркестрации. Под ним — специализированные сервисы: сбор конфигураций, асинхронные операции, сессии Telnet, refresh-токены, синхронизация с биллингами.

OLT-абстракция

Каждый вендор реализован как отдельный класс, наследующий базовый OLT. Команды Telnet, форматы вывода и парсинг изолированы внутри классов вендора. Добавление нового вендора = новый класс + регистрация в фабрике, см. «Добавление вендора OLT».

Сессии Telnet

OltSessionManager держит per-IP блокировку, чтобы исключить одновременные подключения к одному OLT с разных эндпоинтов. Это критично — большинство OLT не любит две параллельные Telnet-сессии.

Асинхронные операции

Отдельный thread-pool для массовых операций. Любая операция, которая может занять больше нескольких секунд, идёт через него и отдаёт taskId — UI и API не блокируются.

Scheduler

Фоновые задачи: периодический опрос OLT (интервал задаётся в конфигурации), очистка дубликатов ONU после переключений портов, регламентные служебные операции.

Поток данных: типовой опрос OLT

Scheduler — пора опросить OLT №42
   ↓
Backend API — берёт учётку и адрес OLT из БД
   ↓
OLT-абстракция — открывает Telnet-сессию, снимает список ONU и сигналы
   ↓
Backend API — нормализует ответ, обновляет состояние и историю в БД
   ↓
Web UI / External API — следующий запрос видит свежие данные

Поток данных: операция оператора

Оператор — нажимает «Перезагрузить ONU» в Web UI
   ↓
Backend API — проверяет права, пишет запись в журнал операций
   ↓
OLT-абстракция — отправляет команду на OLT
   ↓
Backend API — фиксирует результат, возвращает ответ в UI

Интеграции

• Биллинговые системы — отдельные DataSource, маппинг ONU на абонента.
• LDAP — для корпоративной авторизации операторов.
• MCP — JSON-RPC поверх HTTP для LLM-агентов и внешних автоматизаций.

Подробнее: REST API, MCP-сервер, LLM-чат, LDAP / AD.

Безопасность

• Аутентификация: локальные учётные записи или LDAP/AD, опционально 2FA.
• Роли и права доступа: разделение по ролям оператор / инженер / администратор.
• Журнал операций: каждое действие пишется с пользователем, временем и параметрами.
• Хранение учётных данных OLT — на стороне приложения, не передаются клиенту.

Дальше

• Поддерживаемое железо — список вендоров и моделей OLT.
• REST API — для внешних потребителей.
• LDAP / AD — корпоративная аутентификация.