Wie baust du Microservices mit Spring Boot: Konfiguration, Discovery, Resilienz?

Question

IT Interview Practice · Accepted Answer

Spring Boot plus Spring Cloud gibt dir die Bausteine für Microservices. Die drei Probleme, die jedes verteilte System lösen muss, sind **zentralisierte Konfiguration**, **Service Discovery** und **Resilienz** gegen Teilausfälle. ## Die beweglichen Teile ```text ┌── Config Server (git-backed properties) │ Client ──▶ API Gateway ──▶ Service A ──▶ Service B │ │ │ └──▶ Discovery (Eureka / K8s DNS) ◀── register + look up ``` - **Config Server** liefert die Properties jedes Dienstes aus einem zentralen Git-Repo, sodass du die Konfiguration änderst, ohne neu zu deployen. Dienste ziehen sie beim Start (und aktualisieren via `/actuator/refresh`). - **Service Discovery** (Eureka, Consul oder Kubernetes DNS) lässt Dienst A Dienst B über den *Namen* finden statt über einen fest codierten Host, sodass Instanzen frei skalieren und wandern können. - **API Gateway** (Spring Cloud Gateway) ist der einzige Einstiegspunkt für Routing, Auth und Rate Limiting. ## Resilienz – der Teil, den Junioren überspringen In einem verteilten System *wird* jeder Netzwerkaufruf irgendwann fehlschlagen. Verwende Resilience4j, um zu verhindern, dass ein langsamer Dienst in einen Ausfall kaskadiert: ```java @CircuitBreaker(name = "inventory", fallbackMethod = "cachedStock") @Retry(name = "inventory") // retry transient blips @TimeLimiter(name = "inventory") // cap the wait public CompletableFuture stock(String sku) { return inventoryClient.get(sku); // remote call } // Called when the circuit is open or the call fails — degrade gracefully. public CompletableFuture cachedStock(String sku, Throwable ex) { return CompletableFuture.completedFuture(Stock.unknown(sku)); } ``` Der **Circuit Breaker** schaltet nach wiederholten Fehlern auf offen, sodass Aufrufe schnell fehlschlagen, statt sich als Threads aufzustauen, die auf eine tote Abhängigkeit warten. ## Warum es wichtig ist Senior-Interviews prüfen die Reife im Umgang mit verteilten Systemen. Discovery und Config zu benennen, ist Grundvoraussetzung; der Unterschied liegt darin, über **Fehler** zu sprechen: Circuit Breaker, Timeouts, Idempotenz und Observability (Distributed Tracing mit Micrometer/Zipkin). Starke Kandidaten widersprechen auch – und merken an, dass Microservices operativen Aufwand hinzufügen und ein Monolith oft die richtige Wahl ist, bis der Maßstab etwas anderes verlangt.

Die beweglichen Teile

Resilienz – der Teil, den Junioren überspringen

Warum es wichtig ist

Ähnliche Fragen