Spring Boot

Cloud-native Anwendungen mit Java und Kotlin erstellen

Mark Heckler, Kathrin Lichtenberg

• Publisher: O'Reilly
• Year: 2021
• ISBN:
  9783960106050
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming in Java
• Index: Computer Science

Leistungsstarke, produktionsreife Cloud-native Anwendungen mit dem beliebten Framework

• Erfahren Sie, wie Spring Boot die Entwicklung, die Konfiguation und das Deployment von Cloud-nativen Applikationen entscheidend vereinfacht
• Das Buch zeigt Ihnen, wie Sie direkt produktiv in die Arbeit mit Spring Boot einsteigen
• Für Java- und Kotlin-Entwickler: innen

Mit über 75 Millionen Downloads pro Monat ist Spring Boot das populärste und am weitesten verbreitete Java-Framework. Seine Benutzerfreundlichkeit und Leistungsfähigkeit haben die Anwendungsentwicklung von Monolith-Architekturen und Microservices revolutioniert. Doch die Einfachheit von Spring Boot kann auch verwirrend sein. Was brauchen Entwickler, um sofort produktiv zu werden? Dieses praxisorientierte Buch zeigt Ihnen, wie Sie das Framework nutzen, um erfolgreiche unternehmenskritische Applikationen zu entwickeln. Mark Heckler von VMware, der Firma hinter Spring, führt Sie durch die Architektur und die Konzepte von Spring Boot und behandelt auch Themen wie Debugging, Testen und Deployment. Wenn Sie mit Spring Boot schnell und effektiv Cloud-native Java- oder Kotlin-Anwendungen entwickeln wollen - inklusive reaktiver Programmierung, dem Erstellen von APIs und dem Einrichten von Datenbankzugriffen aller Art - dann ist dieses Buch genau das Richtige für Sie.

KAPITEL 1

Spring Boot in a Nutshell

Dieses Kapitel erkundet die drei Kerneigenschaften von Spring Boot und untersucht, wie diese Ihnen als Entwickler zur Seite stehen.

Die drei Grundeigenschaften von Spring Boot

Die drei Kerneigenschaften von Spring Boot, auf denen alles andere aufbaut, sind ein vereinfachtes Abhängigkeitsmanagement, ein vereinfachtes Deployment und die Autokonfiguration.

Starter für vereinfachtes Abhängigkeitsmanagement

Einer der genialen Aspekte von Spring Boot besteht darin, dass es das Dependency- oder Abhängigkeitsmanagement handhabbar macht.

Falls Sie bereits einmal ernsthaft Software entwickelt haben, mussten Sie sich bestimmt schon mehrfach den Kopf hinsichtlich des Abhängigkeitsmanagements zerbrechen. Jede Fähigkeit, die Sie mit Ihrer Anwendung anbieten, erfordert im Vorfeld üblicherweise eine Reihe von Abhängigkeiten. Falls Sie zum Beispiel ein RESTful-Web-API bereitstellen, müssen Sie eine Möglichkeit zur Verfügung stellen, Endpoints über HTTP anzubieten, auf Anfragen (Requests) zu lauschen, diese Endpoints an Methoden/Funktionen zu binden, die diese Anfragen verarbeiten, um dann passende Antworten (Responses) zu erzeugen und zurückzuliefern.

Jede primäre Abhängigkeit zieht fast zwangsläufig zahllose weitere sekundäre Abhängigkeiten nach sich, um ihre versprochene Funktionalität zu erfüllen. Um bei unserem Beispiel eines RESTful-API zu bleiben: Wir können eine Reihe von Abhängigkeiten erwarten (in einer vernünftigen, wenn auch strittigen Struktur), die Code enthalten, der Responses in einem bestimmten Format liefert, z.B. JSON, XML, HTML, Code zum Marshalling/Demarshalling von Objekten in bestimmte Formate, Code zum Lauschen auf und Verarbeiten von Anfragen und zum Zurückgeben von Antworten auf diese, Code zum Decodieren komplexer URIs, die benutzt werden, um vielseitige APIs zu erzeugen, Code zum Unterstützen verschiedener Übertragungsprotokolle und mehr.

Selbst für dieses relativ einfache Beispiel müssen wir wahrscheinlich schon mit einer großen Anzahl von Abhängigkeiten in unserer Build-Datei rechnen. Und wir haben an dieser Stelle noch gar nicht darüber nachgedacht, welche Art Funktionalität wir in unsere Anwendung aufnehmen wollen, sondern nur ihre nach außen gerichteten Interaktionen betrachtet.

Reden wir nun über Versionen und über jeder einzelne dieser Abhängigkeiten.

Die gemeinsame Benutzung von Bibliotheken erfordert eine gewisse Präzision, da es sein kann, dass eine Version einer speziellen Abhängigkeit nur mit einer bestimmten Version einer anderen Abhängigkeit getestet wurde (oder gar nur mit ihr korrekt funktioniert). Solche Probleme, die unweigerlich auftauchen, bezeichne ich als »Abhängigkeits-Whack-a-Mole« (»Hau den Maulwurf«).

Genau wie das namengebende Spiel kann auch Abhängigkeits-Whack-a-Mole sehr frustrierend sein. Anders als bei dem Spiel gibt es jedoch keine Preise zu gewinnen, wenn man Bugs, die aus falschen Zuordnungen resultieren, jagt und zerhaut, sondern höchstens seltsame Diagnosen und Stunden, die man mit der Suche nach ihnen verplempert hat.

Doch jetzt kommen Spring Boot und seine Starter. Spring-Boot-Starter sind Bills of Materials (BOMs; also quasi Stücklisten), die aufgrund der erwiesenen Tatsache erstellt werden, dass Sie eine bestimmte Funktion in der Mehrzahl der Fälle auf nahezu dieselbe Weise bereitstellen.

Jedes Mal, wenn wir im oben angeführten Beispiel ein API bauen, stellen wir Endpoints bereit, lauschen auf Anfragen, verarbeiten die Anfragen, wandeln Objekte um, tauschen Informationen in verschiedenen Standardformaten aus, senden und empfangen Daten mit einem bestimmten Protokoll über die Leitung und mehr. Dieses Muster aus Entwurf/Entwicklung/Benutzung ändert sich nicht sehr, sondern ist ein branchenübliches Vorgehen, das so oder so ähnlich verwendet wird. Und wie andere vergleichbare Muster lässt es sich sehr schön in einem Spring-Boot-Starter festhalten.

Das Hinzufügen eines einzigen Starters, z.B. spring-boot-starter-web, fasst alle dazugehörigen Funktionalitäten in einer einzigen Anwendungsabhängigkeit zusammen. Alle Abhängigkeiten, die in diesem einen Starter enthalten sind, sind darüber hinaus versionssynchronisiert. Das heißt, sie wurden erfolgreich zusammen getestet, und die enthaltene Version von Bibliothek A funktioniert einwandfrei mit der enthaltenen Version von Bibliothek B … und C … und D und so weiter. Dadurch wird unsere Liste mit den Abhängigkeiten und damit unser Leben drastisch vereinfacht, da es ziemlich unwahrscheinlich wird, dass schwer zu identifizierende Versionskonflikte zwischen Abhängigkeiten auftreten, die Sie für die wichtigen Funktionen Ihrer Anwendung zur Verfügung stellen müssen.

In den seltenen Fällen, in denen Sie Funktionalität einbauen müssen, die von einer anderen Version einer enthaltenen Abhängigkeit bereitgestellt wird, können Sie die getestete Version einfach übergehen.

Falls Sie sich über die vorgegebene Version einer Abhängigkeit hinwegsetzen müssen, dann tun Sie das … allerdings sollten Sie dann wahrscheinlich Ihre Tests ausweiten, um die Risiken auszuschalten, die Sie sich durch Ihr Vorgehen möglicherweise einhandeln.

Sie können Abhängigkeiten, die für Ihre Anwendung unnötig sind, auch ausschließen. Dabei gelten allerdings dieselben Vorsichtsmaßnahmen.

Alles in allem rationalisiert das Starter-Konzept von Spring Boot Ihre Abhängigkeiten und verringert den Aufwand, der nötig ist, um ganze Gruppen von Fertigkeiten in Ihre Anwendungen einzubauen. Es verringert außerdem den für Tests, Wartung und Aktualisierung anfallenden Overhead.

Ausführbare JARs für ein vereinfachtes Deployment

Vor langer, langer Zeit, als Application-Server über die Erde streiften, waren Deployments von Java-Anwendungen eine komplexe Angelegenheit.

Um eine funktionierende Anwendung mit z.B. Datenbankzugriff auf den Weg zu bringen – wie bei vielen Microservices heutzutage und fast allen Monolithen damals und heute –, müssten Sie Folgendes tun:

1. Installieren und Konfigurieren des Application-Servers
2. Installieren der Datenbanktreiber
3. Erzeugen einer Datenbankverbindung
4. Erzeugen eines Connection Pools
5. Kompilieren und Testen Ihrer Anwendung
6. Deployment Ihrer Anwendung und deren (meist zahlreichen) Abhängigkeiten auf dem Application-Server

Diese Liste geht übrigens davon aus, dass Administratoren die Maschine/virtuelle Maschine für Sie konfigurieren und Sie irgendwann einmal unabhängig von diesem Prozess die Datenbank erzeugt haben.

Spring Boot stellte einen Großteil dieses schwerfälligen Deployment-Prozesses auf den Kopf und fasste die genannten Schritte zu einem einzigen Schritt zusammen – vielleicht auch zwei, falls Sie das Kopieren oder Verschieben einer einzelnen Datei (mit cf push) als tatsächlichen Schritt betrachten wollen.

Spring Boot war nicht der Ursprung des sogenannten Über-JAR, hat es aber revolutioniert. Anstatt jede Datei aus dem Anwendungs-JAR und allen abhängigen JARs herauszukitzeln, sie dann zu einem einzigen Ziel-JAR zu kombinieren – ein Vorgang, der manchmal als Shading bezeichnet wird –, gingen die Entwickler von Spring Boot die Sache von einer ganz neuen Seite an: Was wäre, wenn wir JARs schachteln und dabei ihr vorgesehenes und übergebenes Format beibehalten könnten?

Das Schachteln von JARs anstelle des Shading behebt viele potenzielle Probleme, da uns keine etwaigen Versionskonflikte begegnen werden, wenn Abhängigkeit JAR A und Abhängigkeit JAR B jeweils eine andere Version von C benutzen; es lässt auch potenzielle rechtliche Probleme verschwinden, die auftreten, wenn man Software neu packt und sie mit anderer Software kombiniert, die eine andere Lizenz verwendet. Behält man alle abhängigen JARs in ihrem Ursprungsformat, dann vermeidet man ganz geschickt diese und andere Probleme.

Es ist außerdem trivial, den Inhalt eines ausführbaren JAR in Spring Boot zu extrahieren, sollten Sie dies wünschen. Unter bestimmten Umständen gibt es gute Gründe dafür, und ich werde darauf in diesem Buch eingehen. Für den Augenblick reicht es, zu wissen, dass das ausführbare JAR in Spring Boot für Sie da ist.

Das einzelne Spring-Boot-JAR mit all den Abhängigkeiten macht das Deployment zu einem Kinderspiel. Anstatt alle Abhängigkeiten zu sammeln und sicherzustellen, dass sie deployt werden, sorgt das Spring-Boot-Plug-in dafür, dass sie in das Ausgabe-JAR eingebunden werden. Ist das erledigt, kann die Anwendung überall ausgeführt werden, wo es eine Java Virtual Machine (JVM) gibt. Es reicht, dazu einen Befehl wie java -jar <SpringBootAppName.jar> auszuführen.

Da gibt es aber noch mehr.

Durch Einstellen einer einzigen Eigenschaft in Ihrer Build-Datei kann das Spring-Boot-Build-Plug-in dieses eine JAR vollständig (selbst) ausführbar machen. Immer noch unter der Voraussetzung, dass es eine JVM gibt, müssen Sie nun nicht die ganze lästige Zeile java -jar <SpringBootAppName.jar eintippen, sondern können die Ausführung mit einem einfachen <SpringBootAppName.jar> erreichen (natürlich müssen Sie hier Ihren eigenen Dateinamen einsetzen) – das war es auch schon. Einfacher geht es wirklich nicht.

Autokonfiguration

Die Autokonfiguration, die Spring-Boot-Neulingen manchmal wie Zauberei erscheinen mag, ist vielleicht der größte »Machtmultiplikator«, den Entwickler durch Spring Boot gewinnen. Ich bezeichne sie oft als die Superkraft eines Entwicklers: Spring Boot gibt Ihnen wahnsinnige Produktivität, indem es Meinungen zu weit verbreiteten und oft wiederholten Use Cases äußert.

Meinungen in Software? Und das hilft?!?

Wenn Sie schon lange als Entwickler unterwegs sind, dann haben Sie zweifellos bemerkt, dass sich manche Muster oft wiederholen. Natürlich nicht perfekt, aber zu einem großen Teil; vielleicht 80 bis 90 Prozent der Zeit bewegen sich die Dinge in einem bestimmten Bereich aus Design, Entwicklung oder Aktivität.

Ich habe bereits auf diese Wiederholung in der Software hingedeutet, da sie es ist, die Spring-Boot-Starter so unglaublich konsistent und nützlich macht. Wiederholung bedeutet auch, dass sich diese Aktivitäten, wenn wir dann zu dem Code kommen, der zum Erledigen einer bestimmten Aufgabe geschrieben werden muss, hervorragend für eine Rationalisierung anbieten.

Um einmal ein Beispiel aus Spring Data zu borgen, ein mit Spring Boot verwandtes und durch Spring Boot ermöglichtes Projekt: Wir wissen, dass wir jedes Mal, wenn wir Zugriff auf eine Datenbank benötigen, irgendeine Art von Verbindung zu dieser Datenbank öffnen müssen. Wir wissen außerdem, dass diese Verbindung geschlossen werden muss, wenn unsere Anwendung ihre Aufgaben erledigt hat, um potenzielle Probleme zu vermeiden. Zwischen dem Öffnen und Schließen richten wir wahrscheinlich zahlreiche Anforderungen an die Datenbank, für die wir Abfragen benutzen – einfache und komplexe, schreibgeschützte und schreibbare. Die korrekte Erstellung dieser Abfragen erfordert eine gewisse Mühe.

Stellen Sie sich nun vor, wir könnten all das rationalisieren. Automatisch eine Verbindung öffnen, wenn wir die Datenbank angeben. Automatisch die Verbindung schließen, wenn die Anwendung fertig ist. Einfachen und erwarteten Konventionen folgen, um mit minimalem Aufwand Ihrerseits automatisch Abfragen zu erzeugen. Wieder durch eine einfache Konvention eine einfache Anpassung selbst dieses minimalen Codes erlauben, um komplexe, spezialisierte Abfragen zu erzeugen, die zuverlässig konsistent und effizient sind.

Diese Herangehensweise an Code wird manchmal als Konvention vor Konfiguration bezeichnet und kann auf den ersten Blick irritierend wirken, wenn eine bestimmte Konvention Ihnen neu ist. Falls Sie jedoch vorher schon einmal Ähnliches implementiert haben und viele Hundert Zeilen lang den immer wieder gleichen Setup/Teardown/Konfigurationscode schreiben mussten, um selbst die einfachen Aufgaben zu erledigen, dürfte dies sehr erfrischend sein. Spring B...