NATS JetStream - Event Bus

#sympozium #architektura #nats #messaging

Rola w systemie

NATS JetStream pełni rolę centralnego event bus łączącego wszystkie komponenty Sympozium. Jest deployowany jako StatefulSet w namespace sympozium-system.

Dlaczego NATS?

Cecha	Wartość dla Sympozium
Durable pub/sub	Wiadomości nie są tracone przy restartach podów
Replay	Kanały mogą odtworzyć niezrealizowane wiadomości
Lightweight	Minimalne zasoby vs Kafka/RabbitMQ
Cloud-native	Natywne wsparcie K8s
Decoupling	Kanały i agenty nie muszą wiedzieć o sobie

Topologia

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Channel Pods │     │   NATS       │     │  Controller  │
│ (Telegram,   │────►│  JetStream   │◄────│  Manager     │
│  Slack, etc.)│◄────│              │────►│              │
└──────────────┘     │  StatefulSet │     └──────────────┘
                     │  sympozium-  │
┌──────────────┐     │  system      │     ┌──────────────┐
│  IPC Bridge  │────►│              │     │  Schedule    │
│  (sidecars)  │◄────│              │     │  Router      │
└──────────────┘     └──────────────┘     └──────────────┘

Połączenie

Wszystkie komponenty łączą się pod adresem:

nats://nats.sympozium-system.svc:4222

Zmienna środowiskowa: EVENT_BUS_URL

Wzorzec komunikacji

Request/Reply - tool execution (request → sidecar → result)
Pub/Sub - lifecycle events (run.started, run.completed)
Queue Groups - channel messages (load-balanced between consumers)

Dlaczego nie bezpośrednia komunikacja?

Agent pod nie ma dostępu sieciowego (NetworkPolicy deny-all). Jedyny komponent z dostępem do NATS to IPC Bridge sidecar. To zapewnia:

Agent nie może bezpośrednio komunikować się z innymi podami
Całość komunikacji przechodzi przez kontrolowany kanał
Łatwe auditowanie (jeden punkt wejścia/wyjścia)

Powiązane: Przepływ danych i IPC | Control Plane | NetworkPolicy i izolacja sieciowa

2.5 KiB Raw Blame History