Microservices mit Java EE - am Beispiel von IBM Liberty

Microservices mit Java EE
am Beispiel von IBM Liberty
ARS Computer und Consulting GmbH
Michael Hofmann, Senior Softwarearchitekt

© ARS Computer und Consulting GmbH 2016
2
Agenda
Microservices – ein paar wichtige Charakteristika...
Microservices – mit Java
Microservices – mit Java EE
Microservices – mit Java EE und IBM WAS Liberty
Microservices – mit Java EE (Ausblick)

3
IBM Redbook: „Microservices Best Practices for Java“
Motivation:
Firmen mit Java EE Entwicklung wollen
Microservices nutzen
Anfänglich wenig Literatur zu Microservices
mit Java, die “roten Faden” aufzeigt
Noch weniger Literatur zu Microservices mit
Java EE
Ziel:
Microservices mit Java und Java EE von
Erstellung bis Produktion

4
Microservices – ein paar wichtige Charakteristika...
Polyglot Persistence (SQL, NoSQL)
Keine Transaktionen über Microservice-Grenzen hinweg (Messaging-
System)
Hoher Verteilungsgrad
 Kommunikation zwischen Microservices (Resilience, Latenz)
 Erhöhter Testaufwand (Verteilungsgrad, Schnittstellen)
Refactoring über Microservices-Grenzen hinweg
Hohe Ansprüche an Betriebsführung
 Packaging, Deployment und Konfiguration
 Logging von Aufrufverläufen zwischen Microservices
 Monitoring
 Unabhängige Skalierbarkeit

5
Agenda
Microservices – nur ein paar wichtige Charakteristika...

6
Microservices – mit Java (1|3)
Polyglot Persistence (SQL, NoSQL)
 SQL
 Java Persistence API (EclipseLink, Hibernate, …), Spring JDBC (JDBC Template), …
 NoSQL
 Spring Data (MongoDB, Neo4J, Elasticsearch, Solr, Redis, Gemfire, Couchbase, Cassandra)
 EclipseLink (JPA Support für MongoDB und Oracle NoSQL (weitere werden folgen))
Messaging-Systeme
 Java Messaging System (JMS) Client
 AMQP
 Spring AMQP, RabbitMQ mit eigenem Java Client
 MQTT
 Eclipse Paho MQTT Client

7
Hoher Verteilungsgrad
 Kommunikation zwischen Microservices (Resilience, Latenz)
 CircuitBreaker
 Netflix Hystrix
 Erhöhter Testaufwand
 Consumer-driven Contract Testing
 JUnit, JMockit, Mockito, REST Assured
 Netflix SimianArmy (z.B. ChaosMonkey)
 Amalgam8

8
Refactoring über Microservices-Grenzen hinweg
 Nicht Java spezifisch, wird aber erleichtert wenn kein polyglot programming vorliegt
 Keine Neuimplementierung von Business Code in anderer Sprache notwendig
 Durchlässigkeit der Entwickler zwischen den Teams höher
 Rad wird in jedem Microservice mit anderer Programmiersprache neu erfunden (Logging, Log-
Format, Security, Utils, ...)
 Entwicklerrichtlinien sind möglich
 Templates für die Erstellung von Microservices sind möglich
 Deployment wird vereinfacht, da es sich immer um ein identisches Deployment-Artefakt
handelt
 Leichtere Betriebsführung wenn identische Systeme verwendet werden (einheitliche Probleme,
einheitliches Skripting, einheitliches Patching, ...)

9
Agenda

10
Microservices – mit Java EE (1|6)
 Als singuläres ausführbares JAR File
 Spring Boot (Tomcat, Jetty, Undertow)
 Wildfly Swarm (JBoss)
 IBM WebSphere Liberty
 Alle 3 Varianten
 Anwendung zusammen mit
 externer Konfiguration (immutable artifact) und
 notwendiger Runtime (Servlet-Container/Java EE Server)
 in minimalisierter Form
 ergänzt um Funktionen für Metrics und Health Care

11
 Minimalisierung
 Spring Boot über Dependency Management (Maven, Gradle)
 Wildfly Swarm und Liberty
 Anwendung analog Spring Boot (Maven, Gradle)
 Zusätzlich Minimalisierung der notwendigen Java EE Runtime
(Analyse der verwendeten Java EE APIs im enthaltenen EAR/WAR)
 Beispiel anhand IBM WAS Liberty (exemplarisch):
 wlp/bin/server package <serverName> --include=minify,runnable --archive=<fileName>.jar
 java -jar <fileName>.jar
 JAR ca. 50-60MB für umfangreiche Anwendung mit versch. Java EE Frameworks
 Liberty Kernel: ca. 11MB

12
 Logging von Aufrufverläufen zwischen
Microservices
 Bei dynamischer Provisionierung können Logs
durch Vernichtung der VM verloren gehen
 Guter Ansatz: Elastic Stack (ELK-Stack)
 Log-Auswertung über Microservice-Grenzen
hinweg notwendig
 einheitliches Log-Format und Log-Level
 Erstellung einer Correlation-ID mit UUID
<featureManager>
<feature>
logstashCollector-1.0
</feature>
</featureManager>
<logstashCollector
source=
"message,trace,garbageCollection,ff
dc,accessLog"
hostName="localhost"
port="5043„
sslRef="mySSLConfig"
/>

13
Hohe Ansprüche an Betriebsführung (am Beispiel WAS Liberty)
 Monitoring mit grundsätzlichem Wirkprinzip:
 Bei welchem Schwellwert wird welche Aktion auf welches Target ausgeführt
 Monitoring (healthManager-1.0/healthAnalyzer-1.0)
 Maximaler Prozentsatz an Request-Timeouts
 Maximale Response-Zeit
 Exzessive Speichernutzung (% von max. Heap-Size über gewissen Zeitraum)
 Potentielle Memory-Leaks
 Führen zu folgenden automatischen Aktionen
 Server Neustart
 Erzeugung Heap oder Thread Dump
 Server zwischen Maintenance Mode hin- und herschalten
 Auf folgenden Targets: Host, Cluster oder Server

14
Hohe Ansprüche an Betriebsführung (am Beispiel WAS Liberty)
 Weitere Monitoring Möglichkeiten (monitor-1.0)
 Sammelt Performanz-Daten zur Laufzeit
 Zur Abfrage mittels JMX oder REST
 Weiteres Feature: adminCenter-1.0 zur Web-Anzeige von
 used heap memory
 loaded classes
 active JVM threads
 CPU usage
 and other metrics, depending on the resource

15
Unabhängige Skalierbarkeit
 Liegt in der Architektur der Microservices
 Kommt aber erst voll zum Tragen, wenn das System von Microservices
automatisch skaliert (autoscaling, dynamic provisioning)
 Nachteil einer statischen Provisionierung
 Anzahl Microservice Instanzen ausgelegt auf peak load (wie oft tritt dieser pro Zeitraum
auf?)
 Microservice Instanzen müssen permanent laufen (load < 10%)
 und mit ihnen die Hosts auf denen sie betrieben werden
 Verschwendung von Speicher, CPU, Energie, Betriebskosten und evtl. Lizenzkosten
 Spring Boot und Wildfly Swarm verlassen sich hier auf die Infrastruktur
(Virtualisierung, Container, Cloud)
 IBM WebSphere Liberty bietet darüber hinaus eigene Zusatzdienste an

16
Agenda

17
Microservices – mit Java EE + IBM WAS Liberty (1|6)
IBM WAS Liberty Features zur Unterstützung von Microservices
Skalierung
 Schnelle Startzeit
 Liberty startet in <5s (Features werden über OSGI bei Bedarf geladen)
 Geänderte Konfiguration zur Laufzeit nachgeladen und angewandt
 Geringer Arbeitsspeicher-Bedarf
 weniger als 60MB für typische Web-Anwendung
 IBM bietet Support für Liberty im Docker Container
 Liberty Collectives und Cluster mit Autoscaling und Dynamic-Routing
 bei Lastspitzen werden automatisch neue Server gestartet/beendet
 und zugleich beim HTTP-Server registriert/deregistriert
Automatische Skalierung im Liberty mit Bordmitteln möglich

18
IBM WAS Liberty Collective

19
IBM WAS Liberty Collective mit Dynamic Routing

20
Skalierungsbeispiel:
 10.000 Members in 50 VMs, somit ~200 Members pro VM
 5 Collective Controllers in eigenen VMs jeweils: 20GB RAM mit 6 CPUs
 Member VM: 64GB RAM mit 16 CPUs (d.h. ~ 320MB RAM pro Member)
 Richtlinie: ca. 50 Hosts pro Collective Controller
 Applikationen pro Server:
 Eine Applikation pro Server: Single Failure, einfaches Tunen der Applikation
 Mehrere Applikationen pro Server: Amortisation der Server Runtime, kleinere Topologie
möglich
 Fazit: „configure as much isolation as you can afford“

21
Liberty elasticity
 Scaling Controller kann Liberty Software auf vorher registrierten Host installieren
und neue Liberty Server bei Bedarf dort erstellen
 Minimales Installationspaket: Liberty Server mit Anwendung (entsprechend
vorheriger Packaging Empfehlung)
 Mehrere Member auf einem Host „wählen“ Host Leader, der als Vertreter mit dem
Scaling Controller kommuniziert
 Host Leader misst Workload des Host und der anderen Member und informiert
Scaling Controller
 Host Leader informiert Member auf seinem Host über Skalierungs-entscheidungen
des Scaling Controllers
 Polyglot Environments: Collective Controller verwaltet:
 StrongLoop Server
 Liberty Server
 Liberty Docker Container

22
<server description="controllerServer">
<featureManager>
<feature>collectiveController-1.0</feature>
<feature>scalingController-1.0</feature>
<feature>dynamicRouting-1.0</feature>
</featureManager>
<collectiveController>
Definition Replica mit allen Controllern
</collectiveController>
<scalingDefinitions>
nach welcher Policy soll wie verfahren werden
</scalingDefinitions>
<dynamicRouting>
Routinginfo wie/wie oft an HTTP-Server
</dynamicRouting>
<server description=„memberServer">
<featureManager>
<feature>collectiveMember-1.0</feature>
<feature>scalingMember-1.0</feature>
<feature>clusterMember-1.0</feature>
</featureManager>
<collectiveMember>
Connect-Info zu Controller
</collectiveMember>
<clusterMember>
Clustername definiert Zugehörigkeit
</clusterMember>

23
Agenda

24
Microservices – mit Java EE (Ausblick)
http://MicroProfile.io

28
Diskussion und Fragen

29
Kontaktinformationen
Für Fragen und weitere Informationen stehe ich Ihnen gerne
zur Verfügung:
Michael Hofmann
michael.hofmann@ars.de
+49 89 32468-2075
ARS Computer und Consulting GmbH
Ridlerstraße 37
80339 München
www.ars.de

30
ARS Computer und Consulting GmbH
ARS Computer und Consulting GmbH ist ein traditionsreiches
IT- und Beratungshaus mit Hauptsitz im Herzen der
bayerischen Landeshauptstadt München.
Mit der Erfahrung seit 1992 unterstützt ARS Kunden bei der
Lösung individueller, komplexer, fachlicher und technischer
Herausforderungen.
Dabei steht der Erfolg der Kunden im Mittelpunkt.
Werthaltig arbeiten, Werte schaffen
– in einer vertrauensvollen Geschäftsbeziehung.
Die Basis dafür bilden die vielfältigen
ARS Beratungs- und Lösungskompetenzen
sowie das tief-technische Know-how.

Microservices mit Java EE - am Beispiel von IBM Liberty

Microservices mit Java EE - am Beispiel von IBM Liberty

Recommended

More Related Content

Viewers also liked

Viewers also liked(20)

Similar to Microservices mit Java EE - am Beispiel von IBM Liberty

Similar to Microservices mit Java EE - am Beispiel von IBM Liberty(20)

More from Michael Hofmann

More from Michael Hofmann(13)

Microservices mit Java EE - am Beispiel von IBM Liberty