Dieses Projekt ist an der BFH im Rahmen des Moduls "BTI7515 - Software Entwicklung Open Source 1" unter Leitung von Roger Villars entstanden.
- Aufgrund eines einfachen UML Domain Models ist mit den im Modul besprochenen Technologien eine kleine Applikation zu bauen.
- Fokus der Applikation ist die Microservice-Architektur. Das Frontend ist irrelevant.
- Technology Stack:
- Git
- Maven
- Spring, Spring Boot, Spring MVC/REST, Spring Core, Spring Cloud
- HAL Browser
- Netflix OSS: Eureka, Ribbon, Feign, Zuul, Hystrix, Turbine
- Docker
- Es ist eine Dokumentation inkl. Reflexion (dieses readme.md) zu erstellen.
31.01.2018
Diese Applikation zeigt die Arbeit mit Microservices anhand eines simplen Addressbuches. Personen und Firmen fallen unter den Oberbegriff "Partner". Addressen, Emails, Telefonnummern unter "Contact".
Derzeit läuft die Applikation noch nicht fehlerfrei. Kopfzerbrechen bereiten uns:
- Docker
- Verknüpfen der Daten mit Feign Client im Partner-Contact-Service
Vorbedingung:
- Java 8 (zu Java 9 siehe unten)
- Maven
- Docker
Starte jede Spring-Boot Applikation im jeweiligen Directory mit mvn spring-boot:run (einigermassen praktisch im integrierten Terminal von IntelliJ).
Dabei muss folgende Reihenfolge eingehalten werden:
- registry-service
- partner-service
- contact-service
- partner-contact-service
- frontend-service
Im root Verzeichnis findet sich ein Docker-Compose File. Es genügt, mit docker-compose up zu starten. Die Anzahl Instanzen pro Service kann über das Flag --scale bestimmt werden, z.B. docker-compose up --scale partner-contact=5 um 5 Instanzen des partner-contact-services zu generieren.
Es stehen folgende Endpoints zur Verfügung:
- http://localhost:1111 Eureka
- http://localhost:2222 Partner-Service (HAL Browser)
- http://localhost:3333 Contact-Service (HAL Browser)
- http://localhost:4444 Partner-Contact-Service (HAL Browser)
- http://localhost:8080/partners Frontend-Service für Partner-Service (HAL Browser)
- http://localhost:8080/contacts Frontend-Service für Contact-Service (HAL Browser)
- http://localhost:8080/partnercontacts Frontend-Service für Partner-Contact-Service (HAL Browser)
- http://localhost:9999/hystrix Hystrix Dashboard
Beim Aufteilung der App in verschiedene Services, haben wir uns an der Demo des Moduls orientiert:
| Service | Zweck | Dependencies |
|---|---|---|
| registry-service | Findet Microservices. |
|
| partner-service
contact-service |
Verwaltet die Entities Person und Company unter dem Oberbegriff "Partner" resp. Address, Phone und Email unter "Contact". Persistenz, REST, HAL-Browser. |
|
| partner-contact-service | Bietet Zugriff auf die Verknüpfung von Contacts und Partners. |
|
| frontend-service | Reverse Proxy, welcher Zugriff auf partner-service, contact-service und partner-contact-service bietet. |
|
| monitoring-service | Überwachen des Gesundheitszustandes der Microservices inkl. Dashboard. |
|
Bei der Umsetzung der Applikation sind wir mit verschiedensten Schwierigkeiten konfrontiert worden.
Das Thema dieser Applikation ist jenem des Moduls sehr ähnlich. Zur Zeit der Einreichung des UML Domain Models wurde im Modul anhand einer Book App demonstriert. Bald wurde dies aber zu einer Person Address Applikation.
Das finale Domain Model entspricht nicht dem ursprünglich geplanten. Zum Zeitpunkt der Festsetzung eines Domain Models war uns noch nicht genügend bewusst, dass eine Micro-Services Architektur angestrebt wird - und was dies bedeutet. Daher besteht das ursprüngliche Domain Model aus Klassen, die sehr stark Verknüpft sind.
Ursprünglich geplantes Domain Model:
Aufgrund der Vielfalt an neuen Technologien und verschieden Möglichkeiten derer Integration ist ursprünglich unklar gewesen, wie die Lösung aufgebaut sein soll. Parallel zur Vorlesung haben wir jeweils versucht die App zu bauen, diese jedoch mit neu hinzukommenden Technologien jedoch wieder verworfen.
Für den Überblick hilfreich sind die regelmässigen Übungen inklusive der Beispiel-Lösungen gewesen (siehe SWOS Microservices 171207).
Die Installation von Docker auf Windows 10 ist vorerst gescheitert.
Das Vorgehen war, wie offiziell beschrieben:
- Hyper-V und Containser aktivieren (PowerShell:
Enable-WindowsOptionalFeature -Online -FeatureName containers –AllundEnable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V –All) und Restart. - Download und Installation von Docker.
Folgender Fehler ist aufgetreten:
Diese Problem scheint seit einem kürzlichen Update von Windows 10 bei vielen Usern aufzutreten. Die Emotionen gehen hoch. Verschiedenste Lösungen werden präsentiert. Für uns war folgender Tipp hilfreich:
Navigating to C:\Users\Public\Documents\Hyper-V\Virtual hard disks\ and requesting access, then restarting the Docker for Windows service fixed the issue for me. tsasioglu
Bei der Entwicklung ist IntelliJ IDEA verwendet worden. Der Vorteil (neben den üblichen Benefits von IntelliJ) ist die simple Integration von Maven (automatisches Importieren von Dependencies) und Spring-Boot (Initializr).
Jeder Service ist als eigenständiges IntelliJ IDEA Project erstellt worden. Sie befinden sich alle in einem gemeinesamen Verzeichnis. Dieses enthält zusätzlich ein übergeordnetes .POM, welches die einzelnen Spring-Boot Projekte als Module referenziert und ein Docker-Compose File.
Dies entspricht unserer Meinung nach der Idee, dass Microservices von verschiedenen Teams gebaut und gepflegt werden. Somit sollte es sich um verschiedene Projekte handeln. Zudem ist dies mit IntelliJ die angenehmste Variante: Jedes Projekt kann mit dem integrierten Initializer erstellt werden.
Folgendes Problem hat uns einige Zeit geraubt:
Grund: Gewisse Spring-Boot Starters verwenden JAXB. In JAVA 8 ist JAXB in der SE enthalten. In JAVA 9 jedoch ist dies nur noch über EE erhältlich. Der Einfachheit halber ist JAVA 8 verwendet worden.
(Danke an rvillars für den Tipp. Siehe auch Stackoverflow)
Applikation nicht mehr fehlerfrei mit docker-compose up starten. Ein Blick auf docker info deutet darauf hin, dass die Container resp. Images nicht sauber entfernt wurden. Daher immer beenden mit docker-compose down.
Immer wieder begegnen wir beim Starten einer Fehlermeldung com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused: connect. Leider bislang keine Lösung gefunden.
Das Verknüpfen der Daten im Partner-Contact-Service bereitet einiges an Kopfzerbrechen. Dies insbesondere weil nun nicht mehr nur eine Entität pro Service bezogen wird. Es scheint Probleme beim Aufrufen der API URL zu geben. Offenbar haben wir diese noch nicht korrekt in der jeweiligen Annotation in den Clients erfasst. Die URLs für die REST Abfragen im Partner-Service und Contact-Service werden automatisch durch die verwendeten Starters generiert. Die Bezeichnungen scheinen auch pluralisiert zu werden. (Reading). Diese Unklarheiten haben viel Zeit gekostet und sind noch nicht vollständig gelöst.
Wir erwarten, über die URL http://localhost:8080/partners/ auf den Partner-Service zugreifen zu können. Dies funktioniert jedoch nicht. Stattdessen erhalten wir den erwarteten HAL Browser über http://localhost:8080/partner-service/. Stattdessen begrüsst uns eine Whitelabel Error Page.
Wenn wir jedoch (anders als in der Demo) im application.yml des Frontend-Service zuul.routes.partner-service.stripPrefix:true setzen, so werden wir erfolgreich über http://localhost:8080/partners/browser/index.html#/partners/ mit dem Partner-Service HAL Browser verbunden.
Dasselbe gilt natürlich auch für den Contact-Service und den Partner-Contact-Service.
Wir sind beide beruflich im Kontext von C#, .NET, respektive ASP.NET tätig. Sowohl punkto C# als auch Java sind die Levels unterschiedlich. Die Welt von Spring-Boot, Netflix OSS, Maven und Docker weicht doch einiges von den Erlebnissen mit .NET ab. Einige kleine Feststellungen:
- Spring-Boot scheint Meister im Vermeiden von Scaffolding zu sein. Es genügen einige wenige Annotationen auf Klassen oder Funktionen, um Service Discovery, Monitoring, Domain Entities, Repositories, RestServices usw. nutzen zu können.
- Es wird einiges an Flexibilität und Einfachheit geboten. So genügt es, ein SQL File in den Resources zu hinterlegen um Seed Data konsumieren zu können.
- Diese Einfachheit bedingt gleichzeitig ein sehr hohes Level an Standards. Spring-Boot ist stark opinionated. Dies ist einerseits eine grosse Erleichterung um schnell ein etwas Simples aufbauen zu können. Andererseits ist wird der Blick auf die Konfigurationsmöglichkeiten so jedoch etwas verschleiert. Zudem scheint es für jedes Problem mehrere sehr gut geeignete Lösungen zu geben. Für ein komplexeres Problem, wie mehrere Microservices die zusammenarbeiten sollen, führt dies schnell zu einer Vielzahl an möglichen Lösungen. Dieses Problem anzugehen, erfordert also ein gutes Verständnis des Zusammenspiels der Tools und stellt somit eine gewisse Lernkurve.
- Maven im Sinne eines Repositories an Tools erinnert stark an die Nugets der .NET Welt. Beiderorts kann Verwendung mehrere solcher schnell zu komplexen Abhängigkeiten führen. Die Spring-Boot Startes liefern hier eine sehr schöne, einfache Hilfestellung.
- Der Tool-Stack von Spring und Netflix OSS ist beeindruckend. Auch hier die Einfachheit im Einzelnen und die Komplexität durch die grosse Menge an Tools, die zusammen spielen können.