refactoring Gateway
This commit is contained in:
+332
@@ -0,0 +1,332 @@
|
||||
### Schlachtplan für das 'infrastructure'-Modul
|
||||
|
||||
Basierend auf der Analyse des aktuellen Zustands (Stand: 11. Oktober 2025) habe ich einen strukturierten Aktionsplan erstellt. Die letzte größere Aktualisierung war im Juli 2025, seitdem gab es signifikante Änderungen am Gateway-Modul.
|
||||
|
||||
---
|
||||
|
||||
### 🔴 Phase 1: SOFORT (Diese Woche)
|
||||
|
||||
#### 1.1 Gateway-Tests reparieren (Höchste Priorität)
|
||||
**Problem:** Tests sind komplett defekt - nur ~47% funktionieren noch (25/53 Tests).
|
||||
|
||||
**Aktionen:**
|
||||
- ❌ **Löschen:** `JwtAuthenticationTests.kt` - testet nicht-existierende Custom-Filter
|
||||
- ✅ **Behalten:** `FallbackControllerTests.kt`, `GatewayApplicationTests.kt`
|
||||
- ✏️ **Überarbeiten:** `GatewayRoutingTests.kt`, `GatewaySecurityTests.kt`, `GatewayFiltersTests.kt`
|
||||
- Option A: Tests mit MockJWT-Tokens ausstatten (siehe `TestSecurityConfig.kt`)
|
||||
- Option B: Tests auf Public Paths verlegen (`/actuator/**`, `/fallback/**`)
|
||||
- Option C: Security in Tests deaktivieren
|
||||
|
||||
**Warum jetzt:** Tests geben keine Sicherheit mehr - blockiert Entwicklung.
|
||||
|
||||
**Zeitaufwand:** 4-6 Stunden
|
||||
|
||||
---
|
||||
|
||||
#### 1.2 Gateway Build-Datei bereinigen
|
||||
**Problem:** Duplizierte Dependency in `gateway/build.gradle.kts` (Zeile 33-34).
|
||||
|
||||
**Aktion:**
|
||||
```kotlin
|
||||
// ENTFERNEN: Zeile 34
|
||||
implementation(project(":infrastructure:event-store:redis-event-store")) // ← Duplikat!
|
||||
```
|
||||
|
||||
**Zeitaufwand:** 5 Minuten
|
||||
|
||||
---
|
||||
|
||||
### 🟡 Phase 2: KURZFRISTIG (Nächste 2 Wochen)
|
||||
|
||||
#### 2.1 Dependency-Versionen aktualisieren
|
||||
**Problem:** Versionen von Juli 2025 - teilweise veraltet.
|
||||
|
||||
**Zu prüfen und aktualisieren:**
|
||||
|
||||
| Dependency | Aktuell | Latest (Okt 2025) | Priorität |
|
||||
|------------|---------|-------------------|-----------|
|
||||
| Spring Boot | 3.5.5 | 3.5.x | Mittel |
|
||||
| Spring Cloud | 2025.0.0 | 2025.0.x | Mittel |
|
||||
| Kotlin | 2.2.20 | 2.2.x | Niedrig |
|
||||
| Keycloak | 26.0.7 | 26.x.x | Hoch |
|
||||
| Testcontainers | 1.21.3 | 1.21.x | Niedrig |
|
||||
| PostgreSQL Driver | 42.7.7 | 42.7.x | Niedrig |
|
||||
|
||||
**Aktion:**
|
||||
1. `gradle/libs.versions.toml` aktualisieren
|
||||
2. Tests nach jedem Update ausführen
|
||||
3. Breaking Changes dokumentieren
|
||||
|
||||
**Zeitaufwand:** 1-2 Tage (mit Testing)
|
||||
|
||||
---
|
||||
|
||||
#### 2.2 Docker-Images aktualisieren
|
||||
**Problem:** Einige Docker-Images sind möglicherweise veraltet.
|
||||
|
||||
**Zu prüfen:**
|
||||
|
||||
```yaml
|
||||
# docker-compose.yml
|
||||
postgres: 16-alpine # ✅ Aktuell (neueste: 16.x)
|
||||
redis: 7-alpine # ✅ Aktuell
|
||||
keycloak: 26.4.0 # ⚠️ Prüfen auf 26.x updates
|
||||
consul: 1.15 # ⚠️ Prüfen (neueste: 1.20+)
|
||||
kafka: 7.4.0 # ⚠️ Prüfen (neueste: 7.8+)
|
||||
prometheus: v2.54.1 # ⚠️ Prüfen
|
||||
grafana: 11.3.0 # ✅ Wahrscheinlich aktuell
|
||||
```
|
||||
|
||||
**Aktion:**
|
||||
1. Versions-Check durchführen
|
||||
2. Schrittweise aktualisieren (einzeln testen!)
|
||||
3. `.env`-Datei mit Versions-Variablen anlegen
|
||||
|
||||
**Zeitaufwand:** 3-4 Stunden
|
||||
|
||||
---
|
||||
|
||||
#### 2.3 Monitoring-Modul vervollständigen
|
||||
**Problem:** Nur 3 Kotlin-Files - deutlich unterimplementiert im Vergleich zur Dokumentation.
|
||||
|
||||
**Dokumentiert aber fehlt:**
|
||||
- Distributed Tracing (Zipkin) - Docker-Container fehlt!
|
||||
- Custom Metrics Implementation
|
||||
- Health Check Aggregation
|
||||
- Alerting Rules Implementation
|
||||
|
||||
**Aktion:**
|
||||
1. Zipkin zu `docker-compose.yml` hinzufügen
|
||||
2. Tracing-Integration in Gateway testen
|
||||
3. Custom Metrics-Library erstellen
|
||||
4. Prometheus Alerting Rules konfigurieren
|
||||
|
||||
**Zeitaufwand:** 2-3 Tage
|
||||
|
||||
---
|
||||
|
||||
### 🟢 Phase 3: MITTELFRISTIG (Nächste 4-6 Wochen)
|
||||
|
||||
#### 3.1 Dokumentation aktualisieren
|
||||
**Problem:** README von Juli 2025 - nicht mehr aktuell.
|
||||
|
||||
**Zu aktualisieren:**
|
||||
|
||||
**`README-INFRASTRUCTURE.md`:**
|
||||
- Zeile 552: "Letzte Aktualisierung: 25. Juli 2025" → Oktober 2025
|
||||
- Security-Sektion: OAuth2 Resource Server statt Custom JWT Filter
|
||||
- Keycloak Version: 23.0 → 26.4.0
|
||||
- Kafka Version: 7.5.0 → 7.4.0 (Downgrade dokumentieren!)
|
||||
- Monitoring: Zipkin-Konfiguration ergänzen
|
||||
|
||||
**Neue Sections hinzufügen:**
|
||||
- #### Bekannte Limitierungen
|
||||
- #### Migration Notes (Juli → Oktober 2025)
|
||||
- #### Troubleshooting erweitern
|
||||
|
||||
**Zeitaufwand:** 1 Tag
|
||||
|
||||
---
|
||||
|
||||
#### 3.2 Auth-Module überarbeiten
|
||||
**Problem:** Vermutlich veraltet - Custom JWT vs. OAuth2 Resource Server Diskrepanz.
|
||||
|
||||
**Zu klären:**
|
||||
- Werden `auth-client` und `auth-server` noch verwendet?
|
||||
- Redundanz mit Gateway's OAuth2 Resource Server?
|
||||
- Keycloak-Integration vereinheitlichen
|
||||
|
||||
**Aktion:**
|
||||
1. Abhängigkeiten zu auth-Modulen analysieren
|
||||
2. Entscheiden: Refactoring oder Deprecation
|
||||
3. Wenn deprecated: Migration Path dokumentieren
|
||||
|
||||
**Zeitaufwand:** 3-5 Tage
|
||||
|
||||
---
|
||||
|
||||
#### 3.3 Cache-Module modernisieren
|
||||
**Problem:** Redis 7 ist aktuell, aber Implementation-Patterns könnten veraltet sein.
|
||||
|
||||
**Zu prüfen:**
|
||||
- Multi-Level Caching tatsächlich implementiert?
|
||||
- Cache Statistics vorhanden?
|
||||
- TTL Management korrekt?
|
||||
- Integration mit Spring Cache Abstraction?
|
||||
|
||||
**Aktion:**
|
||||
1. Cache-Tests erweitern
|
||||
2. Performance-Metriken hinzufügen
|
||||
3. Cache-Warming Strategy implementieren
|
||||
|
||||
**Zeitaufwand:** 2-3 Tage
|
||||
|
||||
---
|
||||
|
||||
#### 3.4 Event-Store Performance-Optimierung
|
||||
**Problem:** Redis-basiert - für Production ggf. nicht optimal.
|
||||
|
||||
**Zu evaluieren:**
|
||||
- Ist Redis der richtige Event Store für Production?
|
||||
- Alternative: PostgreSQL mit Event Store Pattern?
|
||||
- Snapshot-Strategie tatsächlich implementiert?
|
||||
|
||||
**Aktion:**
|
||||
1. Performance-Tests durchführen
|
||||
2. Event Store Benchmark (Redis vs. PostgreSQL)
|
||||
3. Dokumentation aktualisieren mit Pros/Cons
|
||||
|
||||
**Zeitaufwand:** 1 Woche
|
||||
|
||||
---
|
||||
|
||||
### 🔵 Phase 4: LANGFRISTIG (Nächste 2-3 Monate)
|
||||
|
||||
#### 4.1 Service Mesh evaluieren
|
||||
**Dokumentiert in "Zukünftige Erweiterungen"** - noch nicht implementiert.
|
||||
|
||||
**Optionen:**
|
||||
- Istio (komplex, feature-reich)
|
||||
- Linkerd (leichtgewichtig)
|
||||
- Consul Connect (bereits Consul vorhanden!)
|
||||
|
||||
**Empfehlung:** Start mit Consul Connect - minimaler Overhead.
|
||||
|
||||
**Zeitaufwand:** 2-3 Wochen
|
||||
|
||||
---
|
||||
|
||||
#### 4.2 OpenTelemetry statt Zipkin
|
||||
**Problem:** Zipkin ist veraltet - OpenTelemetry ist der moderne Standard.
|
||||
|
||||
**Migration Path:**
|
||||
1. OpenTelemetry Collector aufsetzen
|
||||
2. Spring Boot Auto-Instrumentation aktivieren
|
||||
3. Zipkin als Backend behalten (kompatibel!)
|
||||
4. Schrittweise migrieren
|
||||
|
||||
**Zeitaufwand:** 1-2 Wochen
|
||||
|
||||
---
|
||||
|
||||
#### 4.3 Security Hardening
|
||||
**Aktuelle Gaps:**
|
||||
- JWT Token Rotation nicht implementiert
|
||||
- Rate Limiting nur dokumentiert, nicht konfiguriert
|
||||
- Audit Logging fehlt
|
||||
- HTTPS/TLS noch nicht erzwungen
|
||||
|
||||
**Aktion:**
|
||||
1. Rate Limiting im Gateway aktivieren
|
||||
2. Audit Log Framework implementieren
|
||||
3. TLS für Service-zu-Service Kommunikation
|
||||
4. Security Scan mit OWASP Dependency Check
|
||||
|
||||
**Zeitaufwand:** 2-3 Wochen
|
||||
|
||||
---
|
||||
|
||||
#### 4.4 Infrastructure as Code (IaC)
|
||||
**Problem:** Nur Docker Compose - für Production nicht ausreichend.
|
||||
|
||||
**Zu erstellen:**
|
||||
- Kubernetes Manifests (aktualisieren - Zeile 393+)
|
||||
- Helm Charts (aktualisieren - Zeile 420+)
|
||||
- Terraform für Cloud-Ressourcen
|
||||
- CI/CD Pipelines
|
||||
|
||||
**Zeitaufwand:** 4-6 Wochen
|
||||
|
||||
---
|
||||
|
||||
### 📊 Priorisierungs-Matrix
|
||||
|
||||
| Phase | Aufgabe | Dringlichkeit | Aufwand | Impact |
|
||||
|-------|---------|---------------|---------|--------|
|
||||
| 1 | Gateway-Tests | 🔴 Sehr hoch | 4-6h | Hoch |
|
||||
| 1 | Build-Datei | 🔴 Sehr hoch | 5min | Niedrig |
|
||||
| 2 | Dependencies | 🟡 Hoch | 1-2d | Mittel |
|
||||
| 2 | Docker-Images | 🟡 Hoch | 3-4h | Mittel |
|
||||
| 2 | Monitoring | 🟡 Mittel | 2-3d | Hoch |
|
||||
| 3 | Dokumentation | 🟢 Mittel | 1d | Mittel |
|
||||
| 3 | Auth-Module | 🟢 Mittel | 3-5d | Hoch |
|
||||
| 3 | Cache | 🟢 Niedrig | 2-3d | Mittel |
|
||||
| 3 | Event-Store | 🟢 Niedrig | 1w | Mittel |
|
||||
| 4 | Service Mesh | 🔵 Niedrig | 2-3w | Hoch |
|
||||
| 4 | OpenTelemetry | 🔵 Niedrig | 1-2w | Mittel |
|
||||
| 4 | Security | 🔵 Mittel | 2-3w | Hoch |
|
||||
| 4 | IaC | 🔵 Niedrig | 4-6w | Hoch |
|
||||
|
||||
---
|
||||
|
||||
### 🎯 Empfohlene Reihenfolge
|
||||
|
||||
#### Woche 1-2:
|
||||
1. Gateway-Tests reparieren
|
||||
2. Build-Datei bereinigen
|
||||
3. Dependencies aktualisieren
|
||||
|
||||
#### Woche 3-4:
|
||||
4. Docker-Images aktualisieren
|
||||
5. Monitoring vervollständigen
|
||||
6. Dokumentation aktualisieren
|
||||
|
||||
#### Woche 5-8:
|
||||
7. Auth-Module evaluieren/refactoren
|
||||
8. Cache-Module modernisieren
|
||||
9. Event-Store Performance-Tests
|
||||
|
||||
#### Monat 3-4:
|
||||
10. Security Hardening
|
||||
11. OpenTelemetry Migration
|
||||
12. Service Mesh Evaluation
|
||||
|
||||
#### Monat 5-6:
|
||||
13. Infrastructure as Code
|
||||
14. Production Readiness Assessment
|
||||
|
||||
---
|
||||
|
||||
### 🛠️ Tooling-Empfehlungen
|
||||
|
||||
**Für Dependency-Management:**
|
||||
- Renovate Bot oder Dependabot für automatische Updates
|
||||
- `./gradlew dependencyUpdates` Plugin verwenden
|
||||
|
||||
**Für Security:**
|
||||
- OWASP Dependency Check
|
||||
- Trivy für Container-Scanning
|
||||
- SonarQube für Code-Qualität
|
||||
|
||||
**Für Monitoring:**
|
||||
- Grafana Dashboards aus Community importieren
|
||||
- Prometheus Alertmanager konfigurieren
|
||||
|
||||
---
|
||||
|
||||
### 📝 Nächste Schritte
|
||||
|
||||
1. **Jetzt sofort:** Gateway-Tests fixen (blockiert alles andere)
|
||||
2. **Diese Woche:** Dependencies updaten und testen
|
||||
3. **Nächste Woche:** Sprint Planning für Phase 2
|
||||
4. **Monatlich:** Review des Fortschritts und Reprioritisierung
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Risiken & Abhängigkeiten
|
||||
|
||||
**Kritische Pfade:**
|
||||
- Gateway-Tests müssen ZUERST behoben werden
|
||||
- Dependency-Updates können Breaking Changes haben
|
||||
- Auth-Refactoring könnte alle Services betreffen
|
||||
|
||||
**Externe Abhängigkeiten:**
|
||||
- Keycloak Breaking Changes bei Major Updates
|
||||
- Spring Boot/Cloud Release Schedule beachten
|
||||
- Kubernetes Cluster für IaC-Phase benötigt
|
||||
|
||||
---
|
||||
|
||||
**Geschätzter Gesamtaufwand:** 6-8 Wochen (bei 1 Vollzeit-Entwickler)
|
||||
|
||||
**Empfohlener Start:** Sofort mit Phase 1, dann iterativ durch die Phasen
|
||||
Reference in New Issue
Block a user