NYSSR.NET / RESOURCES

Dienste ohne zentrale Registry finden

Wie redundante nyssr.net-Registries Service Discovery und Load Balancing bieten, ohne dass eine zentrale Registry zum Single Point of Failure wird.

Wenn sich Dienstorte ändern, weil Knoten hinzukommen, wegfallen oder getrennt werden, werden hartcodierte Endpunkte und eine einzelne Registry zum operativen Risiko. nyssr.net macht Discovery Teil der verteilten Runtime.

Automatische Service Discovery und Load Balancing sind Kernfunktionen von nyssr.net. Die Microservice-Registry stellt beides bereit, darf aber nicht zum Single Point of Failure des Netzes werden.

Redundanz von Anfang an

Mehrere Registry-Instanzen können auf verschiedenen Knoten laufen. Wenn sich ein Microservice registriert oder abmeldet, teilen die Registry-Instanzen die Aktualisierung untereinander. Eine neu hinzugefügte Registry synchronisiert ihre Einträge, bevor sie Requests beantwortet.

Registries senden beim Start ihre Präsenz als Broadcast. Neue Knoten lernen verfügbare Registries automatisch kennen, wenn sie dem Netz beitreten.

Kernidee: Discovery bleibt verfügbar, weil der Discovery-Dienst selbst verteilt ist.

Lokale Helfer wählen eine Registry

Jeder Knoten kann ein lokales Helfer-Plugin bereitstellen. Es verfolgt die aktuell verfügbaren Registries und hilft lokalen Diensten, eine passende auszuwählen.

Wenn ein Dienst einen anderen Dienst über die ID adressiert, fragt der Helfer den Router nach einer nahen Registry. Beim Start kann er Registrierungsinformationen annehmen, bevor der erste Registry-Broadcast eintrifft, und die Registrierung abschließen, sobald Netzwerkinformationen vorliegen.

Interessierte Dienste können Registry-Änderungen abonnieren und reagieren, wenn Registries hinzukommen oder entfernt werden.

Einen Dienst über die ID adressieren

Eine Nachricht braucht nur die ID des Ziel-Microservices. Die ID kann numerisch, alphanumerisch oder eine UUID sein. Die Registry löst sie zu einer laufenden Instanz auf.

Nutzen mehrere Instanzen dieselbe ID, wählt die Registry eine davon aus. Load Balancing ist Teil der Service Discovery — kein zusätzlicher Proxy oder Service Mesh ist nötig.

Wird eine Response angefordert, kann sie die direkte Adresse der Instanz enthalten. Folgenachrichten können die Registry dann umgehen. Fällt dieser Knoten aus, kann der Absender zur Service-ID zurückkehren und eine andere Instanz auflösen.

Was das bringt

  • Keine zentrale Registry, die das ganze Netz anhalten kann
  • Automatische Discovery, wenn Knoten beitreten
  • Load Balancing über Service-Instanzen
  • Lokale Helfer für schnelle Registry-Auswahl
  • Ein Rückfallweg, wenn eine Instanz verschwindet

Skalierung: Weitere Registry-Instanzen auf zusätzlichen Knoten betreiben, während das Netz wächst.

Resilienz: Discovery verfügbar halten, auch wenn eine Registry oder Route ausfällt.

Effizienz: Die erste Nachricht per ID auflösen und direkte Adressierung für die Folgekommunikation nutzen.