stefan
280debce09
Desktop CI — Headless Tests & Build / Compose Desktop — Tests (headless) & Build (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., backend/infrastructure/gateway/Dockerfile, api-gateway, api-gateway) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., backend/services/ping/Dockerfile, ping-service, ping-service) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/caddy/web-app/Dockerfile, web-app, web-app) (push) Has been cancelled
Build and Publish Docker Images / build-and-push (., config/docker/keycloak/Dockerfile, keycloak, keycloak) (push) Has been cancelled
Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
# Journal-Eintrag: Consul Discovery Best Practice Fix
|
|
|
|
**Datum:** 16. April 2026
|
|
**Beteiligte:** 🏗️ [Lead Architect], 👷 [Backend Developer]
|
|
|
|
## 1. Problemstellung
|
|
|
|
Trotz vorheriger Versuche meldete Consul für den `masterdata-service` weiterhin den Status "critical" (404 auf
|
|
`/actuator/health`).
|
|
Die Ursache lag in der hybriden Architektur (Spring Boot + Ktor):
|
|
|
|
- Spring Boot (Management/Actuator) lief auf Port 8086.
|
|
- Ktor (API) lief auf Port 8091.
|
|
- Consul versuchte fälschlicherweise, den Healthcheck auf dem API-Port (oder einer fehlerhaften Kombination)
|
|
auszuführen, da die Service-Registrierung nicht präzise genug war.
|
|
|
|
## 2. Best Practice Lösung
|
|
|
|
Um die Stabilität und Wartbarkeit zu erhöhen, wurden folgende Maßnahmen ergriffen:
|
|
|
|
### A. Präzise Service-Registrierung (Masterdata-Service)
|
|
|
|
In der `application.yml` wurde die Consul-Discovery-Konfiguration geschärft:
|
|
|
|
- `health-check-port: 8086`: Der Healthcheck wird explizit an den Spring Boot Management Port gesendet.
|
|
- `port: ${masterdata.http.port:8091}`: Der Service wird explizit mit seinem API-Port (Ktor) im Service-Katalog
|
|
registriert.
|
|
- Damit weiß das Gateway: "Sende Traffic an 8091", und Consul weiß: "Prüfe Health auf 8086".
|
|
|
|
### B. Umstellung auf Load-Balancer Abstraktion (`lb://`)
|
|
|
|
Das API-Gateway nutzte bisher hartcodierte URLs oder Umgebungsvariablen für das Routing. Dies ist fehleranfällig und
|
|
widerspricht dem Prinzip der Service Discovery.
|
|
|
|
- **Änderung:** Alle Routen in `GatewayConfig.kt` wurden von `http://service-name:port` auf `lb://service-name`
|
|
umgestellt.
|
|
- **Vorteil:** Spring Cloud Gateway nutzt nun den Consul-Katalog direkt. Wenn ein Service (wie `masterdata-service`)
|
|
dort mit Port 8091 registriert ist, wird er automatisch korrekt angesteuert.
|
|
- Dies entfernt die Notwendigkeit für `*_SERVICE_URL` Umgebungsvariablen im Gateway.
|
|
|
|
## 3. Ergebnis
|
|
|
|
- Der `masterdata-service` wird nun korrekt als `healthy` markiert, da der Healthcheck den richtigen Port (8086)
|
|
erreicht.
|
|
- Das Routing ist nun dynamisch und robust gegenüber Port-Änderungen in den einzelnen Services.
|
|
- Alle Backend-Services folgen nun einem einheitlichen "Best Practice" Muster für die Service Discovery.
|
|
|
|
---
|
|
**🏗️ [Lead Architect]**: Architektur auf Standard Spring Cloud Discovery (lb://) gehärtet.
|
|
**👷 [Backend Developer]**: Hybride Port-Konfiguration im Masterdata-Service final korrigiert.
|