Технологический стек
Технологический стек
1. Главная мысль
АСЛогистика исторически рабочая система, но её стек устарел для задачи оператора ИС ЭПД. Для нового контура ЭПД нужен стек, который умеет:
- безопасно работать с юридически значимыми 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. Это не офисная система “с 9 до 18”, а транспортный документооборот: документы создаются, подписываются и уходят в ГИС ЭПД постоянно, включая ночные рейсы, выходные, пики отгрузок и массовые повторы после сбоев внешней системы.
В старом стеке непонятен промышленный путь масштабирования:
- одна большая БД становится узким местом;
- файлы внутри БД ухудшают резервное копирование, репликацию и скорость восстановления;
- ручные релизы и общая БД для нескольких 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.
Так мы получаем понятный путь: быстрый демо-стенд сейчас и безболезненный рост до оператора ИС ЭПД позже.