Схема взаимодействия компонентов BOX 3.x

Карта взаимодействий#

Схема показывает референсную архитектуру BOX 3.x внутри Docker Swarm: одну мастер-ноду и горизонтально масштабируемые вычислительные ноды. Точный состав контейнеров, адреса, внешние порты и количество вычислительных узлов определяются версией BOX и спецификацией поставки.

Основной маршрут читается сверху вниз: пользователь или интеграционный клиент входит через защищённый периметр, UI/API направляет команду прикладному сервису, мастер-нода сохраняет состояние и координирует выполнение, а вычислительные ноды обрабатывают видеопотоки и возвращают события через Kafka.

Путь пользовательского запроса#

Оператор и администратор работают через браузер по HTTPS. Nginx завершает входящее соединение и отдаёт клиентское приложение React. Запросы интерфейса поступают в REST-слой, который преобразует их в вызовы внутренних gRPC-сервисов или команды для Kafka.

Права проверяются в доменах аутентификации и доступа. Область видимости должна ограничивать не только пункты интерфейса, но и предприятия, объекты, камеры, события и операции API. Корпоративная аутентификация может использовать AD, Kerberos и LDAPS.

Мастер-нода: управление и данные#

В референсной топологии BOX 3.x мастер-нода существует в единственном экземпляре и объединяет прикладной и управляющий контур. Здесь находятся UI, API, Kafka, сервисы камер, событий, пользователей, ролей, аудита, матрицы решений, счётчиков, отчётов, оповещений, конфигурации и основные хранилища.

Сервисные имена вида st-camera-storage, st-event-storage, st-auth, st-access или st-decision-matrix описывают ответственность домена. В разных релизах один домен может состоять из нескольких процессов, поэтому интеграция должна опираться на поддерживаемый API, а не на прямой доступ к контейнеру или базе.

• UI и маршрутизация запросов
• Apache Kafka
• Камеры, объекты и наблюдения
• События, фильтрация и решения
• Пользователи, роли и аудит
• Данные, отчёты, метрики и журналы

Вычислительная нода: обработка видео#

Вычислительный контур принимает видеопотоки, управляет медиасервисами, запускает модели и формирует результаты inference. inf-load-balancer распределяет камеры, inf-models-storage управляет моделями, inf-image-storage и inf-snapshot-processor работают с изображениями, а inf-monitoring и inf-pushgateway передают состояние и метрики.

Количество вычислительных нод увеличивается вместе с числом камер, FPS и ресурсоёмкостью моделей. Дополнительные компоненты обслуживают WebRTC и извлечение видеофрагментов для отчётов. Мастер-нода остаётся единой точкой управления, а обработка видео масштабируется горизонтально.

• inf-domain-gateway
• inf-mediaserver и inf-coturn
• inf-inference
• inf-load-balancer
• inf-models-storage
• inf-image-storage и inf-snapshot-processor
• inf-monitoring и inf-pushgateway
• inf-report-video-extractor

Два способа обмена#

Большинство межсервисных взаимодействий BOX 3.x проходит через Apache Kafka: брокер передаёт события, изменения сущностей, heartbeat и результаты inference. HTTP и gRPC обслуживают синхронные запросы, а ui-rest-to-grpc преобразует входящий REST-вызов во внутреннюю команду.

Такое разделение уменьшает связанность сервисов. Отправитель события не ждёт завершения всех потребителей, а новый обработчик можно подключить к согласованному топику без изменения inference. При диагностике важно проверять оба пути: синхронный ответ сервиса и прохождение сообщения через брокер.

Хранилища и границы данных#

PostgreSQL хранит транзакционные сущности и конфигурацию, ClickHouse — объёмные события и аналитические выборки, Redis — кэш и оперативные состояния, S3-совместимое хранилище — изображения, видео и файлы. Отдельные сервисы могут иметь собственную базу, чтобы изменения одного домена не связывали остальные.

Прямое чтение внутренних таблиц создаёт жёсткую зависимость от реализации. Для внешних систем используйте API, события или согласованный адаптер. Политики хранения, backup и репликации задаются отдельно для каждого типа данных.

Внешние системы#

BOX может взаимодействовать с корпоративным каталогом, почтовой системой, картографическим сервисом, системами позиционирования, VMS и бизнес-приложениями. Эти связи находятся за границей продуктового контура и должны быть описаны в отдельных правилах обмена данными.

Публичная схема намеренно не содержит адресов серверов, служебных учётных записей и параметров конкретного предприятия. Для рабочей поставки они фиксируются в закрытой архитектурной схеме и эксплуатационном runbook.

Протоколы и порты#

Ниже приведены типичные назначения из референсной топологии. Это внутренние сервисные порты, а не перечень портов для публикации наружу; доступность из конкретного сегмента определяется политикой безопасности поставки.

Как диагностировать путь#

Разбирайте проблему в том же порядке, в котором проходит запрос или событие. Сначала проверьте вход и права, затем ответ UI/API и целевого сервиса, после этого Kafka, вычислительный процесс, хранилище и конечного потребителя.

• Доступен ли HTTPS и проходит ли аутентификация
• Возвращает ли API ожидаемый код и схему
• Работает ли gRPC-сервис и не истёк ли deadline
• Опубликовано ли сообщение в нужный Kafka topic
• Есть ли consumer lag или ошибка обработчика
• Работают ли камера, медиасервис и inference
• Записаны ли событие и медиадоказательство
• Получил ли результат оператор или внешняя система