Eureka – Microservice-Registry mit Spring Cloud

Architektur/Methoden  –  3 Kommentare

Eine wichtige Komponente einer Microservice-Infrastruktur ist die Service-Registry, die Services, ihre Instanzen und Lokationen in einer Datenstruktur zusammenfasst. Der Artikel zeigt die Funktionsweise des Netflix-Projekts Eureka an einem einfachen Beispiel.

Netflix erzeugt mit über 35 Prozent die höchste Downstream-Bandbreite in den USA, weit mehr als YouTube (15 %) und Facebook (6 %) zusammen. Als die monolithische Architektur dem wachsenden Traffic nicht mehr gerecht wurde, baute sie der Streaming-Dienst zwischen 2008 und 2012 zu einem System aus mehr als hundert Microservices um. Seitdem setzt Netflix auf feingranulare, lose gekoppelte Services. Das Unternehmen hat technische Komponenten und Bibliotheken entwickelt, um die Vielzahl der Services zu überwachen und die hohen Anforderungen an Ausfallsicherheit und Skalierbarkeit zu erfüllen. Sie bilden die Infrastruktur für die Netflix-Services und implementieren gebräuchliche Patterns für verteilte Systeme.

Die Komponenten müssen ihre Qualität in der Netflix-Umgebung täglich in einem komplexen, lastintensiven Szenario beweisen. Dank eines ausgefeilten Monitorings entdeckt Netflix Fehler und Schwachstellen in den Komponenten schnell und behebt sie – entsprechend hoch ist die Qualität der Komponenten. Sie werden im Netflix Open Source Software Center (Netflix OSS) als freie Software zur Verfügung gestellt. Spring Cloud Netflix, ein Unterprojekt von Spring Cloud, benutzt sechs Dienste aus dem Netflix OSS:

  • Eureka: Service-Registry und Mid-tier Loadbalancer
  • Hystrix: Bibliothek, die Fehler beim Zugriff auf externe Dienste isoliert und so die Ausfallsicherheit in einem verteilten System erhöht (Circuit Breaker)
  • Ribbon: Library für Interprozesskommunikation mit eingebautem Softwarelastverteiler
  • Archaius: Bibliothek für Konfigurationsmanagement, basiert auf Apache Commons Configuration und erweitert das Projekt für den Cloud-Einsatz
  • Zuul: Edge-Service für dynamisches Routing, Monitoring, Security, Ausfallsicherheit und einiges andere mehr
  • Feign: Library, die das Schreiben von HTTP-Clients vereinfacht

Eine wichtige Komponente einer Microservice-Infrastruktur ist die Service-Registry, die Services, ihre Instanzen und Lokationen in einer Datenstruktur zusammenfasst. Der Artikel zeigt die Funktionsweise von Eureka an einem einfachen Beispiel. Grundkenntnisse in Spring Boot sind sinnvoll, da Spring Cloud darauf basiert. Eine Einführung gibt es zum Beispiel bei spring.io.

Mit Eureka werden Microservices unter einem logischen Namen registriert, anschließend lassen sie sich über diesen Namen ansprechen. Damit können Services dynamisch auf unterschiedlichen Instanzen laufen, ohne dass der Nutzer die tatsächliche URL des Services wissen muss.

Eureka verwaltet die Services dynamisch: Das Projekt erkennt, wenn ein Service nicht mehr verfügbar ist und entfernt ihn aus der Registry. Außerdem können sich mehrere Instanzen eines Services unter dem gleichen logischen Namen registrieren; Eureka übernimmt die Lastverteilung zwischen den Instanzen. Services werden durch die Interaktion zwischen Eureka-Client und -Server gefunden. Der Server sammelt die Informationen über die registrierten Services. Für eine höhere Ausfallsicherheit wird er im produktiven Umfeld in der Regel redundant betrieben. Die redundanten Instanzen synchronisieren ihre Service-Registries untereinander. Der Eureka-Client ist eine Bibliothek zur Kommunikation mit dem Eureka-Server.

Das Beispiel in diesem Tutorial besteht aus drei Microservices (s. Abb. 1):

  • dem Eureka-Server, der die Service-Registry bereitstellt,
  • dem HELLOWORLD-SERVICE, über den der Eureka-Client seinen Dienst beim Eureka-Server registriert,
  • und dem Discovery-Client, der den HELLOWORLD-SERVICE über den Eureka-Server bezieht und ihn aufruft.
Das Beispiel besteht aus drei Microservices: Eureka-Server, HELLOWORLD-SERVICE und Discovery-Client (Abb. 1).

Um einen Dienst zu registrieren, schickt der Eureka-Client eine Registrierung mit einem logischen Namen und der dazugehörigen URL an den Eureka-Server (Register). Danach sendet er alle 30 Sekunden einen sogenannten Heartbeat als Lebenszeichen an den Server (Renew). Bleibt der Heartbeat aus, löscht der Eureka-Server die Instanz automatisch im Verzeichnis (Cancel). Der Client aktualisiert die Registry in regelmäßigen Abständen mit allen registrierten Services (Get Registry). Beim Aufruf eines anderen Dienstes kann der Client die URL des aufzurufenden Services anhand des logischen Namens ermitteln und damit einen Remote Call an den Dienst absetzen.