Архитектура программного обеспечения «Rowux»

Документ описывает архитектуру ПО «Rowux»: архитектурный подход, логические уровни, состав подсистем, взаимодействие подсистем (основные потоки данных) и модель изоляции и безопасности. Процессы разработки, сборки, обновления и сопровождения продукта описаны отдельно и в настоящем документе не рассматриваются.

Рис. 1. Общая архитектура платформы Rowux. Цветом обозначены группы компонентов: собственная разработка, доработанные компоненты с открытым исходным кодом, инфраструктурные компоненты. Связующий слой (уровень прикладной логики) обеспечивает единый вход, сквозную передачу сессий, общие хранилища и единый шлюз доступа к языковым моделям. Код аналитического агента исполняется в изолированной песочнице без доступа к сети и секретам.

#1. Архитектурный подход

Rowux построено по сервис-ориентированной (микросервисной) архитектуре. Все подсистемы упакованы в контейнеры и оркеструются средствами Docker Compose. Между собой сервисы взаимодействуют по внутренним сетям; наружу доступ публикуется через пограничный маршрутизатор трафика (reverse-proxy) с терминацией TLS.

Ключевой принцип продукта — единый связующий слой, обеспечивающий бесшовную интеграцию разнородных подсистем: единая аутентификация, сквозная передача пользовательских сессий, общие хранилища, единый шлюз доступа к языковым моделям.

#2. Логические уровни

#2.1. Уровень представления (интерфейсы)

• Портал (UI) — единая точка входа и навигации.
• Чат-интерфейс — работа с моделями и базами знаний.
• Конструктор сценариев — визуальная сборка агентов и обработчиков.
• Интерфейс потоковой доставки (Ghost-Writer UI) — отображение результатов ИИ-сценариев в реальном времени.
• Лендинг — публичная информационная страница.

#2.2. Уровень прикладной логики

• Сервер-обвязка (Backend) — проверка токенов доступа, синхронизация сессий между подсистемами, единая точка доступа к подсистеме мониторинга.
• Сервис потоковой доставки (Ghost-Writer Backend) — потоковая передача результатов выполнения сценариев в интерфейс.
• Аналитический агент — автономный агент интеллектуальной аналитики.
• Сервис защиты данных (PII-Guard) — обнаружение персональных данных и атак «инъекция инструкций».
• Библиотека интеграций и компонентов — адаптеры и функциональные блоки, связывающие подсистемы.

#2.3. Уровень платформенных подсистем

• Чат-подсистема и конструктор сценариев (доработанные open-source компоненты).
• Шлюз доступа к языковым моделям — единый OpenAI-совместимый интерфейс к различным поставщикам, включая российских.

#2.4. Инфраструктурный уровень

• Система единого входа (SSO) — аутентификация и разграничение доступа.
• Реляционные СУБД — хранение данных подсистем.
• Объектное S3-совместимое хранилище — файлы, артефакты, базы знаний.
• Векторное хранилище — индексы для поиска по знаниям (RAG).
• Подсистема мониторинга — сбор метрик и информационные панели.
• Пограничный маршрутизатор трафика — маршрутизация и TLS.

#3. Взаимодействие подсистем (основные потоки)

Рис. 2. Основные потоки передачи данных между подсистемами. Стрелки показывают направление передачи данных. Каждый из шести сценариев выделен отдельным цветом.

1. Аутентификация. Пользователь входит через единую систему входа; сервер- обвязка проверяет токены и синхронизирует сессии между чат-интерфейсом и конструктором сценариев (единый вход во все подсистемы).
2. Диалог и поиск по знаниям. Чат-интерфейс обращается к языковой модели через шлюз моделей; при работе с базой знаний релевантные фрагменты извлекаются из векторного хранилища, при необходимости обезличиваются и передаются модели.
3. Выполнение сценариев. Конструктор сценариев исполняет флоу на своей серверной части; результаты потоково доставляются в интерфейс сервисом потоковой доставки. Выполнение продолжается независимо от состояния клиента (навигация, перезагрузка страницы не прерывают задачу).
4. Аналитика. Аналитический агент планирует задачу и исполняет автогенерируемый код в изолированной песочнице; сама песочница не имеет доступа к сети и секретам — все обращения к данным (S3, СУБД только на чтение, базы знаний) проходят через контроллер агента, где сосредоточены секреты.
5. Хранение. Файлы, артефакты и базы знаний хранятся в объектном хранилище; индексы — в векторном; структурированные данные подсистем — в реляционных СУБД.
6. Наблюдаемость. Метрики подсистем собираются подсистемой мониторинга и отображаются на информационных панелях.

Детальные описания отдельных потоков приведены в технической документации проекта: жизненный цикл сценария — docs/flow-lifecycle.md; изоляция песочницы аналитического агента — docs/sandbox-isolation-handoff.md; интеграция с BI-системами — docs/client-bi-integration.md, docs/remote-bi-setup.md.

#4. Модель изоляции и безопасности

• Единая аутентификация и разграничение доступа для всех подсистем.
• Изоляция исполнения автогенерируемого кода в одноразовых контейнерах без сетевого доступа наружу и без секретов в окружении (опционально — на отдельной виртуальной машине с усиленной изоляцией среды исполнения).
• Доступ к корпоративным данным только на чтение для аналитического агента.
• Шифрование секретов при хранении.
• Обнаружение и обезличивание персональных данных, защита от атак «инъекция инструкций».
• Закрытие исходящего трафика в промышленном контуре (отдельное наложение файла оркестрации).

#5. Развёртывание архитектуры

Все перечисленные подсистемы поставляются как единый комплекс и разворачиваются на инфраструктуре организации средствами контейнеризации (Docker) и оркестрации (Docker Compose). Подсистемы взаимодействуют по внутренним сетям комплекса; СУБД и хранилища наружу не публикуются, внешний доступ пользователей осуществляется только через пограничный маршрутизатор трафика по протоколу HTTPS. Комплекс может эксплуатироваться в едином окружении либо распределяться по нескольким вычислительным узлам (в частности, изолированное исполнение кода аналитического агента может выноситься на отдельный узел).