Der Spring Cloud Netflix Stack Grundkurs

Der Spring-Cloud-Netflix-Stack auf einen Blick

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Erfahren Sie in diesem Video, aus welchen Komponenten der Spring Cloud-Stack besteht und wo Spring Cloud Netflix ins Spiel kommt. Zusätzlich werfen Sie einen Blick auf einzelne Komponenten von Spring Cloud Netflix wie z.B. Archaius, Zuul, Ribbon, Hystrix, Feign, Eureka und Turbine.

Transkript

Eine Microservices-Applikation zu schreiben ist relativ einfach. Alles was wir brauchen ist Java, Spring Boot und vielleicht eine Entwicklungsumgebung. Was aber geschieht, wenn wir mehr als nur eine einfache Applikation brauchen? Was aber geschieht, wenn unsere Kunden von uns erwarten, dass wir Skalierbarkeit, Ausfallsicherheit und Anpassbarkeit der Applikation sicherstellen. In diesem Fall könnten wir entweder, das Rad neu erfinden, oder aber wir setzen beispielsweise auf den Spring Cloud und dort spezifisch den Spring Cloud Netflix Stack. Und wir werden uns in diesem Video einmal anschauen, was sich hinter diesem Stack verbirgt. Spring Cloud ist ein sogenanntes Umbrella oder Regenschirm-Projekt und das bedeutet, es besteht aus verschiedenen Teilprojekten oder Teilframeworks die unterschiedliche Aufgabenstellungen oder Aspekte der Integration einer Applikation in die Cloud abbilden. Spring Cloud Connectors erlaubt es uns unsere Applikationen mit sogenannten PaaS Plattformen, wie Heroku oder Cloud Foundry zu integrieren. PaaS steht für "Platform as a Service" und bezeichnet eine Umgebung, die in der Lage ist, ihre Infrastrukturen automatisch, entsprechend der Last ihrer Services, zu skalieren. Das heißt, zusätzliche Ressourcen bereitzustellen, oder die eben auch wieder wegzunehmen, wenn die Last nicht mehr darauf liegt. Spring Cloud Connectors gibt uns alles, was wir benötigen, um mit dieser Infrastruktur zu interagieren und dieser, beispielsweise auch Applikationsmetriken bereitzustellen, damit das Ganze gezielt erfolgen kann. Spring Cloud Bus ist ein Framework, das einen sogenannten Event Bus bereitstellt. Ein Event Bus ist eine Message Queue, in die unsere Komponenten der Applikation Nachrichten einstellen können, wenn bestimmte Operationen vorgenommen worden sind, also bpsw. ein Datensatz angelegt wurde Dann können andere Teilkomponenten der Applikation, oder sogar komplett andere Applikationen auf diese Nachrichten reagieren und können ihrerseits, dann im Anschluss, eigene Operation mit diesen Informationen durchführen. Und wenn sie diese Operation abgeschlossen haben, können sie wieder eine Nachricht in diesen Event Bus einstellen und die nächste Komponente kann dann entsprechend reagieren, interagieren und ihre Funktionalität ausführen. Spring Cloud Security ist ein Framework mit dessen Hilfe wir übergreifende Sicherheit gewährleisten können. Das heißt, wir sind in der Lage eine zentralisierte Authentifizierung und Autorisierung abzubilden und auf Ebene der einzelnen Services unserer Applikation dann eben auch mit dieser Authentifizierung und Autorisierung zu interagieren. Wir müssen dabei so gut wie keinen eigenen Code schreiben, sondern lediglich einige Annotationen unserer Applikation hinzufügen. Spring Cloud Config stellt ein Konfigurationsservice bereit. Das heißt, wir haben die Möglichkeit zentral im Rahmen einer Applikation Konfigurationen abzulegen und dann können wir die einzelnen Services, die in der Applikation laufen, sich die benötigten oder interessanten Konfigurationsinformationen abholen. Auf die Art und Weise vermeiden wir feste Verdrahtungen innerhalb der einzelnen Services und können, sogar im laufenden Betrieb, auf geänderte Umgebungen, Zustände oder Anforderungen reagieren. Spring Cloud for Amazon Web Services ist dann wieder eine Integrationsplattform. Mit deren Hilfe sind wir in der Lage mit Amazon Webservices, also AWS-Komponenten zu interagieren. Der Vorteil für uns als Applikation ist, dass wir uns weitestgehend davon abstrahieren können und Spring Cloud für AWS alles Notwendige dann an Infrastruktur, an Kommunikationswegen und Logiken bereits bereitstellt und abbildet, um unsere Applikation im Amazon Web Services Umfeld erfolgreich bereitstellen und deployen zu können. Die Basis unserer Applikation, also das Herzstück einer Cloud-Applikation bildet oftmals der Spring Cloud Netflix Stack und dieser Spring Cloud Netflix Stack besteht aus einzelnen Komponenten, die wir uns gleich anschauen wollen. Zunächst einmal aber ein paar Worte zu Spring Cloud Netflix selber. Spring Cloud Netflix ist ein "Open Source Stack", der von der gleichnamigen Firma Netflix bereitgestellt wird. Netflix ist eine Firma, die speziell im Videostreaming-Umfeld agiert und die bereits seit 8 oder 9 Jahren, sehr, sehr, sehr cloudorientiert arbeiten und alles, das was Netflix selber an Infrastrukturen geschrieben hat, haben sie an die Community zurückgegeben, sodass letztlich dieselben Technologien wie sie Netflix einsetzt, auch für unsere Applikationen zur Verfügung stehen. Der Spring Cloud Netflix Stack ist dann eine Anpassung dieses Netflix Stacks an das Spring-Umfeld. Es ist letztlich in dieses Projekt integriert, wann immer Netflix neue Komponenten bereitstellt, gibt es kurz danach, entsprechende Spring Cloud Netflix-Integrationskomponenten. Diese Komponenten werden in Form von Maven-Artefakten ausgeliefert. Das heißt, auf Ebene unserer Applikation ist die Integration und Nutzung dieses Stacks sehr, sehr einfach, denn wir müssen lediglich Maven-Artefakte hinzufügen, die Applikation neu konfigurieren und dann entsprechend kompilieren und bereitstellen. Eine Applikation, die mit Hilfe des Spring Cloud Netflix Stacks umgesetzt wird kann auf verschiedene Teilkomponenten und Aspekte dieses Stacks zurückgreifen und damit natürlich ihre entsprechende Funktionalität sicherzustellen. Wenn sie beispielsweise eine zentrale Konfiguration anbieten möchten, dann können sie "Archaius" verwenden. Archaius funktioniert so ähnlich wie Spring Cloud Config, nur ist das Ganze hier mithilfe von Netflix-Technologien umgesetzt worden. Die Applikation wird in aller Regel ebenfalls einen sogenannten "Zuul Proxy" einsetzen. Zuul Proxy ist eine Komponente, die einen Proxyserver bereitstellt, auf dem virtuelle Pfade hinterlegt sind. Jeder dieser virtuellen Pfade zeigt dabei in aller Regel auf einen eigenständigen Service, der seinerseits wieder in mehreren Instanzen erfolgen kann. Der Vorteil, so einen Zuul Proxy einzusetzen, besteht darin, dass man dann zentral auf Ebene dieses Proxys, die Pfade anpassen kann, beziehungsweise die Komponenten, die angesprochen werden, entsprechend anpassen kann, ohne dass es der Endkunde, also der Nutzer oder eine andere Komponente mitbekommen. Die Komponenten Ribbon, Hystrix und Feign werden üblicherweise gemeinsam eingesetzt Hystrix ist dabei der Kern dieser drei Komponenten, denn Hystrix ist ein sogenanntes Resilience Framework Ein Resilience Framework ist ein Framework, mit dessen Hilfe die Applikation wie so eine Art Schalter implementieren kann. Das heißt, wenn beim Aufruf eines anderen Service ein Fehler auftritt, dann wird, nachdem der Fehler passiert ist, diese Serviceinstanz, die den Fehler verursacht hat, für eine gewisse Zeit nicht mehr erneut aufgerufen. Das heißt, der Schalter wird geschlossen und die Applikation wird, wenn keine weitere Serviceinstanz dieses Typs vorhanden ist, automatisch einen Fehler werfen, oder aber, sie wird, wenn eine andere Serviceinstanz verfügbar ist, diese andere Serviceinstanz stattdessen ansprechen. Das erledigt Hystrix für uns und Hystrix erlaubt es uns auch, diese Timeouts, von denen ich gerade gesprochen habe, zu hinterlegen. Das heißt, zu verhindern, dass die Applikationen beim Warten auf einen anderen Service in ein Deadlock oder in ein unendliches Warten hineinläuft. Ribbon ist ein Load-Balancer. Load-Balancer haben ja die Aufgabe die Last auf dem System zu verteilen und Ribbon nutzt dabei die Daten, die von Hystrix erhoben worden sind, also diese Schalterdaten und auch die Daten, wie lange jetzt eigentlich der eigentliche Request gedauert hat um zu erkennen, welche Instanzen unter Last stehen, welche Instanzen überhaupt ansprechbar sind und welche nicht ansprechbar sind und gibt diese Informationen dann in der Applikation an beispielsweise den Feign-Client weiter. Der Feign-Client ist eine Komponente, mit deren Hilfe wir Rest-Requests anders und einfacher umsetzen können. Das heißt, wir sind hier in der Lage, zum einen zu definieren, welche Komponente möchte ich jetzt ansprechen, mit welchen Daten, was bekomme ich zurück, zum anderen nutzt aber Feign die Daten, die von Ribbon bereitgestellt worden sind, um die korrekte Instanz eines Service anzusprechen und Feign seinerseits integriert sich auch mit Hystrix, beziehungsweise verwendet Hystrix, um dieses Schalterverhalten, also, hier ist ein Fehler passiert und jetzt spreche ich diese Instanz nicht mehr an und eben auch das Erheben der eigentlichen Daten, wie lange hat jetzt ein Request gedauert, wie viele Daten habe ich zurückbekommen und so weiter und so fort sicherzustellen und diese Daten dann an die Applikation wieder weiterzugeben. Aber woher wissen Ribbon, Hystrix und Feign eigentlich, welche Serviceinstanzen in der Applikation bekannt sind? Wir wollen sie idealerweise nicht fest verdrahten, denn feste Verdrahtung wäre im Cloudumfeld ein echtes Vergehen. Nein, es muss eine weitere Komponente geben, mit deren Hilfe wir Services und Serviceinstanzen verwalten können und das ist Eureka. Eureka ist eine sogenannte Service Discovery. Das heißt, bei dieser Komponente melden sich alle Services, beziehungsweise alle Serviceinstanzen, wenn sie gestartet werden an und Eureka wird diese Information dann Ribbon, Hystrix und Feign zur Verfügung stellen und natürlich auch allen anderen Komponenten, die daran interessiert sind. Eureka ist ebenfalls in der Lage sicherzustellen, dass die Services überhaupt noch existieren. Das heißt, Eureka wird in regelmäßigen Abständen die Liste dieser Services durchgehen und die Services anpollen und schauen, ob es in einem bestimmten Zeitrahmen überhaupt noch eine Reaktion gibt. Auf die Art und Weise haben wir ein System, was hochdynamisch im Bezug auf Services und Instanzen ist und gleichzeitig sich selbst überwacht, und wenn ein Service verschwindet, das auch rechtzeitig bemerkt. Die Daten, die ein Hystrix zum Beispiel erhebt, werden normalerweise auf Ebene der Serviceinstanzen, wo das Hystrix läuft, vorgehalten. Da wir aber zu einem Service natürlich mehr als eine Instanz haben können, das ist ja das Prinzip einer cloudfähigen Applikation besteht eine weitere Notwendigkeit, nämlich, wir müssen diese Daten zentral konsolidieren können, um beispielsweise auf Ebene von Ribbon auch die richtigen Aussagen treffen zu können. Und das ist die Aufgabe von Turbine. Turbine ist eine Datenkonsolidierungs-Komponente, die die Hystrixdaten und auch andere Daten die innerhalb der Komponenten erhoben werden, zusammensammelt und über den sogenannten Turbinestream dann auch allen anderen interessierten Komponenten zur Verfügung stellt und darüberhinaus das sogenannte Turbine Dashboard bereitstellt, wo die Hystrix-Daten, die aufgenommen worden sind, zentralisiert dargestellt werden können. Dabei interagiert Turbine nicht nur mit den einzelnen Hystrix-Komponenten, sondern auch mit Eureka, um nämlich diese Daten dann auch auf Serviceebene wieder zu konsolidieren. Das heißt, wir können zentral erkennen, wir haben beispielsweise ein Frontend-, Backend- und Mail-Service und wir können dann auch wirklich von allen Instanzen in Echtzeit oder nahezu Echtzeit erkennen, wie ist die Last eigentlich auf dem System. Und das ist etwas, was man als Administrator oder als Betreiber eines Services sehr, sehr gut nutzen kann, um dann festzustellen, hier muss jetzt eine zusätzliche Instanz gestartet werden, oder hier kann ich wieder eins, zwei Instanzen händisch herunterfahren, um eben nicht unnötig Ressourcen zu blockieren. Ziehen wir mal einen Strich drunter. Wenn wir uns das anschauen, bekommen wir hier eine ganze Menge an Funktionalitäten, vom Spring Cloud Netflix Deck bereitgestellt, also zentrales Konfigurationsmanagement, einen Proxy-Server, einen Load-Balancer, Resilience, Konsolidierung von Monitoring Daten, Service Discovery, mit deren Hilfe wir sehr, sehr spannende und interessante Lösungen umsetzen können. Und wenn wir dann auch noch den gesamten Spring Cloud Stack mit in Betracht ziehen, dann ist das schon eine ganze Menge an Funktionalitäten und an Diensten und an Integrationen, die uns da für das Umsetzen von unserem "next big thing", zur Verfügung stehen. Und es lohnt sich wirklich sich mit den verschiedenen Aspekten von Spring Cloud und speziell auch Spring Cloud Netflix auseinanderzusetzen, zumal diese verschiedenen Komponenten einem ständigen Wandel im positiven Sinn, und einer Erweiterung unterlegen sind. Das bedeutet, das was wir heute wissen, ist die Basis für unsere Applikation morgen und kann übermorgen schon um ganz neue Funktionalitäten in diesem Stack erweitert werden. Und es lohnt sich wirklich da mal einen intensiveren Blick darauf zu werfen.

Der Spring Cloud Netflix Stack Grundkurs

Lernen Sie den Open Source Cloud Stack und seine vielfältigen Einsatzmöglichkeiten kennen.

2 Std. 5 min (13 Videos)
Derzeit sind keine Feedbacks vorhanden...
Exklusiv für Abo-Kunden
Ihr(e) Trainer:
Erscheinungsdatum:06.03.2017
Laufzeit:2 Std. 5 min (13 Videos)

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!