Service Discovery: Wie sich Services in dynamischen Umgebungen finden

In dynamischen containerisierten Umgebungen ändern sich IP-Adressen und Ports ständig. Service Discovery löst das fundamentale Problem — wie Services einander finden.

Warum statische Konfiguration nicht ausreicht¶

In einer traditionellen Umgebung reicht eine Konfigurationsdatei mit Service-IP-Adressen aus. In einer containerisierten Umgebung funktioniert das nicht mehr — Container werden dynamisch erstellt und zerstört, IP-Adressen ändern sich, und Services skalieren horizontal.

Service Discovery registriert Services automatisch beim Start und deregistriert sie beim Herunterfahren. Clients fragen die Registry statt hartcodierte Adressen ab.

Client-Side vs. Server-Side Discovery¶

Zwei grundlegende Ansätze:

Client-Side Discovery — der Client fragt die Registry ab und wählt eine Instanz:

• Der Client kontrolliert die Load-Balancing-Strategie
• Direkte Kommunikation ohne Vermittler
• Netflix Eureka + Ribbon ist ein typisches Beispiel

Server-Side Discovery — der Client ruft einen Load Balancer auf, der das Routing übernimmt:

• Einfacher für Clients
• Zentraler Punkt für Monitoring
• AWS ELB, Kubernetes Service sind Beispiele

Kubernetes verwendet Server-Side Discovery mit kube-dns für DNS-basierte Auflösung.

Consul, etcd und ZooKeeper¶

Drei populäre Tools für Service Discovery:

• Consul (HashiCorp) — Service Discovery + Health Checking + KV-Store + Multi-Datacenter. Die vollständigste Lösung.
• etcd (CoreOS) — verteilter KV-Store, die Grundlage von Kubernetes. Einfach und zuverlässig.
• ZooKeeper (Apache) — der Veteran, umfassend, aber höhere Betriebskosten.

Consul bietet ein DNS-Interface — Services sind als service-name.service.consul erreichbar, was die Integration vereinfacht.

Health Checking und Resilienz¶

Service Discovery ohne Health Checking ist gefährlich — Clients können an nicht funktionierende Instanzen geroutet werden.

Consul unterstützt:

• HTTP Health Checks
• TCP-Port-Checks
• Skript-basierte Checks
• TTL-basierte Heartbeats

Die Kombination von Service Discovery mit dem Circuit-Breaker-Pattern (Hystrix) stellt sicher, dass der Ausfall eines Services keinen kaskadierenden Ausfall des gesamten Systems verursacht.

Fazit: Ein Fundament der Microservices-Infrastruktur¶

Service Discovery ist ein wesentlicher Baustein für Microservices-Architektur. Wir empfehlen Consul als Standardwahl dank seiner vollständigen Feature-Palette. In einer Kubernetes-Umgebung ist Discovery eingebaut — aber das Verständnis der zugrunde liegenden Prinzipien ist auch dort wichtig.