Архитектура Barfinex — как устроена система

Общая картина

Barfinex построен на одном принципе: каждый этап торгового цикла получает свой сервис, а сервисы взаимодействуют через типизированные, аудируемые контракты.

Результат — система, в которой можно задеплоить новую стратегию без перезапуска потока данных, добавить риск-правило без касания AI-уровня, и заменить терминал без каких-либо изменений в бэкенде. Важнее всего: каждое решение, принятое на каждом этапе, является типизированным событием с полной аудиторской записью — прослеживаемым от сигнала до исполненного ордера.

Поток данных (схема)

Биржа (Binance / Alpaca / …)
        │
        ▼
   [ Provider ]
   • Подключение к бирже (REST + WebSocket)
   • Нормализация рыночных данных: свечи, сделки, стакан
   • Обнаружение пробелов и автоматическое восстановление
   • Единый REST API и WebSocket /ws
   • Единственный источник правды для всех нижестоящих сервисов
        │
        ▼
   [ Шина событий — Redis pub/sub ]
   • Все сервисы публикуют и подписываются через типизированные каналы
   • Имена каналов и структуры данных определены в libs/types
        │
   ┌────┴──────────┬──────────────┬────────────────────┐
   ▼               ▼              ▼                    ▼
[Detector]    [Advisor]     [Inspector]          [Studio /ws]
   │               │              │
   │ сигналы       │ решения      │ события риска
   │               │              │
   └───────────────┴──────────────┘
           все маршрутизируются в Inspector
           Inspector размещает ордера через REST Provider

Роли сервисов

Provider

Provider — фундамент системы. Его задача: принимать сырые рыночные данные с бирж и делать их доступными для всего остального через единый нормализованный API.

• Приём данных — подключается к WebSocket-потокам бирж (сделки, стакан, тикеры) и REST API (свечи, счёт, ордера)
• Агрегация свечей — строит OHLCV-свечи на нескольких таймфреймах из сырых тиковых данных
• Целостность данных — обнаруживает пробелы свечей, запускает задания автоматического восстановления, валидирует стыки, отслеживает здоровье приёма по коннектору
• Реестр приложений — Detector, Advisor и Inspector регистрируются в Provider при старте. Provider проксирует к ним запросы и раскрывает их доступность в Studio.
• Единый шлюз — Studio подключается только к Provider: один URL, один токен авторизации, один WebSocket. Все остальные сервисы доступны через прокси Provider.

Detector

В Detector живёт логика стратегий. Каждый экземпляр Detector — типизированная TypeScript-конфигурация, описывающая, что наблюдать, какие условия оценивать и как взвешивать результат.

• Движок правил — оценивает условия на основе живых данных свечей и потока ордеров на каждой новой свече
• Оценка сигналов — у каждого правила числовой вес; суммарная оценка сравнивается с порогом
• Несколько экземпляров — одновременно работают несколько конфигураций Detector для разных инструментов или рыночных режимов; экземпляры полностью изолированы
• Выход — типизированное событие сигнала: инструмент, направление (long/short), показатель уверенности, идентификатор стратегии, атрибуция правил

Advisor

Advisor — AI-движок принятия решений. Это не опциональный AI-модуль — это структурированный 8-ступенчатый конвейер рассуждений, запускаемый на каждом входящем сигнале.

8 этапов:

1. Получение рыночного контекста через инструменты Provider MCP (цены, позиции, состояние счёта)
2. Шлюз качества рынка — блокировка при оценке качества данных ниже порога
3. Оценка правил и ML-сигналов — независимая оценка сигнала
4. Скоринг уверенности — присвоение числового показателя доверия [0, 1]
5. Калибровка уверенности — логистическая регрессия с режим-адаптивным масштабированием (методы Платта / изотонической регрессии)
6. LLM-синтез — вызов сконфигурированного LLM с полным структурированным контекстом; извлечение направленного уклона, рассуждений и рекомендации по размеру позиции
7. Валидация решения — блокировка при спреде > 0,4% или R/R < 1,2
8. Генерация исполнительного намерения — публикация типизированного события решения с инструкцией исполнения

Каждый этап производит событие телеметрии. От Advisor публикуется более 28 типов событий: снимки уверенности, атрибуция, смена режима, обнаружение галлюцинаций, переключение модели. Все хранятся в журнале аудита временного ряда.

Advisor также раскрывает весь свой API как инструменты Model Context Protocol через Provider, делая его напрямую вызываемым любым LLM, поддерживающим использование инструментов.

Inspector

Inspector — риск-регулятор. Каждое исполнительное намерение от Advisor проходит через Inspector прежде, чем любой ордер достигнет биржи.

• Валидация политик — проверяет лимиты размера позиции, ограничения экспозиции портфеля, пороги просадки, лимиты серий убытков, периоды охлаждения, ограничения по времени суток
• Действия — ALLOW (передать на исполнение), BLOCK (отклонить), THROTTLE (снизить частоту сигналов), STAND_DOWN (приостановить новые входы), CLOSE_ALL (аварийный выход)
• Защитные ордера — выставляет и сопровождает стоп-лосс и тейк-профит для всех runtime-позиций через REST API Provider
• Постторговый аудит — отслеживает проскальзывание, коэффициент исполнения, комиссии и частичные заполнения для каждого исполненного ордера
• Реконсилиация — периодически синхронизирует ожидаемые и фактические позиции для обнаружения расхождений состояния

Inspector различает:

• Runtime-позиции — открытые пока Inspector работает; полный контроль (стопы, трейлинг, закрытие)
• Legacy-позиции — существовавшие до запуска Inspector; только уведомление (Telegram-оповещение)

Studio

Studio — операционный терминал. Next.js-приложение, подключающееся ко всем бэкенд-сервисам исключительно через единый шлюз Provider.

• Живые графики — свечные графики с наложенными сигналами и маркерами позиций
• Временна́я шкала сигналов — история срабатывания правил и атрибуция оценки для каждого сигнала
• Журнал решений Advisor — трассировки рассуждений, показатели уверенности, выход LLM-синтеза
• Риск-дашборд — KPI Inspector, активные позиции, состояние просадки, статус политик
• Эффективность капитала — аналитика утилизации, подавления и резервирования по стратегиям

Studio наблюдает за конвейером — она не исполняет сделки.

Порты по умолчанию

Реестр приложений

Detector, Advisor и Inspector регистрируются в Provider при старте через стандартный поток register + heartbeat. Provider ведёт реестр и проксирует весь внешний трафик к зарегистрированным сервисам.

Это означает, что Studio и API-клиентам никогда не нужен прямой доступ к портам Detector, Advisor или Inspector. Всё маршрутизируется через единый шлюз Provider.

Подробнее о путях API и прокси-маршрутизации — в Справочнике API Provider и Работа с API.