
Microservices in Java - Spring Cloud und Netflix im Überblick - Teil 2
In
Teil 1
haben wir über die Microservices-Architektur, das Spring Cloud-Projekt und zwei wichtige Komponenten der Spring Cloud (Eureka Service Discovery und Zuul Edge Server) gesprochen. Jetzt werden wir unsere Geschichte über die Microservices-Architektur fortsetzen und auch andere Komponenten vorstellen:
- Dynamisches Routing und Lastausgleich – Netflix Ribbon
- Leistungsschalter und Überwachung – Netflix Hystrix
- Zentraler Konfigurations-Server – Cloud-Konfigurations-Server
Dynamisches Routing und Lastausgleich – Netflix-Bänder
Der serverseitige Lastausgleich wird bei monolithischen Anwendungen eingesetzt, bei denen sich eine begrenzte Anzahl von Anwendungsinstanzen hinter dem Load Balancer befindet. In diesem Fall hat der Load Balancer eine öffentliche IP und DNS und ein Client stellt eine Anfrage über die öffentliche IP/DNS. Der serverseitige Lastausgleich ist größtenteils ein manueller Aufwand, und wir müssen dem Lastausgleich manuell Instanzen hinzufügen/entfernen, damit er funktioniert. Um die Probleme des traditionellen Lastausgleichs zu überwinden, kam der clientseitige Lastausgleich ins Spiel.
Es gibt viele Microservices in der Microservice-Architektur und jeder Microservice kann mehrere Instanzen haben. Eine einzige Instanz eines Dienstes ist in der Produktion unvorstellbar, daher verwenden wir in diesem Fall in der Regel einen Load Balancer, der die Nutzlast auf mehrere Instanzen eines Dienstes verteilt. Netflix Ribbon aus der Spring Cloud-Familie bietet die Möglichkeit, zusammen mit der Service-Registry-Komponente einen clientseitigen Lastausgleich einzurichten.

Neben den clientseitigen Lastausgleichsalgorithmen bietet Ribbon noch weitere Funktionen
- Integration der Dienstsuche
- Fehlertoleranz
- Konfigurierbare Lastausgleichsregeln
Wenn es um Lastausgleichsregeln geht, unterstützt Ribbon standardmäßig RoundRobinRule, AvailabilityFilteringRule, WeightedResponseTimeRule sowie die Definition eigener Regeln. Die Ribbon API ermöglicht es, die folgenden Komponenten des Load Balancers zu konfigurieren:
- Regel – Eine logische Komponente, die die Regel für den Lastausgleich in unserer Anwendung festlegt
- Ping – Eine Komponente, die den Mechanismus angibt, mit dem wir die Verfügbarkeit des Servers in Echtzeit ermitteln
- ServerList – kann dynamisch oder statisch sein
Ribbon API kann die Verfügbarkeit des Servers durch regelmäßiges Kontakt-Pinging der Server ermitteln. Wenn alle Server ausgefallen sind und somit kein Server verfügbar ist, um die Anfrage zu bedienen, schlägt die Methode pingUrl() fehl und wir erhalten eine Ausnahme mit der Meldung „No instances are available to serve the request“.
Leistungsschalter und Überwachung – Netflix Hystrix
Ein typisches System besteht aus vielen Diensten, die zusammenarbeiten und sich gegenseitig unterstützen. Diese Dienste sind anfällig für Ausfälle oder verzögerte Antworten. Wenn ein Dienst ausfällt, kann dies Auswirkungen auf andere Dienste haben, die Leistung beeinträchtigen und möglicherweise andere Teile der Anwendung unzugänglich machen oder im schlimmsten Fall die gesamte Anwendung zum Erliegen bringen.
Hystrix ist eine Bibliothek zur Steuerung der Interaktionen zwischen diesen Diensten , die eine größere Latenz- und Fehlertoleranz bietet. Hystrix isoliert Zugriffspunkte zwischen den Diensten, verhindert kaskadenartige Ausfälle und bietet Fallback-Optionen, die die allgemeine Ausfallsicherheit des Systems verbessern. Es implementiert das Muster des Leistungsschalters. Stromkreisunterbrecher berechnen, wann der Stromkreis geöffnet und geschlossen werden muss und was im Falle einer Störung zu tun ist. Wenn alle Dienste zu einem bestimmten Zeitpunkt ausfallen, kann der Leistungsschalter diese Ausfälle problemlos bewältigen. Die Sicherungsautomaten haben drei Zustände:
- OPEN
- GESCHLOSSEN
- HALB-ÖFFNEN
Heutzutage werden bei Netflix täglich Dutzende Milliarden Thread-isolierter und Hunderte Milliarden Semaphor-isolierter Aufrufe über Hystrix ausgeführt, und durch den Einsatz von Hystrix wurde eine dramatische Verbesserung der Betriebszeit und Ausfallsicherheit erreicht.
Zentraler Konfigurations-Server – Cloud-Konfigurations-Server
In der Microservices-Architektur gibt es in der Regel eine große Anzahl kleiner Microservices und jeder Microservice ist in der Regel in mehreren Umgebungen gestaffelt. Spring Cloud Config ist der Client/Server-Ansatz von Spring zum Speichern und Bereitstellen von verteilten Konfigurationen über mehrere Anwendungen und Umgebungen hinweg. Mit dem Config Server gibt es einen zentralen Ort zur Verwaltung externer Eigenschaften für Anwendungen in allen Umgebungen.

Spring Cloud Config ist die Kombination aus zwei wichtigen Komponenten:
- Spring Cloud Config Server – Bietet Unterstützung für die Verwaltung zentraler Konfigurationen im GIT-Repository
- Spring Cloud Config Client – Bietet Unterstützung für das Anhängen von Anwendungen an Spring Cloud Config Server
Dieser Konfigurationsspeicher wird idealerweise unter Git-Versionskontrolle versioniert und kann zur Laufzeit der Anwendung geändert werden. Es passt zwar sehr gut in die Spring-Anwendungen, die alle unterstützten Konfigurationsdateiformate zusammen mit Konstrukten wie Environment,
PropertySource oder @Value
verwendet werden, kann es in jeder Umgebung mit jeder Programmiersprache verwendet werden.
Schlussfolgerung
Microservices haben viele Vorteile für agile und DevOps-Teams. Im Gegensatz zu Microservices wird eine monolithische Anwendung als einzelne, autonome Einheit erstellt, und Änderungen an einem kleinen Codeabschnitt können die Erstellung und Bereitstellung einer völlig neuen Version der Software erfordern. Microservices lösen diese Herausforderungen monolithischer Systeme, indem sie so modular wie möglich sind. Sie sind oft über APIs verbunden und können viele der gleichen Tools und Lösungen nutzen, die sich im RESTful- und Webservice-Ökosystem entwickelt haben.