Microservices mit Spring Boot

Einführung in Microservices

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
In diesem Video erfahren Sie, was Microservices sind, inwiefern sie sich von anderen Ansätzen unterscheiden und welche Versprechen sie in Bezug auf Skalierbarkeit, schnelle Updates und Technologieunabhängigkeit machen. Außerdem lernen Sie den Technologiestack kennen (Spring, Spring Boot, Netflix OSS, Vagrant, Docker, Tomcat und Java).

Transkript

Wenn Sie sich auf Konferenzen oder in der Fachpresse umschauen, werden Sie feststellen, dass es aktuell fast nur noch ein Thema gibt: Microservices und Cloud. Wir werden uns aus diesem Grund in diesem Video damit auseinandersetzen, was Microservices überhaupt sind, inwieweit sich Microservices von klassischen und gängigen Ansätzen der Softwareentwicklung unterscheiden und mit welchen Tool Sets wir sie umsetzen können. Ganz klassisch werden die meisten Entwickler in den letzten 20-25 Jahren Applikationen geschrieben haben, die wir als "Monolithische Lösungen" bezeichnen können. Bei einer monolithischen Lösung, etwa einer Client-Applikation oder einer Applikation, die als einzelnes Webarchiv, also WAR-Archiv ausgeliefert wird, sind üblicherweise alle Schichten, die es in dieser Applikation gibt, fest miteinander verdrahtet und verknüpft. Das ist schnell zu schreiben, das läuft auch in sich sehr sehr schnell, ist aber, wenn man das mit anderen Ansätzen vergleicht, schlecht zu warten und zu pflegen und auch nicht sonderlich gut zu skalieren. Um diese Probleme zu lösen, ist man dazu übergegangen für größere Applikationen das Konzept der Verticals einzusetzen. Verticals bezeichnen ein Ansatz bei dem wir eine sogenannte "Vertikale Dekomposition" fahren und das bedeutet eigentlich nichts anderes, als dass wir ein Gesamtsystem, als eine Summe von verschiedenen Teilsystemen bezeichnen, beispielsweise ein Front-End bei einer Java-EE-Applikation, dass in Form eines WAR-Archives ausgeliefert wird und eine Geschäftslogik und Datenlogik, die in Form eines JAR-Archives ausgeliefert wird und damit unabhängig von dem WAR-Archiv, dann auch betrieben und im Betrieb gesetzt werden kann. Diese Modularisierung der verschiedenen Komponenten erleichtert uns dann die Entwicklung, das Deployment und den Betrieb. Üblicherweise fahren wir dabei Client-Server-Ansätze, das heißt, wir haben eine Client-Schicht und eine Server-Schicht, wir können das Ganze allerdings, wie bereits beschrieben, auch auf Ebene von nur serverseitigen Ansätzen, also beispielsweise Java-EE- Web-Applikationen umsetzen. Betrachten wir die beiden Ansätze, also Monolithen und Verticals, dann stoßen wir auf verschiedene übergreifende Problemstellungen, die wir eigentlich bei fast jede Applikation so immer wieder feststellen können. Zum einen haben wir die Problemstellung der Infrastruktur. Solche Applikationen laufen üblicherweise auf Applikationsservern, also Servern wie dem WildFly-Server, JBoss oder dem Web Sway Application Server. Solche Application Server haben ein ganz grundsätzliches Versprechen, nämlich sie bieten mir alles aus einer Hand an, das heißt, sie bieten eine Menge an Services an, von denen ich allerdings in Form einer üblichen Webapplikation nur ein ganz geringen Teil nutze, nämlich Web-Messaging vielleicht, Asynchronität. Alle anderen Services, die da drin bereitgestellt werden, laufen unnütz mit Kosten Ressourcen und müssen dennoch mit gemanagt werden. Ein weiterer Problembereich ist die Skalierbarkeit. Solche Applikationen sind üblicherweise nur relativ schwierig zu skalieren, denn ich kann sie entweder nur im Ganzen skalieren bei den Monolithen oder nur in groben Teilen bei den Verticals. Das Ganze reicht für die normale Wald- Feld- und Wiesen-Applikation völlig aus, aber sobald es mehr Last wird, sobald wir mehr Druck auf die Applikation bekommen, wird die Synchronisation dieser verschiedenen Komponenten, die wir dann skalieren wollen, extrem schwierig. Wir haben einen gewaltigen Leistungsverlust und wir haben auf Grund der sehr groben Struktur gar keine Möglichkeit gezielt zu skalieren, wir können nur die Gesamtapplikation oder zumindest grobe Teile der Applikation skalieren, nicht aber diesen einen kleinen Service, diese eine kleine Funktionalität, die gerade unter Last gerät. Und wir haben keine Antworten auf die Verarbeitung von großen Datenmengen, denn diese Services können nicht beliebig ausskalieren, wie gesagt, nur große Stücke und große Synchronisationsaufwände und das limitiert die Art und Weise, wie wir eine Skalierung vornehmen können. Ein weiterer Problembereich ist der Bereich des sogenannten Continuous Deployment oder der Continuous Delivery. Üblicherweise ist es so, dass das Deployment als aufwendig betrachtet wird, natürlich wir haben eine große Applikation, die wir am Stück aktualisieren müssen oder eben wieder im groben Teilen, je nachdem ob wir Monolithen oder Verticals einsetzen, und wir können nicht gezielt die eine kleine Komponente aktualisieren. Und das wird dann ein großes Problem, wenn wir ständig Aktualisierungen mit in Betrieb setzen wollen, weil wir agil arbeiten, weil wir agil entwickeln, weil der Kunde auch agil Anforderungen hat, dann wird in solche Szenarien das Deployment und die Delivery eine ganz große Problemstellung. Die letzte Problemstellung ist die Beherrschbarkeit. Beherrschbarkeit meint, wie kann ich die Applikation betreiben. Das ist aus betrieblicher Sicht normalerweise relativ gut beherrschbar, denn wir setzen sie auf einem Application Server auf, der läuft vielleicht im Cluster, also mit zwei-drei Instanzen. Die Application-Server-Instanzen arbeiten untereinander alles ab, wir müssen da überhaupt nichts tun, wir müssen ein, zwei Systeme überwachen. Alles super. Wenn wir allerdings die Entwicklersicht und die Kundensicht mit ins Spiel bringen, dann sieht die Sache schon anders aus, denn aus Entwickler- beziehungsweise Kundensicht sind solche Systeme, also Monolithen beziehungsweise Verticals, nur schwer beschwerlich beherrschbar. Hintergrund, der Entwickler will und soll ständig Änderungen einbringen, es müssen Bugfixes bereitgestellt werden, es sollen neue Funktionalitäten kommen und wenn wir dann in Richtung Deployment denken, dann ist das, wie bereits erwähnt, schwierig bis unmöglich zu bewerkstelligen. Und aus Kundensicht, der Kunde möchte gerne skalieren, der Kunde möchte eine komplette Ausfallsicherheit seiner Applikation haben, der Kunde möchte in der Lage sein Lastspitzen abzufangen, das kann er mit Monolithen und mit Verticals nicht. Und das ist der Grund, warum es Microservices gibt. Microservices stellen Sie sich am besten so vor, dass wir eine Applikation statt, wie bei Verticals nur in große, grobe Teile zu zerlegen, in ganz ganz viele kleine Teile zerlegen, wie in diesem Bild viele viele kleine Häuser oder wenn Sie sich ein Haus vorstellen wollen, dann wird dieses Haus aus ganz vielen kleinen Ziegelsteinen gebaut. Jeder einzelne dieser Teile ist dann ein eigenständiger Service und kann eigenständig betrieben und eigenständig betrachtet werden. Solche Microservices sind dann technologieunabhängig. Technologieunabhängig bedeutet für uns, dass wir eine Vielzahl an Services haben, von denen jeder Service bei Bedarf die für ihn am besten geeignete Technologie einsetzen kann, das heißt, das ist durchaus denkbar, dass wir Services haben, die beispielsweise mit PHP und einer MySQL Datenbank geschrieben worden sind und darüber hinaus Services haben, die mit Java und einer Oracle Datenbank arbeiten und dann weitere Services haben, die mit einer ganz anderen Programmiersprache und einer NoSQL Datenbank interagieren. Das alles ist kein Problem, denn jeder Service ist in sich selbst geschlossen und kann das für ihn am besten geeignete Werkzeug einsetzen. In großen Projekten wird man dennoch üblicherweise eher auf einen Technologie-Stack zurückgreifen, aber wir haben die grundsätzliche Freiheit hier in Bezug auf Ansätze und Technologien eigene Wege zu gehen und damit dann auch neue Ansätze und neue Technologien, bessere Ansätze, bessere Technologien bei Bedarf zeitnah mit ins Spiel bringen zu können. Das Ganze führt dann dazu, dass wir nicht mehr in 10-15 Jahren mit Applikation-Stack konfrontiert sind für die es niemanden mehr gibt, der sie beherrschen kann, sondern die Applikationen sind einem ständigen Wandel unterlegen und wir können diese Applikationen gezielt an neue Technologien und an neue Services und an neue Ansätze anpassen. Auch die Skalierbarkeit ist, wenn wir Applikationen als Microservices ausführen, deutlich besser als bei klassischen Ansätzen. Zum einen bleibt die klassische horizontale Skalierbarkeit natürlich bestehen. Horizontale Skalierbarkeit meint, dass, wenn mein System langsam wird, ich einfach mehr Arbeitsspeicher, mehr Prozessoren, mehr Festplattenspeicher, vielleicht eine schnellere Festplatte einbaue und damit eine höhere Geschwindigkeit erziele. Das ist allerdings nur in Grenzen möglich. Was Microservices darüber hinaus aber versprechen, ist die sogenannte vertikale Skalierbarkeit. Vertikale Skalierbarkeit meint, dass ich gezielt die Teile einer Applikation, die unter Last geraten oder den ich mehr Ressourcen zuweisen möchte, als kleine Teile parallel zusätzlich aufsetze, das bedeutet ich habe dann einen Service A, der dann eben in drei Instanzen, vier Instanzen, fünf Instanzen, sechs Instanzen vorliegt. Beim klassischen Ansatz, bei Monolithen, müsste ich die Gesamtapplikation skalieren und bei Verticals müsste ich zumindest große Teile der Applikation skalieren, mit dem besprochenen Nachteilen, im Bezug auf Datenübertragung auf Latenzen und so weiter und so fort. Wie gesagt, vertikale Skalierbarkeit ist in sich bei Microservices geben. Darüber hinaus bin ich in der Lage Microservices sehr sehr einfach mit einem Load-Balancing zu versehen, das bringen die oftmals schon out-of-the-box mit und das bedeutet letztlich, dass, wenn ich zwei, drei, vier, fünf Services habe vom selben Typ, diese Services dann automatisch nacheinander angesprochen werden, sodass sich eine Last verteilt. Damit das Ganze funktionieren kann, benötige ich das Konzept der Zustandslosigkeit umgesetzt auf Ebene der Services. Und das mag zwar für den Entwickler dann vergleichsweise schwierig sein, weil Zustandslosigkeit immer bedeutet, dass ich den Zustand woanders vorhalten muss als auf dem jeweiligen Service. Bezogen auf den Service ist das allerdings sehr sehr positiv, denn der Service muss sich eben nicht über einen Zustand klar werden, der muss eben nicht wissen, wie war denn mein Zustand vorher oder was ist denn der Zustand nach der Verarbeitung, sondern der tut schlicht und einfach seine Arbeit. Und weil er genau das tut und nichts anderes, kann später problemlos ein anderer Service für ihn mit einspringen, wenn zu viel Last anliegt oder wenn der Service runterfällt. Und auch der Sharding ist bei Microservices umsetzbar. Sharding meint ein Konzept, bei dem Services, die auf Systemen mit mehr Ressourcen laufen, auch mehr Last bekommen, während Services, die auf Systemen mit geringen Ressourcen laufen, eben weniger Last bekommen. Das lässt sich auf Ebene von Microservices sehr fein ausjustieren. Was sind denn dann jetzt aber eigentlich Microservices, nachdem wir jetzt schon relativ intensiv über die Vorteile gesprochen haben. Nun, wie bereits erwähnt, Microservices sind eigene kleine Dienste. Das bedeutet, jeder Microservice hat genau eine Aufgabe "Single Purpose" und die Services sind voneinander isoliert, das heißt, ein einzelner Microservice weiß möglicherweise, welche anderen Services er aufruft, aber wie es danach weitergeht, das weiß er nicht und das muss ihn auch nicht interessieren, er muss auch kein Bild davon haben, wie jetzt der Systemkontext aussieht oder ähnliches. Die Services agieren in einer sogenannten losen Kopplung, das bedeutet, ein Service bietet eine Schnittstelle, üblicherweise eine RESTful-Services Schnittstelle an und kennt dann auch von anderen Services nur deren RESTful-Services Schnittstelle oder wenn es sich um einen Messaging-System, was asynchron arbeitet, eben deren Messaging-Schnittstelle. Mehr muss er nicht kennen und das erlaubt es uns dann wiederum relativ einfach die Services gegeneinander auszutauschen, solange wie die Schnittstelle gewartet bleibt. Ein ganz wesentliches Element von Microservices ist, dass diese Netzwerkbasiert arbeiten und das bedeutet, sie kommunizieren lediglich über einfache Protokolle, wie HTTP oder HTTPS miteinander und nicht über In-Memory oder andere fest verdrahtete Sachen, das macht sie zwar auf der einen Seite langsamer, auf der anderen Seite aber wesentlich besser skalierbar und wesentlich unempfindlicher gegenüber lokalen Störungen. Und der bereits angesprochene Best-Fit auf Technologieebene, Microservices sind eben kleine unabhängige Komponenten, die sehr lose nur miteinander verkoppelt sind und voneinander isoliert arbeiten und deswegen kann ich auf Ebene jeder einzelnen Komponente genau die Technologie einsetzen, von der ich denke, dass sie am besten dafür geeignet ist, um eine Aufgabe zu erfüllen. Microservices sind darüber hinaus ein Kind des Web-Zeitalters, das bedeutet, sie kommunizieren üblicherweise über HTTP oder HTTPS und RESTful-Services als Kommunikationsprotokolle und ihre Oberflächen basieren auf HTML, JavaScript und CSS. Sie können UI enthalten, müssen das aber nicht. Sie benutzen dann üblicherweise HTML und Webseiten, um verschiedene Verknüpfungen zwischen verschiedenen Services herzustellen. Der Datenaustausch ist ebenfalls bei Microservices vergleichsweise einfach geregelt wie bereits angesprochen HTTP, HTTPS oder asynchrone Protokolle, die dann eben über Netzwerk Q laufen. Mehr müssen Microservices nicht kennen, mehr müssen Microservices auch nicht wissen und damit haben wir eine sehr hohe Abstraktion zwischen den Services. Wenn wir Microservices umsetzen, ist es, wie bereits erwähnt, eigentlich relativ egal, was wir für Technologien einsetzen. Ganz primär sind Microservices, nämlich ein Gedankenkonstrukt. Wenn wir uns allerdings mit Technologien im Java-Umfeld auseinandersetzen wollen, dann gibt es einen mittlerweile zumindest sehr häufig verwendeten Technologie-Stack, der in aller Regel auf dem Spring-Framework basiert und der dann Applikationen umfasst, die mit Spring Boot, einer speziellen Variante von Spring implementiert worden sind. Wir verwenden dann üblicherweise ein Tomcat-Webserver für die Webschnittstellen, das Ganze ist Java-basierend und basiert oftmals, nicht immer, aber oftmals, auf Komponenten aus dem Netflix, Open-Source-Framework. Es ist genau die Firma Netflix, die uns die Videos nach Hause bringt. Um das ganze dann laufen zu lassen, verwendet man oftmals Docker Container. Docker Container sind im Grunde kleine virtuelle Maschinen, in denen die Applikation und sonst nichts drin läuft, und diese Docker Container können sehr sehr effizient verwaltet werden, sie verbrauchen deutlich weniger Ressourcen, als es klassische virtuelle Maschinen tun und sind dann auch über Infrastruktur- Werkzeuge extrem gut in Betrieb zu halten, zu skalieren, zu verteilen, neu aufzusetzen und so weiter und so fort. Vagrant ist ebenfalls ein Framework, was an dieser Stelle nicht unerwähnt bleiben sollte, denn Vagrant wird genutzt, damit wir Infrastruktur automatisiert bereitstellen können. Vagrant erlaubt es uns vorgefertigte virtuelle Maschinen herunterzuladen und diese virtuellen Maschinen, die sogenannten Basis Images, dann über Scripte und eigene Funktionalitäten automatisiert mit allen benötigten Funktionen auszustatten und dann könnte da drin beispielsweise wieder ein Docker Container laufen oder ich könnte dort drin dann auch eine Entwicklungsumgebung bereitstellen, je nachdem in welche Richtung ich gehen möchte. Applikationen, die als Microservice-basierender Applikationen auf diesem Technologie-Stack ausgefüllt sind, sind dann Applikationen, die es uns erlauben, anders zu skalieren, anders Funktionalitäten in den Markt zu bringen, schneller vor allen Dingen und auch viel zielgerichteter. Solche Applikationen bilden die Grundlage dessen, was wir heutzutage mit Cloud-basierenden und Cloud-fähigen Applikationen assoziieren, denn sie sind in der Lage sich über cloudifizierte Infrastrukturen, die dynamisch kommen und die auch relativ dynamisch wieder verschwinden können auszubreiten. Sie sind in der Lage mit diesen Infrastrukturen zu interagieren, sie sind selber Teil dieser Cloud-Welt, denn sie sind wesentlich einfacher, wesentlich leichtgewichtiger und wesentlich besser skalierbar, als es die klassischen monolithischen oder einfach vertikal zerlegten Applikationen sind. Das ist der Grund, warum Microservices immer mehr an Bedeutung gewinnen und das ist auch der Grund, warum Sie sich mit dieser Technologie auseinandersetzen sollten.

Microservices mit Spring Boot

Sehen Sie, wie moderne Applikationen für Cloud-Umgebungen entstehen.

2 Std. 14 min (12 Videos)
Derzeit sind keine Feedbacks vorhanden...

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!