Ich nehme derzeit an einer Akademie zum Java Fullstack Software Engineer teil. In den kommenden Wochen möchte ich hier meine Mitschrift, so gut es geht, aufzeichnen und mitteilen. Hier ist das, was ich vom ersten Tag in Block 11 (wir springen etwas hin und her) gelernt und behalten habe:
Unterschied zwischen *.war und *.jar File
Im *.war-File ist im Unterschied zum *.jar File kein Tomcat-Server mit drin (auch wenn dies auf der Spring-Boot-Seite so angezeigt wird).
Wir erzeugen spaßeshalber ein *.war Springboot, ändern ein bisschen was, complieren es mit Maven und erhalten wieder ein neues *.war.
Dieses verschieben wir in einen laufenden Tomcat-Server in den Ordner Webapps.
Der Tomcat deployt dann automatisch das war-File:
Beispiel für das Einrichten einer Tomcat Testumgebung mit Docker:
Mit folgendem prinzipiellen Dockerfile können wir einen bestehenden Tomcat-Server runterladen und mit unserem war-File verknüpfen.
ROOT.war ist die Standardanwendung des Tomcatservers:
-----------------------------------
Springcloud
Springcloud bietet verschiedene Dienste in Bezug auf die Organisation einer Containerwelt:
- Gateway (Proxy, Security) (Produktname: Spring Cloud Gateway oder Zuul)
- Namensdienst (Register für die Container) (Produktname: Eureka)
- Failover (Ausfallsicherheit)(Produktname: Hystrix (veraltet) oder resilience4j)
- Lastverteilung (Loadbalancing)(Produktname: Ribbon)
https://spring.io/projects/spring-cloud
Failover mit Hystrix
Hystrix ist eigentlich schon veraltet. Es gibt aber Alternativen:
Wir öffnen unser Beispiel ueb-hystrix in IntelliJ:
Wenn wir es laufen lassen, erscheint folgendes:
Der Service soll ja die Anfrage annehmen und weiterleiten an andere Microservices. Da wir keine haben, sehen wir diese "Fehler-"Meldung.
(Exkurs: Um eine PID herauszufinden, die auf einen Port lauscht, eignet sich folgender Befehl:
netstat -ano
)
-----------
Loadbalancer Ribbon
Ribbon (Ist auch schon veraltet, besser: "Spring Cloud Routing")
https://cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-ribbon.html
Wir öffnen ueb-ribbon in IntelliJ:
In dem user-Projekt in der application.yml werden die Server gelistet, die geloadbalanced werden sollen. (Wäre Eureka aktiv, könnte dieser Namensdienst die Ip-Adressen und Ports zurückgeben, die unter listOfServers dann mit einem Pseudonym beschrieben wären):
Wir starten den Loadbalancer und say-hello und überprüfen, ob es funktioniert:
---------------------------
Gateway / Routing mit Zuul (und einem Exkurs zu Actuator)
Als Tool nehmen wir Zuul (Spring Cloud Gateway).
Gründe: Routing, Security, Filter
Wir starten die Übung Ueb-tempservice in IntelliJ
Metriken (Actuator)
Wir finden in der pom.xml eine Abhängigkeit zu den Metriken (Actuator):
pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
In den application.properties finden wir auch einige gesetzte Schalter:
# Actuator
# https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-features.html
management.endpoint.info.enabled=true
management.endpoints.web.exposure.include=health,info,env,beans,metrics
management.endpoint.health.group.custom.show-components=always
#management.endpoint.health.group.custom.show-components=always
#management.endpoint.health.group.custom.show-details=always
management.endpoints.jmx.exposure.include=*
Wir lassen das Programm laufen, machen ein paar curl-Requests und schauen uns dann das Log an. Der Temperaturservice, welcher Celsius in Fahrenheit und umgekehrt umrechnet, funktioniert:
Hier ist die Beschreibung der Log-Elemente:
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve
Wir sind nun dank Actuator in der Lage viele Systemdetails (Metriken) auszulesen:
curl http://localhost:8888/actuator
curl http://localhost:8888/actuator/health
curl http://localhost:8888/actuator/info
curl http://localhost:8888/actuator/env
curl http://localhost:8888/actuator/metrics
curl http://localhost:8888/actuator/metrics/system.cpu.usage
Man kann diese Daten in Systemmonitoren wie Nagius auswerten und bei Bedarf Events auslösen. Der Actuator zeigt die Systemresourcen, die man auch mit der Java Management Console sehen kann, in Form von JSON Daten über die Web-Schnittstelle.
Zuul
Wir starten jetzt zusätzlich zum bestehenden Service das Projekt "ueb-tempzuul", welcher auf Port 8080 lauscht:
Wir starten den Zuul-Server und greifen mit einem Browser auf Port 8080 zu. Das folgende Bild ist irritierend, da wir beim Zugriff auf den Actuator tatsächlich den vom Zuul erwischen und dessen Metriken sehen:
Aber der Tempservice wird weiter auf Port 8888 geroutet. Das ist der einzige Service der geroutet wird.
zuul.routes.temp.url=http://localhost:8888/tempservice // Durchrouten eines einziges Services @RequestMapping(path="/tempservice") public class TempContoller {
Beispiel für ein Produktionsnetz
In einem Produktionsnetz würden wir noch Ribbon einschalten. Eventuell haben wir drei Pods (virtuelle Rechner) für die Temperatur-Services Ts1, Ts2 und Ts3 mit je einem eigenen Port (und IP-Adresse).
Vom Internet wäre der Zugriff auf Zuul (8080) erlaubt. Dieser würde die Anfrage nach Ribbon (8888) weiterleiten. Jener würde entscheiden, auf welchen der drei Pods letztendlich der User geroutet werden würde:
————————————————-
Disclaimer
Alles was ich mitschrieb und verstanden habe ist ohne Gewähr. Die Bilder stammen teilweise aus dem Internet und wir haben keine Urheberansprüche darauf.
Besten Dank an unseren sehr empfehlenswerten
Trainer: Hans-Joachim Blanke blanke@4point.de
In den nächsten Tagen geht es weiter, so: stay tuned!
Achim Mertens