Архитектура Barfinex — экосистема и поток данных

Как устроена платформа Barfinex: от биржи до Studio. Поток данных, роли компонентов и связи между сервисами.

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

Barfinex — модульная экосистема. У каждого компонента своя роль: Provider подключается к биржам, Detector генерирует сигналы, Advisor помогает с решениями, Inspector управляет риском, Studio даёт единый интерфейс. На этой странице — как данные движутся между ними и как мыслить о развёртывании.

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

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

Роли компонентов

Provider

Читает: биржа (REST + WebSocket: тикеры, стакан, сделки, свечи, счёт, ордера).
Пишет в шину: все события слоя данных (сделки, стакан, свечи, счёт, ордера, инструменты, цены).
Дополнительно: REST API для счетов, ордеров, свечей, коннекторов, реестра приложений; прокси к Advisor, Inspector и Detector; WebSocket /ws отдаёт те же события в браузер.

Provider — единая точка входа для фронтенда: один URL, один токен, один WebSocket.

Detector

Читает из шины: рыночные данные и события счёта/ордеров от Provider, события риска от Inspector.
Пишет в шину: торговые сигналы и запросы по позициям (открыть, закрыть, уменьшить, развернуть).
Отдельный сервис: свой процесс/контейнер; подключается к шине и регистрируется в Provider, чтобы Studio обращалась к нему через прокси.

Advisor

Читает из шины: новые сигналы от Detector (и при необходимости запросы на решение).
Пишет в шину: ответы с решением и снимки контекста.
Отдельный сервис: регистрируется в Provider как advisor, чтобы Studio и другие клиенты вызывали его через Provider.

Inspector

Читает из шины: все рыночные и ордерные события от Provider, запросы по позициям от Detector.
Пишет в шину: события риска (превышение лимита, аварийное отключение и т.д.).
Отдельный сервис: исполнение ордеров и стопов через REST API Provider, не через Detector. Регистрируется в Provider как inspector.

Studio (веб-приложение)

Читает только из: Provider. REST через прокси к Advisor/Inspector/Detector; счета, ордера, свечи — из Provider. События в реальном времени — через WebSocket Provider /ws.
Не подключается напрямую к шине и к портам других сервисов при рекомендуемой схеме.

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

Сервис	Порт	Назначение
Provider	8080/8081	REST API, WebSocket, прокси
Advisor	8009	REST API (решения, рекомендации)
Inspector	8008	REST API (дашборд риска, аудит)
Detector	8101	REST API (детектор, метрики)
Шина	6379	Магистраль сообщений (внутри сети)

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

Advisor, Inspector и Detector при старте регистрируются в Provider:

Эндпоинты: регистрация, heartbeat, снятие с учёта.
Итог: Provider знает, куда проксировать запросы, и отображает эти приложения в Studio. Вы работаете с одним базовым URL и ключом appKey для каждого компонента.

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