trade/trade-frontend
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
a674d40453e10e5c1ca93f70b047f7776c8a0454
trade-frontend/doc/mevnode-bot-architecture.md

246 lines
7.4 KiB
Markdown
Raw Blame History

# Mevnode Bot Architecture
## Zasada glowna
`mevnode_bot` nigdy nie uruchamia warstwy Solana node:
- bez `agave`
- bez `ledger`
- bez `yellowstone server`
- bez validator stack
`mevnode_sol` pozostaje jedynym hostem node-level:
- `agave-validator`
- `yellowstone geyser plugin`
- `yellowstone gRPC`
- plugin metrics
- lokalny RPC
- opcjonalnie pozniej RPC proxy
## Schemat `mevnode_bot`
```text
+--------------------------------------------------------------+
| mevnode_bot |
| single-node k3s only |
| |
| ingress/web |
| - frontend |
| - api |
| |
| trading/read |
| - yellowstone-consumer |
| - market ingest / parser |
| - dlob-worker |
| |
| trading/core |
| - strategy-engine |
| - risk-manager |
| - order-manager |
| - tx-router |
| |
| tx paths |
| - tpu client |
| - jito client |
| - rpc client / later rpc proxy target on mevnode_sol |
| |
| data |
| - postgres |
| - redis optional |
| - clickhouse later optional |
| |
| ops |
| - prometheus |
| - grafana |
| - loki optional |
| |
| platform |
| - argo/flux |
| - sealed-secrets or sops |
| - internal registry access |
+--------------------------------------------------------------+
```
## Przeplyw danych
```text
Yellowstone on mevnode_sol
|
v
yellowstone-consumer
|
v
parser / ingest / dlob-worker
|
v
strategy-engine
|
v
risk-manager / order-manager
|
v
tx-router
| | |
v v v
TPU Jito RPC
```
## Namespace plan
- `web`
- `trade`
- `data`
- `ops`
- `infra`
## Kolejnosc wdrozenia
1. `web`: `frontend`, `api`
2. `data`: `postgres`
3. `trade`: `yellowstone-consumer`
4. `trade`: `strategy-engine`, `tx-router`
5. `ops`: `prometheus`, `grafana`
## Read i write path
Read path:
- `mevnode_bot -> wg0 -> mevnode_sol:10000`
Metrics path:
- `mevnode_bot -> wg0 -> mevnode_sol:8999`
Write path pozniej:
- `mevnode_bot -> TPU/Jito`
- albo `mevnode_bot -> RPC proxy -> mevnode_sol:127.0.0.1:8899`
## Zasada architektoniczna
- `mevnode_sol` = source of truth dla chain access
- `mevnode_bot` = execution and product node
## K3s object map
### Namespace `web`
- `Deployment` `frontend`
- `Service` `frontend` typu `ClusterIP`
- `Deployment` `api`
- `Service` `api` typu `ClusterIP`
- `Ingress` `web`
Przeznaczenie:
- `frontend` wystawia UI
- `api` wystawia backend HTTP
- `Ingress` publikuje tylko web entrypoint
### Namespace `trade`
- `Deployment` `yellowstone-consumer`
- `Deployment` `dlob-worker`
- `Deployment` `strategy-engine`
- `Deployment` `risk-manager`
- `Deployment` `order-manager`
- `Deployment` `tx-router`
- `Service` `strategy-engine` typu `ClusterIP` jesli inne komponenty maja sie do niego odwolywac
- `Service` `tx-router` typu `ClusterIP` tylko jesli potrzebne bedzie sterowanie po HTTP/gRPC
Przeznaczenie:
- `yellowstone-consumer` czyta stream z `mevnode_sol`
- `dlob-worker` robi ingest i przygotowanie danych
- `strategy-engine` podejmuje decyzje
- `risk-manager` egzekwuje limity
- `order-manager` sklada i nadzoruje lifecycle zlecen
- `tx-router` wybiera `TPU`, `Jito` albo `RPC`
Uwagi:
- `strategy-engine`, `order-manager` i `tx-router` mozna uruchamiac z `hostNetwork: true`, jesli bedzie potrzeba minimalizacji narzutu sieciowego
- `yellowstone-consumer` powinien miec `Secret` z `x-token` i endpointem `10.91.0.1:10000`
### Namespace `data`
- `StatefulSet` `postgres`
- `Service` `postgres` typu `ClusterIP`
- `PersistentVolumeClaim` dla `postgres`
- `StatefulSet` `redis` opcjonalnie
- `Service` `redis` typu `ClusterIP`
- `PersistentVolumeClaim` dla `redis` tylko jesli ma byc trwaly cache
- `StatefulSet` `clickhouse` dopiero pozniej
- `Service` `clickhouse` typu `ClusterIP`
- `PersistentVolumeClaim` dla `clickhouse`
Przeznaczenie:
- `postgres` dla stanu systemu, pozycji, filli, konfiguracji i jobow
- `redis` dla cache, kolejek, lockow i rate limitu
- `clickhouse` dla ciezszej analityki i archiwizacji eventow
### Namespace `ops`
- `StatefulSet` `prometheus`
- `Service` `prometheus` typu `ClusterIP`
- `Deployment` `grafana`
- `Service` `grafana` typu `ClusterIP`
- `Deployment` `promtail` opcjonalnie
- `StatefulSet` albo `Deployment` `loki` opcjonalnie
Przeznaczenie:
- `prometheus` zbiera metryki z `k3s` i z aplikacji
- `grafana` daje dashboardy
- `loki/promtail` sa opcjonalne do logow
### Namespace `infra`
- `Deployment` `argocd-server` albo kontrolery `flux`
- `Deployment` `argocd-repo-server` jesli wybierzemy `Argo CD`
- `Deployment` `sealed-secrets-controller` albo integracja `sops`
- `Secret` / `ExternalSecret` dla tokenow i kluczy
Przeznaczenie:
- GitOps sync z Gitea
- zarzadzanie sekretami
- bootstrap aplikacji i manifestow
## Service exposure rules
- tylko `frontend` i `api` wychodza przez `Ingress`
- `postgres`, `redis`, `clickhouse`, `strategy-engine`, `tx-router` zostaja wewnetrzne jako `ClusterIP`
- bez `LoadBalancer`
- bez publicznego wystawiania komponentow tradingowych
- `yellowstone-consumer` nie potrzebuje publicznego `Service`
## Storage rules
- `postgres` na trwałym wolumenie
- `clickhouse` tylko na szybkim lokalnym storage
- `redis` bez PVC jesli ma byc tylko cache
- aplikacje tradingowe jako stateless `Deployment`, jesli stan trzymamy w `postgres`
## Config and secrets
- `ConfigMap` dla endpointow, feature flags i runtime config
- `Secret` dla:
- tokenu Yellowstone
- kluczy API
- danych do `postgres`
- danych do `Jito`
- kluczy signing/delegate
## Kolejnosc wdrozenia w k3s
1. `infra`: GitOps i secrets
2. `data`: `postgres`
3. `web`: `frontend`, `api`, `Ingress`
4. `trade`: `yellowstone-consumer`
5. `trade`: `strategy-engine`, `risk-manager`, `order-manager`
6. `trade`: `tx-router`
7. `ops`: `prometheus`, `grafana`
Reference in New Issue View Git Blame Copy Permalink