Der Spring Cloud Netflix Stack Grundkurs

Das Lastverhalten der gesamten Applikation überwachen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Normalerweise reicht es nicht aus, nur eine Instanz eines spezifischen Services zu überwachen. Deshalb werden Sie in diesem Video mit Hilfe von Turbine alle Instanzen des Backend-Services parallel überwachen. Mithilfe von Apache JMeter werden Sie zudem Ihre Anwendung einem Stresstest unterziehen, um zu erkennen, wo deren Leistungsgrenzen liegen.

Transkript

Die Kombination aus Hystrix-Dashboard und Hystrix-Stream ist großartig, wenn Sie eine einzelne Instanz eines Services überwachen wollen. Nur was ist, wenn Sie eine zweite oder eine dritte Instanz überwachen wollen, oder gar einen zweiten Service? Dann kommen Sie ganz schnell an Grenzen, denn dann müssten Sie zwei, drei, vier verschiedene Hystrix-Dashboard-Instanzen offen halten. Das Ganze ist dann irgendwann nicht mehr handhabbar. Aus diesem Grund gibt es Turbine. Turbine ist ein Framework, das in der Lage ist, die Hystrix-Streams von verschiedenen Instanzen und Services zu kombinieren und zu konsolidieren. Und diese konsolidierten Informationen dann den Hystrix-Dashboards zur Verfügung zu stellen. Auf die Art und Weise können wir uns an einer zentralen Stelle einen Überblick verschaffen, was in unserer Applikation gerade los ist. In diesem Video werden wir uns einmal damit befassen, wie wir Turbine aufsetzen können und wie wir verschiedene Instanzen eines Services mit Hilfe von Turbine konsolidieren können, das heißt, deren Daten abgreifen können und den Hystrix-Dashboards zur Verfügung stellen können. Wir werden ebenfalls mit Hilfe von Apache JMeter einen Lasttest fahren. Um Turbine nutzen zu können, müssen wir unserer Applikation zunächst einmal zwei weitere Abhängigkeiten hinzufügen. Wir erledigen dies in der Datei "pom.xml" und wechseln dort in den Reiter "Dependencies". Hier fügen wir nun zunächst einmal die Abhängigkeit für Eureka hinzu, denn Turbine soll sich mit Eureka verbinden. Die Abhängigkeit befindet sich in der Group-ID "org.springframework.cloud" und heißt "spring-cloud-starter-eureka". Ein Klick auf "OK" übernimmt diese Abhängigkeit und per "Add" fügen wir nun noch die Turbine-Abhängigkeit hinzu. Diese befindet sich in derselben Group-ID, also "org.springframework.cloud", und die Artifact-ID lautet "spring-cloud-starter-turbine" Ein Klick auf "OK" übernimmt auch diese Abhängigkeit. Sobald wir das Ganze gespeichert haben, können wir die letzten notwendigen Anpassungen vornehmen. Wir wechseln nun in die Bootstrapping-Klasse und fügen hier zwei weitere Annotationen hinzu, nämlich einmal "EnableEurekaClient" und einmal "EnableTurbine". Damit haben wir hier alles soweit vorbereitet und können uns nun um die Konfiguration von Eureka, beziehungsweise von Turbine kümmern. Wir erledigen dies dann in der Datei "application.properties" und werden hier zunächst einmal die Eureka-Konfigurationseinstellungen hinzufügen. Hierbei handelt es sich um die Information zum Applikationsname, also dem Namen unter dem Turbine, beziehungsweise dieser Service später in Eureka auftaucht, und natürlich die Konfiguration des Eureka-Servers selber, so dass wir wissen, wo wir uns hinwenden müssen. Die nächste Konfiguration betrifft dann schon Turbine. Wir müssen nämlich zunächst einmal festlegen, welche Applikation, beziehungsweise welche Services wir überwachen wollen. Das ist in diesem Fall der Service mit dem Namen "backend". Das ist der einzige Service, der über einen Hystrix-Stream verfügt. Und wir müssen darüber hinaus, mit Hilfe von "turbine.cluster-name-expression" angeben, welches Cluster wir überwachen wollen. Da wir gar kein Cluster definiert haben, ist die Angabe hier als 'default' festzulegen. Wir speichern die "application.properties" einmal und sind dann soweit auf Ebene dieser Applikation einsatzfähig. Bevor wir nun allerdings die Applikation starten und uns anschauen, wie Turbine funktioniert, sollten wir noch eine Änderung an der "application.properties"-Datei des Guestbook-Backend-Projekts vornehmen und zwar sollten wir hier noch einen Eintrag hinzufügen, nämlich "eureka.instance.instance-id", und dieser Eintrag sollte einen zufälligen Wert annehmen. Der Hintergrund ist, dass Eureka nicht in der Lage ist, mehrere Instanzen, die von derselben Maschine gestartet worden sind, zu unterscheiden. Das könnte sowohl bei der Verteilung von Requests ein Problem darstellen, wie auch dann beim Auswerten der Daten über Turbine. Dasselbe machen wir auf Ebene vom "guestbook-mail"-Projekt einmal und fügen dort diese Information an. Und wo wir gerade beim "guestbook-mail"-Projekt sind, hier öffnen wir einmal den "GuestbookMailController" und werden hier das Versenden der E-Mail auskommentieren, denn wir wollen nicht wirklich, wenn wir jetzt hier ein Tool drüber laufen lassen würden, sekündlich Dutzende von E-Mails versenden. Stattdessen simulieren wir das, indem wir, statt des Versendens, "Thread.sleep(1500)" aufrufen. Das Ganze wird dann mit einer Try/Catch-Definition umgeben, so dass eventuelle Fehler dabei behandelt sind. Und dann sind wir einsatzfähig. Nun sollten wir alle eventuell laufenden Instanzen vom Mail und vom Backend-Service einmal neu starten. Es gibt dafür eine entsprechende Schaltfläche im Eclipse. Beim Neustart wird allerdings jeweils nur eine Instanz dieses Dienstes gestartet, das Ganze dauert auch ein paar Sekunden, bis es abgeschlossen ist. Solange kann es durchaus sein, dass Eclipse auch nicht vernünftig reagiert. Ich werde jetzt hier noch eine zweite und eine dritte Backend-Instanz auf einen beliebigen Port starten, damit wir beim Backend drei Instanzen haben, beim Mail-Server eine Instanz und dann werde ich zu guter Letzt auch noch Hystrix neu starten oder grundsätzlich überhaupt starten. Auch das wird wieder ein paar Sekunden dauern, aber sobald das geschehen ist, bin ich dann in der Lage, mein Backend zu testen. Diesen Test möchte ich dann allerdings nicht mehr von Hand vornehmen, sondern, und das könnten Sie sich vielleicht schon denken, wenn ich hier den Versand der E-Mail auskommentiere, ich möchte dafür ein Tool nehmen. Es gibt verschiedene Tools, mit denen man so etwas machen kann. Ich werde jetzt Apache JMeter einsetzen. Apache JMeter können Sie kostenlos herunterladen, unter "jmeter.apache.org". Wechseln Sie hier zum Download und laden Sie das entsprechende ZIP-Archiv runter, entpacken Sie es und starten Sie JMeter über die Datei, die sich im Bin-Verzeichnis befindet. Das ist ein JAR-Archiv, normalerweise reicht ein Doppelklick darauf aus. Hier im JMeter werden wir nun einen neuen Testplan anlegen. Zu diesem Zweck führen wir einen Rechtsklick auf "Testplan" aus und wählen "Hinzufügen" "Threads (Users)" und dann nehmen wir eine Thread-Gruppe. Diese nennen wir "Backend-Test" und lassen sie erst mal so stehen, wie sie ist. Unter dieser Thread-Gruppe fügen wir über "Konfigurations Element" "HTTP Header Manager", einen sogenannten Header-Manager hinzu. Den benötigen wir, damit wir nämlich sagen können, was wir an unser Backend schicken. Deswegen sobald dieser Header-Manager existiert, klicken wir dort auf "Hinzufügen" und fügen jetzt hier einen HTTP-Header-Wert ein, nämlich "content-type" und da kommt der Wert "application/json" hinein. Nun fügen wir den Test noch eine weitere Komponente hinzu, nämlich einen Sampler und zwar einen HTTP-Request. Und hier geben wir zunächst einmal beim Server-Name "localhost" an. Der Port ist 8000. Protokoll können wir so stehen lassen. Methode ist "PUT". Pfad ist "/guestbook/" und wir wechseln einmal in den Bereich "Body Data" und simulieren jetzt hier die Daten, die von der Frontend-Applikation normalerweise geschickt werden, und das sind drei Datenfelder, nämlich "comment". Da können wir einen entsprechenden Wert eintragen, "Test-Kommentar". Dann kommt ein Komma und in nächster Zeile dann "commenter". Und zu guter Letzt "title" mit einem entsprechenden Wert. Damit haben wir hier auf Ebene von Apache JMeter alles hinterlegt, was wir hinterlegen müssen, um automatisiert oder in großen Mengen Tests gegen unsere Applikation fahren zu können, und können uns nun das Laufverhalten unsere Applikation anschauen. Zu diesem Zweck werden wir das Hystrix-Dashboard zusammen mit Turbine einmal in Betrieb nehmen. Mit Hilfe von Eureka öffne ich nun die Turbine-Instanz, ändere die Adresse, am Ende auf "hystrix.dashboard", kopiere den vorderen Teil und füge an diesen Teil "turbine.stream" an. Ein Klick auf "Monitor Stream" öffnet dann den Hystrix-Stream. Hier wird jetzt, solange keine Last auf der Applikation liegt, gar nix erscheinen. Erst wenn wirklich eine Last auf der Applikation liegt, werden hier sukzessive die verschiedenen Hosts sichtbar werden. Um dies ein wenig zu beschleunigen, habe ich JMeter geöffnet und führe einmal 10 Requests aus. Nach ein paar Sekunden werden wir dann feststellen, dass der Hystrix-Stream beginnt, Daten darzustellen. Sollte Ihnen das zu lange dauern, dann refreshen Sie die entsprechende Seite. Haben Sie aber bitte etwas Geduld, es kann wirklich etwas dauern, bis die Daten erscheinen. So, nun werden wir einmal 25 Requests auf die Applikation loslassen und dann werden wir uns mal anschauen, ob wir das schon sehen können, dass die Daten entsprechend verarbeitet werden. Ich habe den Request gestartet und wir sehen, die Applikation kommt wunderbar mit 25 parallelen Requests klar. Es dauert ein paar Sekunden, bis diese abgearbeitet sind. Jetzt sind sie alle weg. Wunderbar. Und wir sehen auch in der Seite, dass alle drei Backend-Services, die zur Verfügung stehen, hier registriert sind. Nun werden wir die Applikation mal langsam an ihre Grenzen bringen. Und zwar werden wir einmal 50 Threads laufen lassen und dann gucken, ob wir da schon Ausfälle beobachten können. Ja, bei 50 Threads gibt es schon die ersten Ausfälle, allerdings scheinen die, nur relativ kurzfristiger Natur zu sein. Die gelblichen Färbungen der Kreise verschwinden nach einer kürzen Zeit wieder. Wir schauen uns mal an, wie das Ganze bei 500 Threads aussieht. Hier könnten wir gerade eben schon feststellen, dass Circuits geclosed worden sind, dass also die Applikation, speziell Hystrix, in der Applikation festgestellt hat, dass wir auf ein Problem gestoßen sind. Deswegen wurde dann die Verarbeitung auch abgebrochen und deswegen konnte die Applikation als solches zwar die Aufgabe nicht mehr erfüllen, aber war dennoch noch in der Lage, zu reagieren. Wir können es jetzt solange weiter treiben, bis wir hier unsere Applikation wirklich dauerhaft an Grenzen führen, aber das ist ja gar nicht die Idee von diesen Tests. Und man sollte sich auch klarmachen: 500 Threads, die, wie ich jetzt gerade konfiguriert habe, in 10 Wiederholungen parallel auf die Applikation einhämmern, sind eigentlich schon eine Denial-of-Service-Attacke. Und selbst in solchen Fällen kommen noch Verarbeitungen im Backend an, auch wenn lange nicht mehr alles ankommt. Wir sehen also, die Applikation als solches ist durchaus in der Lage, zu skalieren, und durchaus auch in der Lage, Lasten abzuarbeiten. Und mit Hilfe des Hystrix-Dashboard und von Turbine können wir das gesamt monitoren. Das heißt, wir sind nicht nur auf einen einzigen Service mit seiner einen Instanz angewiesen, sondern können das für alle Instanzen aller Services, die Hystrix und den Hystrix-Stream unterstützen, hier zentralisiert abbilden. In diesem Video haben wir unsere Applikation um die Fähigkeit erweitert, nicht nur eine Instanz, sondern mehrere Instanzen parallel zu überwachen. Wir haben darüber hinaus, mit Hilfe von Apache JMeter, einmal einen echten kleinen Lasttest auf der Applikation gefahren und wissen nun, dass wir zumindest 25 bis 50 Anfragen parallel verarbeiten können. Und das ist doch für so eine kleine Applikation, wie wir sie bisher geschrieben haben, eine sehr sehr gute Zahl.

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
Erscheinungsdatum:06.03.2017

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!