4 Minuten Lesezeit (880 Worte)

Microservices: Mit Eclipse MicroProfile zu leichtgewichtigen verteilten Java EE Microservices (Teil 2)

Donnerstag, 01. August 2019

Mit Eclipse MicroProfile steht ein Quasistandard zur Verfügung, der die Implementierung von Microservices erheblich vereinfacht, ohne den bewährten Java-EE-Standard aufzugeben.

Microservice-Architektur im Java-EE-Umfeld

Um monolithische Strukturen zu vermeiden, ist es naheliegend, die Themen fachlich passend zu schneiden und auf einzelne Self-Contained-Systems- Microservices (SCS-Microservices) zu verteilen. Mit Domain-Driven-Design (DDD) gelingt dies. DDD bietet mit Bounded Context ein Konzept, um Fachdomänen voneinander abzugrenzen. Hinzu kommt, dass die Entwickler und die Fachabteilungen intensiver zusammenarbeiten (müssen), um die Microservices passend schneiden zu können. Die Fachlichkeit rückt in den Vordergrund und die Technik eher in den Hintergrund. Ein Microservice soll so klein sein, dass bei Änderung der Fachlichkeit dieser kann durch eine Neuimplementierung ausgetauscht werden kann ohne zeitaufwendige Test- und Refactoring-Runden.

Um die Abhängigkeit der Microservices zu minimieren, wird jeder Microservice auf einem eigenen Application Server betrieben. Die Kommunikation der Services untereinander wird über das Netzwerk betrieben.

Dieses Vorgehen hat aber den Nachteil, dass der Overhead (ein kompletter Application Server) pro Service sehr groß ist, da nicht jeder Service alle Komponenten aus dem Application Server benötigt. Es entsteht außerdem ein hoher Aufwand für Systemkonfiguration, Deployment und Management der einzelnen Services. Hinzu kommt der Aufwand für das Monitoring der vielen Server/Services. Da jeder Service auf einem eigenen Application Server läuft, braucht jeder Service/Application Server eine eigene Konfiguration, u.a. Netzwerkeinstellungen (IP und Port für den eigenen Service und IPs und Ports für die Services, mit dem er kommuniziert), ein eigenes Deployment und seine eigenen Logging- und Monitoring-Einstellungen.

Um all diese Herausforderungen zu meistern, wurde das Eclipse MicroProfile gegründet. Die Idee dahinter ist, einen abgespeckten Application Server (ohne Overhead) betreiben zu können und APIs bereitzustellen, die die Herausforderungen der Pflege und Überwachung der verteilten Server/Services vereinfachen.

Eclipse MicroProfile APIs

Im Java-EE-Umfeld gibt es schon viele erprobte Konzepte, um Software modular zu gestalten, wie beispielsweise CDI. Allerdings fehlen Konzepte, die speziell auf verteilte Systeme und ihre Anforderungen zugeschnitten sind. Hierfür wurden die Eclipse MicroProfile APIs entwickelt (siehe Abbildung 3).

Durch den Einsatz von JAX-RS und JSON-P kann die Kommunikation zwischen den einzelnen Services über REST-Schnittstellen im JSON-Format umgesetzt werden.

Um die einzelnen Services an die jeweilige Umgebung (Dev, Test, Prod) von außjen anpassen zu können, wurde die Config-API eingeführt.

Die Konfiguration der einzelnen Services wird durch den Einsatz der Config-API erleichtert. So können Konfigurationen auf unterschiedlichen Ebenen eingesetzt werden. Die Reihenfolge ist wie folgt:

System.getProperties()
System.getenv()
META-INF (microprofile-config.properties-Dateien, die im ClassPath liegen)

Ein Überblick über die Systemgesundheit aller verteilt laufenden Services kann durch den Einsatz von Health Checks und Metrics APIs erstellt werden. Mit der Health Check API kann von außen festgestellt werden, ob ein Service noch so läuft, wie geplant. Die API stellt einfache Health-Endpoints zur Verfügung, die bei einem Aufruf mit einer Statusmeldung "UP" oder "DOWN" oder mit einem Netzwerkfehler antworten.

Die Informationen aus den Health-Endpoints können benutzt werden, um Services über Tools wie beispielsweise Kubernetes (https://kubernetes.io) automatisch neu zu starten.

Die Metrics API liefert Detailinformationen über einen einfachen Health-Check hinaus. So lassen sich durch Langzeitmessungen Tendenzen des Speicherverbrauchs vorhersagen. Außerdem kann man durch das permanente Auswerten von Antwortzeiten schleichende Verschlechterungen frühzeitig erkennen. Um auf Fehlersituationen in verteilten Systemen besser reagieren zu können, wurde die Fault Tolerance API hinzugefügt. Sie enthält unter anderem Hystrix (https://github.com/Netflix/Hystrix). Hystrix wird darüber hinaus oft in Spring Microservices eingesetzt und enthält Entwurfsmuster, um die Ausfallsicherheit zu erhöhen.

Um Security einerseits zwischen den einzelnen Services und andererseits zwischen Client und Services umsetzen zu können, wird JWT Propagation eingesetzt. JWT Propagation vereinfacht die Umsetzung von OAuth2, OpenID Connect (OIDC) und JSON Web Tokens (JWT).

Abb. 3: Eclipse MicroProfile 2.0 – Quelle: https://microprofile.io

Die nächsten Themen

Somit haben wir schon einige Hilfsmittel, um Microservices mit Java EE umsetzen zu können. Allerdings sind noch nicht alle Lücken zum Vorreiter Spring geschlossen. So fehlt noch eine Möglichkeit der Service-Discovery. Die Service-Discovery kann mithilfe von Consul (https://www.consul.io/discovery.html) übernommen werden, Consul ist aber nicht im Microprofile aufgenommen. Die Weiterentwicklung folgender Themen wird aktuell
diskutiert:

Long Running Actions
Reactive Streams
Reactive Events
Data Access
Event Data

Fazit

Die Architektur von kleinen selbstständigen Services lässt sich dank MicroProfile auch mit Java EE umsetzen. Die Vorteile der Umsetzung von Microservices mit Java EE sind:

Java EE ist ein Standard, Komponenten können von mehreren Herstellern eingesetzt werden. Die Abhängigkeit zu einem Hersteller wird vermieden.
Der Standard ist gut dokumentiert.
Es gibt viele Entwickler, die Erfahrung in der Verwendung dieses Standards haben.
Der Standard ist stabil – Abwärtskompatibilität ist gewährleistet. Release-Zyklen sind in der Regel größer als ein Jahr, Ausnahme: kürzere Release-Zyklen für Eclipse MicroProfile.
Java-EE-Lösungen sind schon lange am Markt (> 15 Jahre).

Glossar

Domain-Driven-Design (DDD)
DDD wurde 2003 von Eric Evans in seinem gleichnamigen Buch geprägt. Dabei wird die Modellierung von Software im Wesentlichen von den umzusetzenden Fachlichkeiten der Anwendungsdomäne beeinflusst.

Enterprise Application Archive (EAR)
EAR ist ein Dateiformat, welches alle Programm- und Konfigurationsdateien enthält, um eine Applikation auf einem Applikationsserver betreiben zu können.

Java Enterprise Edition (Java EE)
Java EE ist eine Sammlung von Spezifikationen, um Anwendungen auf herstellerunabhängigen Applikationsservern betreiben zu können.

Monolithen
Von einer monolithischen Software Architektur (Monolith) ist die Rede, wenn die funktionalen Elemente in einem einzigen, untrennbaren sowie homogenen Gebilde miteinander verbunden sind.