Files
obsidian-sympozium/02-Architektura/NATS JetStream - Event Bus.md
2026-03-25 00:05:57 +01:00

60 lines
2.5 KiB
Markdown

# 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
1. **Request/Reply** - tool execution (request → sidecar → result)
2. **Pub/Sub** - lifecycle events (run.started, run.completed)
3. **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]]