Barfinex как операционная система: пятисервисная архитектура

Принцип проектирования

Торговая система, которая падает из-за зависшего компонента — это не актив, а обязательство. Система, где деплой новой стратегии требует перезапуска конвейера данных — хрупкая. Система, в которой нельзя проследить причину сделки в 3 часа ночи — неприемлема в production.

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

Это означает: можно обновить логику стратегии Detector, не затрагивая поток данных Provider. Можно скорректировать риск-политики Inspector без перезапуска Advisor. Можно проследить любой исполненный ордер до породившего его сигнала, одобрившего его AI-рассуждения и валидировавшей его риск-проверки.

Пять сервисов в деталях

Provider (порт 8081) — Фундамент

Provider — единственный источник правды для всех рыночных данных в системе. Ни один другой сервис не подключается к бирже напрямую. Всё идёт через Provider.

Что делает Provider:

Подключается к WebSocket-потокам и REST API бирж (Binance, Alpaca, другие через плагины коннекторов)
Нормализует сырые тиковые данные в OHLCV-свечи на нескольких таймфреймах
Обнаруживает и восстанавливает пробелы свечей — определяет недостающие временны́е диапазоны, получает из исторического API, валидирует заполненные стыки
Отслеживает здоровье приёма по каждому коннектору; предоставляет более 25 эндпоинтов отладки и аудита специально для верификации целостности данных
Ведёт реестр всех работающих сервисов (экземпляры Detector, Advisor, Inspector). Другие сервисы регистрируются в Provider при старте и отправляют периодические heartbeat. Provider проксирует весь внешний трафик к зарегистрированным сервисам.
Раскрывает единый REST API и WebSocket /ws — единственная точка подключения, нужная Studio

Практический эффект: один URL, один токен авторизации, один WebSocket. Studio и любые внешние клиенты общаются только с Provider. Остальная система снаружи не видна.

Detector (порт 8101) — Движок стратегий

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

Ключевые характеристики:

Движок правил — оценивает каждое условие правила на основе данных свечей и потока ордеров от Provider в реальном времени на каждой новой свече
Оценённый выход — у каждого правила числовой вес; сигналы генерируются только когда суммарная оценка превышает сконфигурированный порог
Полная атрибуция — событие сигнала содержит полную запись о том, какие правила сработали, какие — нет, и что каждое внесло в оценку
Изоляция экземпляров — несколько конфигураций Detector работают одновременно без разделения состояния. Ошибка в одном не влияет на другие.
Несколько стратегий параллельно — разные стратегии для разных инструментов, рыночных режимов, или A/B-тестирование разных весов правил на одном инструменте

Advisor (порт 8009) — AI-движок принятия решений

Advisor — AI-движок принятия решений. Это уровень, отличающий Barfinex от чисто правиловой системы.

Advisor запускает структурированный 8-ступенчатый конвейер на каждом входящем сигнале от любого экземпляра Detector:

Рыночный контекст — получает текущие цены, позиции и состояние счёта через инструменты Provider MCP
Шлюз качества рынка — оценивает свежесть данных, стабильность спреда и ликвидность; блокирует при значении ниже порога
Независимая оценка сигнала — применяет собственный уровень правил и ML-скоринга отдельно от оценки Detector
Скоринг уверенности — объединяет в нормализованный [0, 1] показатель уверенности
Калибровка уверенности — применяет логистическую регрессию с режим-адаптивным масштабированием (методы Платта и изотонической регрессии); учитывает историческое распределение результатов по разным рыночным режимам
LLM-синтез — отправляет структурированный объект контекста в сконфигурированный LLM; получает направленный уклон, текст рассуждений и рекомендации по размеру; программно валидирует выход; генерирует событие обнаружения галлюцинации при несогласованности
Валидация решения — блокирует при спреде > 0,4% или R/R < 1,2
Исполнительное намерение — генерирует типизированное событие, на которое подписывается Inspector

Более 28 различных типов событий телеметрируются из конвейера Advisor, хранятся в журнале аудита временного ряда и видны в Studio.

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

Inspector (порт 8008) — Риск-регулятор

Inspector — шлюз между решением и исполнением. Ни один ордер не достигает биржи без явного одобрения Inspector.

Для каждого исполнительного намерения от Advisor Inspector оценивает:

Размер позиции по сконфигурированным лимитам
Суммарную экспозицию портфеля по ограничениям
Просадку сессии по порогам
Последовательные убытки по лимитам
Периоды охлаждения и временны́е ограничения

Доступные ответы: ALLOW, BLOCK, THROTTLE, STAND_DOWN, CLOSE_ALL.

Помимо валидации политик, Inspector управляет полным жизненным циклом защитных ордеров для каждой открытой позиции: выставляет стоп-лосс и тейк-профит сразу после заполнения, корректирует по мере движения цены, отменяет при закрытии позиции. Также отслеживает проскальзывание, коэффициент заполнения и задержку исполнения для каждой сделки и запускает периодическую реконсилиацию с фактическим состоянием счёта на бирже.

Studio (BFF порт 8010) — Операционный терминал

Studio — терминальный UI на Next.js. Подключается исключительно через единый шлюз Provider — нет прямых подключений к портам Detector, Advisor или Inspector.

Что отображает Studio:

Живые свечные графики с наложениями сигналов и маркерами позиций
История срабатывания правил для каждого сигнала с атрибуцией оценки
Журнал решений Advisor: трассировки рассуждений, показатели уверенности, состояние калибровки, события блокировки
Риск-дашборд Inspector: активные позиции, KPI, состояние просадки, журнал аудита
Метрики эффективности капитала: аналитика утилизации, подавления и резервирования

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

Шина событий

Сервисы взаимодействуют асинхронно через Redis pub/sub. Все имена каналов и структуры данных определены в общем TypeScript-пакете libs/types. Если имя канала или структура данных меняются, компилятор TypeScript обнаруживает это до попадания в production.

Этот типизированный контрактный уровень позволяет сервисам развёртываться, обновляться или заменяться независимо без сбоев координации.

Сквозной поток данных

Биржа
  → Provider (приём, нормализация, публикация в шину)
      → Detector (подписка на свечи, оценка правил, генерация сигнала)
          → Advisor (подписка на сигнал, 8-ступенчатый AI-конвейер, исполнительное намерение)
              → Inspector (подписка на намерение, валидация политик, размещение ордера через Provider)
                  → Биржа (ордер размещён)

Все этапы → шина событий → Studio (наблюдение за всем в реальном времени)

Каждая стрелка в этой схеме — типизированное событие с временно́й меткой, схемой данных и аудиторской записью. Ничто в системе не взаимодействует через недокументированные побочные каналы.

Развёртывание

Весь стек запускается локально одной командой docker-compose up. Каждый сервис также может быть развёрнут на отдельной инфраструктуре по мере роста требований. Единственное жёсткое ограничение маршрутизации: каждый сервис, которому нужны рыночные данные, должен иметь доступ к Provider. Все остальные сервисы можно организовать произвольно.

В следующей статье мы разбираем движок правил Detector — как выразить торговую стратегию как типизированную конфигурацию и что вы получаете в части наблюдаемости по умолчанию.