Ein Leitfaden für Java-Microservices. Teil 2: Bereitstellung und Tests

Übersetzung und Anpassung von Java Microservices: Ein praktischer Leitfaden . Link zum ersten Teil des Leitfadens . Jedes serverseitige Java-Programm und damit jeder Microservice ist lediglich eine Datei mit der Erweiterung .jar oder .war. Es gibt eine großartige Sache am Java-Ökosystem bzw. der JVM: Sie müssen Java-Code nur einmal schreiben und er kann auf fast jedem Betriebssystem ausgeführt werden, solange Sie Ihren Code nicht mit einer neueren Java-Version als Ihrem kompiliert haben Ziel-JVM-Version. Dies ist wichtig zu verstehen, insbesondere wenn es um Themen wie Docker, Kubernetes oder (Trommelwirbel!) Die Cloud geht. Warum? Schauen wir uns verschiedene Bereitstellungsszenarien an.

Beispiel für eine minimalistische Java-Microservice-Bereitstellung

Fahren wir mit dem Bankbeispiel fort. Wir haben also eine monobank.jar-Datei (Monolith) und unsere neu extrahierte riskengine.jar (den ersten Mikroservice zur Risikoprüfung). Nehmen wir außerdem an, dass beide Anwendungen, wie jede andere Anwendung auf der Welt, eine .properties-Datei benötigen. In unserem Fall enthält es nur die Datenbank-URL und die Anmeldeinformationen. Eine minimale Bereitstellung könnte aus zwei Verzeichnissen bestehen, die etwa so aussehen: Erstens:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 monobank-384.jar

ubuntu@somemachine:/var/www/www.monobank.com/java$ java -jar monobank-384.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Zweite:

-r-r------ 1 ubuntu ubuntu     2476 Nov 26 09:41 application.properties
-r-x------ 1 ubuntu ubuntu 94806861 Nov 26 09:45 risk-engine-1.jar

ubuntu@someothermachine:/var/www/risk.monobank.com/java$ java -jar risk-engine-1.jar

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
...

Damit bleibt die Frage offen: Wie gelangen die .properties- und .jar-Dateien auf den Server? Leider kann es viele Antworten geben.

So verwenden Sie Build Tools, SSH und Ansible zum Bereitstellen von Java Microservices

Langweilige, aber nicht minder hervorragende Ratschläge zur Bereitstellung von Java-Microservices ... Eigentlich genau so, wie Systemadministratoren in den letzten 20 Jahren jedes Java-Serverprogramm in Unternehmen bereitgestellt haben. Das ist die Mischung:

• Ihr Lieblings-Build-Tool (Maven, Gradle)
• gutes altes SSH/SCP zum Kopieren von .jars auf Server
• Bash-Skripte zum Verwalten von Bereitstellungsskripten und Servern
• oder noch besser: einige Ansible-Skripte.

Dies ist natürlich nicht für Innovatoren geeignet, die eine „atmende“ Cloud, Server mit automatischem Lastausgleich usw. benötigen. Das ist wirklich langweilige alte Schule. Aber es funktioniert!

So verwenden Sie Docker zum Bereitstellen von Java-Microservices

Kehren wir zurück zur süßen Qual der Wahl. Vor ein paar Jahren kam Docker auf den Plan und damit auch die Containerisierung. Wenn Sie noch nie damit gearbeitet haben, finden Sie hier eine kurze Beschreibung für Endbenutzer und Entwickler:

• Ein Container (vereinfacht) ähnelt der guten alten virtuellen Maschine, ist aber „leichter“. Wenn Sie sich nicht sicher sind, was „einfacher“ in diesem Zusammenhang bedeutet, lesen Sie bitte diese Antwort auf Stackoverflow .
• Der Container garantiert seine eigene Tragbarkeit. Das heißt, es funktioniert überall. Kommt Ihnen bekannt vor, nicht wahr?

Es ist lustig, dass diese Funktion angesichts der Portabilität und Abwärtskompatibilität der JVM kein so großer Vorteil zu sein scheint. Sie können JVM.zip einfach auf einen beliebigen Raspberry Pi (oder sogar ein Mobiltelefon) herunterladen, es extrahieren und eine beliebige .jar-Datei ausführen. Die Situation ändert sich in Sprachen wie PHP oder Python, wo Versionsinkompatibilitäten oder Bereitstellungseinstellungen komplexer sind. Oder wenn Ihre Java-Anwendung von vielen anderen installierten Diensten (mit den richtigen Versionsnummern) abhängt: zum Beispiel einer Postgres-Datenbank oder einem Redis-Schlüsselwertspeicher. Der Hauptvorteil von Docker für Java-Microservices, oder genauer gesagt für Java-Anwendungen, ist also dieser: die Möglichkeit, homogenisierte Test- oder Integrationsumgebungen mithilfe von Tools wie Testcontainers einzurichten . Komplexe Entwicklungen lassen sich einfacher installieren. Nehmen Sie die Forensoftware Discourse . Sie können es mit einem einzigen Docker-Image installieren, und dieses Image enthält alles, was Sie brauchen, von der in Ruby geschriebenen Discourse-Software über eine Postgres-Datenbank bis hin zu Redis und der Küchenspüle. Wenn Ihre Bereitstellungen ähnlich sind oder Sie eine schöne kleine Oracle-Datenbank ausführen möchten, versuchen Sie es mit Docker. Um es zusammenzufassen: Anstatt nur die .jar-Datei anzusehen, können Sie jetzt Folgendes tun:

• Bündeln Sie Ihre JAR-Datei in einem Docker-Image
• Schieben Sie dieses Image in eine private Docker-Registrierung
• Ziehen Sie dieses Image herunter und führen Sie es auf Ihrer Zielplattform aus
• Oder kopieren Sie das Docker-Image direkt auf Ihr Produktionssystem und führen Sie es aus.

So verwenden Sie Docker Swarm oder Kubernetes zum Bereitstellen von Java-Microservices

Nehmen wir an, Sie entscheiden sich, Docker auszuprobieren. Jedes Mal, wenn Sie einen Java-Microservice bereitstellen, erstellen Sie ein Docker-Image, das Ihre .jar-Datei bündelt. Nehmen wir an, Sie verfügen über einige dieser Java-Microservices und möchten diese Services auf mehreren Computern (in einem Cluster) bereitstellen. Es stellt sich die Frage: Wie verwaltet man diesen Cluster? Docker-Container ausführen, Leistung prüfen, Updates bereitstellen, System skalieren (brrr)? Zwei mögliche Antworten auf diese Frage sind Docker Swarm und Kubernetes. Auf beide Optionen im Detail einzugehen, würde dieses ohnehin schon lange Tutorial zu lang machen, aber wir halten es für wichtig zu erwähnen, dass beide Optionen letztendlich davon abhängen, dass Sie YAML-Dateien schreiben (siehe Yaml-Einrückungsgeschichten ), um Ihren Cluster zu verwalten. Wenn Sie wissen möchten, welche Gefühle das in der Praxis hervorruft, geben Sie einfach eine ähnliche Suchanfrage in die Twitter-Suche ein. Der Bereitstellungsprozess für Ihre Java-Microservices sieht nun etwa so aus:

• Konfigurieren und Verwalten von Docker Swarm/Kubernetes
• Alle Schritte für Docker (siehe oben)
• Schreiben Sie YAML und führen Sie es aus , bis Ihnen die Augen bluten, bis alles funktioniert.

So testen Sie Java-Microservices

Nehmen wir an, Sie entscheiden sich für die Implementierung von Microservices in der Produktion. Wie können wir die N-Microservices-Integration jetzt während der Entwicklung testen? Wie können Sie sehen, ob der gesamte Workflow funktioniert und nicht nur Teile davon? In der Praxis können Sie eine von drei Methoden verwenden:

1. Mit ein wenig Aufwand (wenn Sie Frameworks wie Spring Boot verwenden) können Sie alle Ihre Microservices in einer Startklasse kombinieren und alle Microservices mit einer einzigen Wrapper.java-Klasse laden – je nachdem, ob auf Ihrem Computer genügend Speicher dafür vorhanden ist Führen Sie alle Ihre Microservices aus.
2. Sie können Docker Swarm- oder Kubernetes-Einstellungen lokal kopieren.
3. Führen Sie Integrationstests einfach nicht mehr lokal durch. Stellen Sie stattdessen eine dedizierte DEV/TEST-Umgebung bereit. Dies ist etwas, was viele Teams tatsächlich tun, wenn sie den Schmerzen lokaler Microservice-Setups erliegen.

Zusätzlich zu Ihren Java-Microservices benötigen Sie wahrscheinlich auch einen laufenden Nachrichtenbroker (wie ActiveMQ oder RabbitMQ) oder möglicherweise einen E-Mail-Server oder eine andere Messaging-Komponente, die Ihre Java-Microservices für die Kommunikation untereinander benötigen. Dies führt zu einer deutlichen Unterschätzung der Komplexität auf der DevOps-Seite. Werfen Sie einen Blick auf Microservice Testing Libraries, sie können dieses Problem lindern. Auf jeden Fall bringt uns diese Komplexität zu den allgemeinen Problemen von Microservices, über die wir gleich sprechen werden. Im letzten Teil werden wir allgemeine Fragen zu Java-Microservices behandeln.