ich beschäftige mich grad mit Microservices und Java EE. Ich kapiere nicht, wie man Projekte aufbauen soll. Ich verstehe es so, dass ich in Eclipse zb für jeden Service ein eigenes .war erstelle!? und diese .war dann deploye. Die Services untereinander kommunizieren dann via REST.
Soll das so richtig sein? Kann mir jemand eine kleine Projektstruktur darstellen?
Angenommen ein Programm, dass eine UI hat die Produktdaten aus einer Datenbank holt und speichert. Es können auch Artikel über CSV zb importiert werden.
Da würde ich jetzt ein war für die UI, das mit einem .war für JPA-Datenbank kommuniziert (um die Daten zu lesen, darzustellen) und ein war für den Upload, welches ebenfalls mir dem DB Server über REST die Artikel in die DB schreibt.
Ich würde mich echt freuen wenn mir das jemand darstellen könnte, wäre das in Eclipse jeweils ein eigenes Projekt? Dann müsste ja jedes Projekt eine eigene web.xml etc haben?!
Bin auch bereit paar Euro auf den Tisch zu legen, wenn mir das jemand praxisnah erklären könnte. Hab da ein großes Fragezeichen im Moment, würde mein Programm aber gern in Microservices aufteilen, da mir die Vorteile gefallen
Neues Projekt? Dann würde ich dir Spring Boot nahelegen anstelle von Java EE. Tutorials dazu gibt es haufenweise im Netz. Zusätzlich auch entsprechend gute Libraries (Netflix ist da sehr aktiv!).
Gerade in Bezug auf Orchestrierung nimmt dir das haufenweise Arbeit ab und man kann sehr schnell gute Ergebnisse erzielen.
Warum? Man muss sich erstmal klar werden warum man Microservices haben möchte.
Der letzte Satz ist problematisch. Microservices bieten keine Vorteile, erst recht keine die einem gefallen können. Microservices lösen ein Problem. Die Frage ist nur ob du dieses Problem hast. Microservices bringen in erster Linie Komplexität mit ins Spiel. Sie kosten Latenz. Ein typischer Request geht nun zur UI, wird dann in ein oder mehrere Requests gewandelt, geht dann via http an den Datenservice, dieser nimmt das entgegen, parst, interpretiert, schickt das ganze dann eine Datenbank und bastelt dann daraus JSON, was wieder über die Leitung geschickt wird um dann in der UI entgegengenommen und weiterverarbeitet zu werden. Das kostet Zeit.
Letztens ist auch die Empfehlung von Tomate_Salat problematisch. Bei Microservices ist es egal was man für den einzelnen Service nimmt. JEE mit Spring Boot im Mix sollte kein Ausschlusskriterium sein. Hauptsache die Kommunikation zwischen beiden funktioniert.
Spring Boot ist nicht schlecht und es bringt einiges mit was man für eine MS-Architektur gebrauchen kann. Es ist nur die Frage ob das dein Problem löst und die Kosten wert ist.
Wenn es nur um Buzzwords geht, dann vielleicht Nanoservice oder ganz extrem Picoservice.
Vielen Dank. In erster Linie suche ich eine Technologie oder Struktur mit der ich Programme schnell individualisieren und deployen kann. Hatte dazu mal einen Thread; brauche ein Hauptprojekt dass ich für jeden Kunden anpassen kann, ohne das hauptprojekt kopieren zu müssen sondern nur die Programmteile, die für den Kunden individuell programmiert werden.
Die anderen Programmteile sollen Abhängigkeit zum Standard haben.
Bei microservice könnte ich nur den Service kopieren und individuell anpassen und beim Kunden austauschen.
Und ich sah den Vorteil, dass wenn Service abschmiert der Rest nicht betroffen ist.
Die Kommunikation über Rest zwischen den Services find ich auch aufwändig zu programmieren. Jeder Service braucht da viel Arbeit, daher meine Frage ob ich das richtig verstanden habe.
Ich lass mir auch super gern andere Strukturen nahelegen, die für meinen Fall ausreichend sind. Microservice ist vielleicht mit Kanonen auf Spatzen schießen
Darum geht’s mir nicht. Du kannst auch Microservices in C#, PHP oder sonst was schreiben und mitverwenden. Mir geht es darum, die Dinger möglichst einfach miteinander zusammen spielen zu lassen und da hilft dir Spring Boot einfach enorm! Ich hatte es mal ausprobiert. Dabei hatte ich mehrere Microservices mit Loadbalancing, Service-discovery, session replication und automatischem Gateway in weniger als einem halben Tag aufgesetzt Und dabei enthalten waren glaub noch viele nette out-of-the-box geschenke wie Circuit-Breaker. Sowas wie Server oder Client für die Service-Discovery sind da wenige Zeilen config und eine Annotation. Fertig (wie gesagt: Netflix bietet da einige sehr nützliche libs - von denen ich nicht weiß, ob du das so einfach in JavaEE zur Verfügung hast).
Nope - leider nicht. Spring Boot an sich ist ganz gut dokumentiert und auf deren Seite findet man auch das ein oder andere Beispiel. Aber ich hab mir afair Video-Tutorials davor auf udemy angeschaut gehabt (sind aber halt nicht kostenlos).
hab mir packtpub account getern zugelegt. wie gesagt da bin ich und mein Auftrageber offen, wenn es was kostet und uns weiter bringt, kein Problem. Hatte mir ein Video angesehen, da war mir die Projektstruktur verdammt unklar zudem der da auch noch mit intelliJ gearbeitet hat.
Wie sieht denn eine einfache Projektstruktur in Eclipse zb aus, wenn man Microservices bauen will?
Ein Dynamic Webprojekt als Hauptprojekt mit der UI?
Jeder Service wie DB-Layer, Logik etc dann ein simples Java Project mit den REST API?
Wie werden solche dann deployed? Wenn ich Payara Micro nehme, geht das lokal, aber wenn der mal abschmiert muss alles einzeln gestartet werden → Docker?
Ihr seht fragen über Fragen
Spring Boot ist ja wirklich super! Danke für den Tipp!
Nun stellst sich mir die Frage wie ich 10 Services auf einem linuxserver deploye. Alle einzeln hochfahren und init.d pro Service einrichten oder gibts da was besseres?
Nur wenn du planst, dass jeder Microservice in einem seperaten Container startet.
Aber ganz ehrlich Du solltest dir mal wenigstens das Tutorial durchlesen. Viele deiner Fragen werden darin geklärt. Hier im Forum sich bei den Basics durchzufragen halte ich für nicht effizient…
Welches Problem soll denn gelöst werden? Microservices sind an sich erstmal nur ein Architekturstil der Deployment als technisches Detail auf die Architekturebene hebt und Entkopplung über Netzwerkverkehr erzwingt. Als Vorteil gewinnt man eine hohe Unabhängigkeit zwischen den Services auf Technologieebene, es ist z.B. egal ob ein Service in Go, einer in Kotlin und einer in C++ implementiert ist, solange sich alle über die Schnittstellen einig sind und der Kunde Entwickler für jede Technologie beschäftigen will. Nachteile hat das ganze auch: Bei falschen Schnitt über die Businessdomänen und etwas Hype-drive („das geht auch als Microservice“) hat man sehr schnell einen komplexen Haufen aus abhängigen Services mit einem Zoo aus Technologien und massivem Netzwerkoverhead.
Den Schnitt der Services selbst kann man auch komplett unterschiedlich aufziehen. Von Services mit nur einzelnen Funktionen (sieht man z.B. ab und an im embedded Bereich bei Messdaten), einzelnen Fachservices (Abgrenzung über Domänenkontexte aus dem Domain Driven Design, z.B. so bei Netflix im Einsatz) bis zu Self-Contained Systems mit eigener DB und UI.
Ist das Problem z.B. Versions- oder Releasemanagement, kann man das auch auf Architekturebene in einem Monolithen lösen indem man die wiederverwendbaren Teile als interne Bibliotheken auslagert und pro Kunde eine Anwendung baut bzw indem man pro Kunde einen Zweig in seiner Versionsverwaltung pflegt. Auch da gibt es noch mehr Möglichkeiten und pauschal eine als „beste Lösung“ zu nehmen macht keinen Sinn wenn man das Kundenproblem nicht kennt. 3 Individuelle Releases zu pflegen ist z.B. eine andere Hausnummer als angepasste Software für 500 Automobilprodukte zu liefern, da kommt man dann eher in die Ecke Modellgetriebene Entwicklung und ein git-branch pro Kunde tut es eher nicht mehr
Danke für deine ausführliche Antwort. Das eigentliche Problem ist, dass ich derzeit alle Kundendaten über einen Monolithen abbilde. Stell es dir wie eine Warenwirtschaft vor, die online liegt. Kunden loggen sich ein und können da ihren Lagerbestand verwalten. Artikel importieren, exportieren usw.
Nun dachte ich, ich erstelle für den Import, Export usw einen Microservice, das löst aber nicht mein Problem, dass ich von sagen wir 50 Kunden jeweils 50.000 Artikeldaten, in einer Anwendung speichere.
Microservices wären dahingehend gut, dass ich sage “Export braucht viel resource”, da kann ich noch einen Service dazuschalten. (Wenn weiterhin alle Kundendaten in einem “Portal” bleiben). Updates sind sofort für alle Kunden online. Anwendung kackt nicht ab wenn der Export oder Import schief läuft.
Nun war ein anderer Ansatz (anderer Post) dass ich für jeden Kunden einen eigenen Wildfly Server aufsetzte, also die Kunden sich nicht mehr bei mir einloggen, sondern in der eigens für den Kunden deployten App. Jeder Kunde hätte dann seine eigene App und sein eigenes.
Du solltest dir mal wenigstens das Tutorial durchlesen. Viele deiner Fragen werden darin geklärt. Hier im Forum sich bei den Basics durchzufragen halte ich für nicht effizient…