Технологический стек

1. Главная мысль

Электронная транспортная платформа (далее ЭТП) исторически рабочая система,на базе ЭТП мы можем реализовать прохождение аттестации НИИАС, как оператора ГИС ЭПД, и выход с этим продуктом на старт Проекта "Электронные транспортные документы" 01.09.2026г, но её стек в дальнейшем требует модернизации для реализации задачи оператора ИС ЭПД для значительного круга Клиентов.Более того действующая ЭТП готова к реализации всех 6-ти пунктов "Продуктовой модели", указанных в документе присланном Вам 07.05.2026г. Для нового контура ЭПД нужен стек, который умеет:

безопасно работать с юридически значимыми XML и подписями;
держать версии XSD ФНС;
отправлять документы в ГИС ЭПД с контролем SLA;
хранить документы и аудит годами;
масштабироваться без остановки;
проходить проверки ИБ и эксплуатации.

Рекомендуемое решение: новый модуль ИС ЭПД делать на современном Java-стеке, связав его с legacy через API и справочники. Не надо закапывать ЭПД глубоко внутрь старого ExtJS/Struts-приложения.

2. Рекомендуемый стек

Слой	Технология	Простое объяснение
Backend	Java 21 + Spring Boot 3	Основной ~~“двигатель”~~“двигатель” системы. Java хорошо подходит для банковских, государственных и документооборотных систем
API Gateway	Spring Cloud Gateway	Центральный вход: проверяет запросы, маршрутизирует, пишет аудит
База данных	PostgreSQL	Главный журнал и картотека: документы, статусы, связи, справочники
Файловое хранилище	MinIO, дальше Ceph/S3 с WORM	Электронный архив XML, PDF, подписей; WORM нужен, чтобы документы нельзя было тихо подменить
Очереди	Kafka для production, RabbitMQ допустим для MVP	Диспетчерская очередь: если ГИС ЭПД временно не отвечает, документ не теряется
Подпись	КриптоПро JCP/JCSP, КриптоПро browser plug-in, HSM позже	Юридическая подпись по ГОСТ; HSM нужен для защищённого хранения серверных ключей и массового подписания
Авторизация	Keycloak	Единая проходная: пользователи, роли, организации, интеграция с ЕСИА в будущем
Frontend	React + TypeScript + Vite	Современный веб-кабинет, легче нанимать разработчиков, быстрее делать формы
Мобильный контур	PWA/React на демо, Flutter позже	Быстрый водительский интерфейс; Flutter можно взять для полноценного мобильного приложения
Наблюдаемость	Prometheus + Grafana + Loki + OpenTelemetry	Приборная панель: видим ошибки, задержки, статусы, SLA
Безопасность	Wazuh/SIEM, Vault, mTLS/ГОСТ TLS	Контроль событий ИБ, секреты, защищённый канал в ГИС ЭПД
Развёртывание	Docker Compose для демо, Kubernetes + ArgoCD для production	Сначала быстрый стенд, потом промышленная эксплуатация

3. Почему старый стек ЭТП в дальнейшем требует модернизации

Текущий стек по обзору logovista/СИСТЕМА_ОБЗОР.md: Java 8, Tomcat 8.5, MySQL 5.7, ExtJS 4.x, Struts 2.3, Spring 3.2, Hibernate 3, ручной деплой .war, четыре webapp на одной БД.

Это не ““плохая ~~система”~~система” в историческом смысле. Она просто создавалась для другой эпохи. Для ЭПД-оператора риски стали слишком дорогими.

Проблема	Почему это плохо для ЭПД
Java 8 / Spring 3 / Struts 2.3 сняты с нормальной поддержки	Уязвимости сложнее закрывать; проверяющие будут спрашивать про обновления
MySQL 5.7 устарел	Хуже с современными возможностями репликации, производительностью, JSON, аудитом, расширениями и поддержкой
ExtJS 4.x	Трудно нанимать фронтендеров, сложно делать современный кабинет и мобильные сценарии
Ручной деплой `.war`	Релиз зависит от человека; риск ошибки при обновлении
Нет CI/CD и миграций схемы	Нельзя уверенно доказать, что сборка воспроизводима, а БД изменяется контролируемо
Файлы в БД через longblob	Бэкапы тяжёлые, репликация дорогая, архив юридически значимых документов неудобен
Нет полноценной очереди и outbox-паттерна	Сложнее гарантировать отправку в ГИС ЭПД и не потерять документ при сбое
Старый UI и монолитная архитектура	Новые типы документов, версии XSD и связи будут добавляться медленно и рискованно

Главный тезис: Старый стек ЭТП требует в дальнейшем переработки для production-контура ИС ЭПД. Необходимо указать следующие причины: устаревшие компоненты, известные классы уязвимостей, слабая производительность на современных нагрузках ЭПД, ручная эксплуатация, тяжёлое хранение файлов в БД и высокая стоимость сопровождения. Его можно временно стабилизировать как legacy-систему и источник справочников, а в дальнейшем сделать на нём новый юридически значимый операторский контур.

3.1. Почему это production-риск

Риск	Что это означает для бизнеса
Безопасность	Старые Java/Spring/Struts/Tomcat/MySQL сложнее патчить; ~~“дыры”~~“дыры” в таком контуре превращаются в риск утечки документов, сертификатов, персональных данных и коммерческой информации
Производительность	ЭПД требует массовой генерации XML, XSD-валидации, подписи, очередей, повторных отправок и хранения больших архивов; legacy-монолит и файлы в БД будут быстро упираться в диск, БД и ручную эксплуатацию
Надёжность	Нет нормального CI/CD, миграций схемы, изоляции контуров и управляемых очередей; сбой или неудачный релиз может остановить документооборот
Проверяемость	Для оператора ИС ЭПД нужны понятные логи, аудит, контроль SLA, неизменяемый архив и трассировка; в старом стеке это придётся дорого достраивать сбоку
Кадры	Разработчиков под ExtJS 4, Struts 2.3 и Hibernate 3 найти сложнее; стоимость изменений растёт, скорость падает
Масштабирование	Старый контур трудно горизонтально масштабировать и безопасно разделять по клиентам, ролям, документам и версиям XSD

Вывод: Использовать старую ЭТП можно как промышленную основу для быстрого выхода на рынок и решения текущих продуктовых моделей. Роль старой ЭТП —— источник опыта, бизнес-логики, справочников и, возможно, интеграционных данных. Правильная роль нового стека —— production-контур документов, подписей, ГИС ЭПД, аудита и архива.

3.2. 24/7, нагрузка и база данных

Контур ИС ЭПД должен работать 24/7: документы создаются, подписываются и уходят в ГИС ЭПД постоянно, включая ночные рейсы, выходные, пики отгрузок и массовые повторы после сбоев внешней системы.

Хочу указать уязвимости старого стека ЭТП при промышленном масштабировании":

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

Для ИС ЭПД это критично: если система ~~“просела”~~“просела”, документы не уходят, участники перевозки не видят статусы, нарушается SLA передачи в ГИС ЭПД, а бизнес получает операционный простой.

PostgreSQL здесь не "серебряная пуля", но даёт нормальную траекторию роста:

Возможность	Зачем нужна ИС ЭПД
Репликация и read replicas	Разнести чтение, отчёты, карточки и поиск от основной записи документов
Партиционирование	Делить большие таблицы документов, событий и аудита по датам/тенантам
Индексы, JSONB, полнотекстовый поиск	Быстро искать по статусам, участникам, УИД, реквизитам, техническим ошибкам
Row Level Security	Безопасно разделять данные организаций в мультитенантной системе
Расширения и Postgres Pro	Дальше расти в промышленную российскую поставку с поддержкой
Logical replication / CDC	Передавать события в аналитику, архив, интеграции без нагрузки на основной контур
Совместимость с k8s-операторами и бэкап-инструментами	Управляемый production: резервные копии, восстановление, мониторинг

Правильная схема нагрузки: PostgreSQL хранит метаданные, статусы, связи и аудит; MinIO/Ceph хранит тяжёлые XML/PDF/подписи; Kafka/RabbitMQ берёт на себя очереди отправки и повторов; сервисы масштабируются горизонтально. В таком контуре понятно, куда добавлять ресурсы при росте нагрузки.

4. Как, на наш взгляд, дорабатывать, куда стремиться.

Минимальный промышленный вариант:

Java 21 + Spring Boot 3.
PostgreSQL.
MinIO для XML/PDF/подписей.
Kafka или RabbitMQ для очередей.
Keycloak для пользователей и ролей.
React + TypeScript для веб-кабинета.
КриптоПро для УКЭП.
Prometheus/Grafana/Loki для мониторинга.
Docker Compose для демо; Kubernetes для production при большом росте числа клиентов.

Для первого прототипа разумный компромисс: модульный монолит на Spring Boot + отдельные сервисы gis-epd-gateway, signature-service, mock-gis-epd, frontend. Это быстрее, чем сразу строить 20 микросервисов, но не закрывает дорогу к росту.

5. Объяснение технологий

Термин	Что сказать руководителю
XML	Официальный электронный бланк документа, который понимает ФНС и ГИС ЭПД
XSD	Чертёж XML: какие поля обязательны, как называются, какие значения допустимы
УКЭП	Электронная подпись, юридически равная собственноручной подписи организации
КриптоПро	Российский промышленный инструмент для ГОСТ-подписей и защищённых каналов
API	Договор между системами: как одна система отправляет данные другой
Kafka / RabbitMQ	Электронная очередь: если адресат временно недоступен, документ ждёт и не теряется
PostgreSQL	Надёжная база данных для карточек, статусов, связей и справочников
MinIO / S3	Электронный архив больших файлов: XML, PDF, подписи, вложения
WORM	Режим архива ““записал и нельзя ~~подменить”~~подменить”; важен для доверия и проверок
Keycloak	Система пропусков: кто вошёл, от какой организации, что ему разрешено
Workflow	Машина маршрута: кто подписывает следующий титул и куда идёт документ
Docker	Упаковка программы, чтобы она одинаково запускалась на стенде и сервере
Kubernetes	Промышленный диспетчер серверов: перезапускает упавшие сервисы и раскатывает версии
Observability	Приборы системы: логи, метрики, трассировки, чтобы быстро видеть сбои

6. Что важно

Система будет делать юридически значимые документы по государственным форматам.
Каждый документ проходит проверку по официальной XSD ФНС.
Каждый титул подписывает правильная роль: грузоотправитель, перевозчик, грузополучатель, экспедитор.
Документ не теряется при сбоях: стоит в очереди, повторяется, журналируется.
Руководство видит статус: создан, подписан, отправлен, принят, отклонён, закрыт.
Архив защищён от подмены.
Старую ЭТП используем на этапе старта и аккуратно замещаем блоки по мере готовности: используем опыт старой ЭТП и справочники, но новый ЭПД-контур строим на современной базе.

7. Итоговое решение

Для прототипа: Java 21 + Spring Boot 3, PostgreSQL, MinIO, RabbitMQ/Kafka, React, Keycloak, КриптоПро/fake-mode, Docker Compose.

Для production: тот же фундамент, но Kafka, Postgres, распределённый MinIO/Ceph, Kubernetes, ArgoCD, Vault, SIEM, HSM, ГОСТ TLS.

Так мы получаем понятный путь: быстрый демо-стенд сейчас и безболезненный рост до массового оператора ИС ЭПД позже.