Service Discovery
Service Discovery löst einen stabilen Dienstnamen zur Laufzeit in eine Menge erreichbarer Endpunkte auf.
- DienstnameBleibt stabil, während Instanzen wechseln.
- EndpunktmengeEnthält aktuell bekannte Kandidaten samt Gesundheitsstatus.
- Stale-FensterBegrenzt die Wahl bereits ausgefallener Ziele.
Einordnung
Warum das wichtig ist
Discovery meldet bekannte Endpunkte; tatsächliche Erreichbarkeit und erfolgreiche Fachantwort bleiben Aufgaben von Client, Load Balancer und Anwendung.
Die verteilte Ausbaustufe im Shop-Szenario ist hypothetisch; der aktuelle Shop bleibt ein modularer Monolith mit sieben Modulen und gemeinsamer Datenbank.
Service Discovery: Entscheidungsgrenzen
Der aktuelle Shop hat sieben Module in einem Prozess. Hypothetisch läuft Versand auf drei wechselnden Instanzen hinter dem logischen Namen versand. Die Plattform veröffentlicht Endpointänderungen und entfernt eine fehlerhafte Instanz nach der Gesundheitsregel. Das Team beendet eine Instanz während laufender Anfragen und misst Zeit bis zur Entfernung, Fehlversuche aus Caches und Verhalten bei Ausfall des Discovery-Dienstes. Erst eine begrenzte Stale-Phase und erfolgreiche Neuauflösung tragen die Zusage.
So liest du das Bild
- Dienstname Logische Adresse
- Endpunktmenge Versionierte Aktualisierung
- Stale-Fenster TTL plus Deregistrierung
| Vergleich | Aspekt | Tragfähiger Einsatz | Grenze |
|---|---|---|---|
| DNS-basiert | Breit unterstützt und einfach | TTL begrenzt Aktualität | Clientcache kann alte Ziele halten |
| Registry/API | Schnelle Endpunktupdates | Watch oder Abfrage | Registryausfall braucht Cachepfad |
| Plattform-Service | Discovery plus Load Balancing | Plattform verwaltet Endpunkte | Plattformsemantik bestimmt Health und Routing |
Nutzen & Grenzen
Hilft, wenn
- TTL begrenzt Aktualität
- Watch oder Abfrage
- Plattform verwaltet Endpunkte
Grenzen
- Clientcache kann alte Ziele halten
- Registryausfall braucht Cachepfad
- Plattformsemantik bestimmt Health und Routing
In der Praxis
- Starte und beende Versandinstanzen während laufender Bestellabfragen. Prüfe, wie schnell Discovery den aktuellen Endpunktbestand veröffentlicht.
- Lass einen registrierten Endpunkt nicht mehr antworten. Verifiziere, dass Gesundheitsprüfung oder Clientstrategie ihn nicht dauerhaft als gesund auswählt.
- Bewerte DNS-basierte gegen API-basierte Discovery anhand Cachezeit, Ausfallsignal und Plattformabhängigkeit. Halte die gewählte Aktualitätszusage messbar fest.
Ausführliche Erklärung lesen
Instanzen registrieren sich oder werden von der Plattform beobachtet. DNS, Registry oder Endpoint-API liefert Kandidaten, aus denen Client oder Proxy ein Ziel wählt.
TTL, Health-Check-Intervall und Deregistrierungszeit bestimmen, wie lange ein ausgefallenes Ziel noch gewählt werden kann. Caches brauchen eine definierte Reaktion, wenn die Discovery selbst ausfällt.
Load Balancing wählt aus den gefundenen Zielen. Service Mesh kann Discovery konsumieren und die Weiterleitung übernehmen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was ist die Kernaufgabe von Service Discovery?
Lösung mit Begründung ansehen
Service Discovery löst einen stabilen Dienstnamen zur Laufzeit in eine Menge erreichbarer Endpunkte auf.
AnwendenAuf eine neue Lage übertragen
Welche Annahme ist im Shop hypothetisch?
Lösung mit Begründung ansehen
Hypothetisch läuft Versand auf drei wechselnden Instanzen hinter dem logischen Namen versand. Die Plattform veröffentlicht Endpointänderungen und entfernt eine fehlerhafte Instanz nach der Gesundheitsregel.
BewertenEine Alternative abwägen
Welche drei Punkte müssen vor einer Einführung belegt sein?
Lösung mit Begründung ansehen
Dienstname, Endpunktmenge, Stale-Fenster.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.