Strukturplanug Klappe die 2. Microservices zu ModulMonolith

Diskutiere Strukturplanug Klappe die 2. Microservices zu ModulMonolith im Application Tier Bereich.
NicoDeluxe

NicoDeluxe

Hallo zusammen,

in Anlehnung an den Thread hier https://www.java-forum.org/thema/microservices-strukturplanung.188630/
möchte ich einen neuen aufmachen. Und zwar haben sich Dinge ergeben, die uns überlegen lassen ob es nicht doch sinnvoller wäre einen Monolithen zu bauen statt Microservices und Datenbanken tenant zu machen.

Zb kommt eine Lagerverwaltung dazu, später noch Abrechnungen usw. Vermutlich werden einige Customizings anfallen, sodass wir nun überlegen ob ein Monolith nicht doch sinnvoll wäre und jeder Kunde einen kleinen Server bekommt und das Programm drauf statt Microservices.

Nun haben wir es ja so, dass jeder Service separiert ist und alle unter einander mit REST kommunizieren.

Jetzt möchte ich mir da mal einen groben Überblick verschaffen, früher haben wir einen Monolith als .war deployed. Spring Boot hat selbst auch etwas Multi-Module mäßiges an Board wenn ich das richtig sehe, das schau ich mir dann mal genauer an.

Nun ein paar Fragen an euch:

Arbeitet jemand mit Spring Boot und einem Monolith? Wie ist das Programm da aufgebaut, je Service eine jar die in ein war/ear kommen oder werden die Services einzeln deployed? Letzteres wäre mir lieber, ich stelle mir so in etwa vor dass jeder Service unabhängig der anderen Module im Monolithen updated werden kann.

Wie kommunizieren die Services/Module in einem Monolithen am besten? REST eher nicht denk ich, JMS oder ähnliches?
 
NicoDeluxe

NicoDeluxe

Die sind aber schon sehr von einander abhängig oder? Das wollte ich vermeiden
 
MoxxiManagarm

MoxxiManagarm

Die sind aber schon sehr von einander abhängig oder? Das wollte ich vermeiden
Nicht unbedingt. Du hast im Monolith aber typischer Weise mehrere Schichten - ganz unten meist Datenbankqueries, ganz oben die Rest Interfaces. Diese Beans und Services stehen allen Rest Interface Methoden zur Verfügung, welche du nutzt würde ich nicht als Abhängikeit bezeichnen sondern ist deine eigene Wahl. Du kannt gemeinsame Methoden irgendwo in der Mitte definieren oder du verwendest eventuell nur die gleiche Datenbank Query wieder. Da wo es Sinn macht verwendet du Methoden/Beans etc wieder. Du hast hier ganz normal das Ziel duplizierten Code zu vermeiden.
 
mrBrown

mrBrown

Arbeitet jemand mit Spring Boot und einem Monolith? Wie ist das Programm da aufgebaut, je Service eine jar die in ein war/ear kommen oder werden die Services einzeln deployed? Letzteres wäre mir lieber, ich stelle mir so in etwa vor dass jeder Service unabhängig der anderen Module im Monolithen updated werden kann.

Wie kommunizieren die Services/Module in einem Monolithen am besten? REST eher nicht denk ich, JMS oder ähnliches?
Wenn du den Monolithen in einzelne Services teilst, die unabhängig voneinander sind, einzeln deployed werden und über JMS kommunizieren, landest du bei Mikroservices ;)
 
NicoDeluxe

NicoDeluxe

joa hast irgendwie Recht. Wenn da nicht diese dusselige tenante Datenbank wäre und das logging super kompliziert ist wenn bei einem User ein Problem auftritt.

Bei nem Monolithen hat jeder Kunde seinen Server mit dem Programm drauf machts Fehler suchen einfacher und es entstehen keine Netzwerkprobleme (wenn man mit Modulen und Methodenaufrufen arbeitet)
 
MoxxiManagarm

MoxxiManagarm

Ich vermute mal, er hat eine Applikation mit mehreren Teilbereichen, z.B. UserManagement, MetaDatenManagement etc.. Jeder einzelne Bereich hat einen Datenbankuser, oder mehrere.

@NicoDeluxe Bist du dir bewusst, dass es noch etwas anderes gibt zwischen MicroServices und Monolith? Man nennt das SOA. Vielleicht ist das noch was für dich.
 
NicoDeluxe

NicoDeluxe

Was mich stört ist zb: ein Service arbeitet ewig und bespielt die tenante Datenbank. Da wir ja alles über einen zentralen Service leiten (der in die DB speichert) kann man den nicht updated solange der noch gebraucht wird. Die Zeiträume wo der nicht arbeitet sind super kurz. Man könnte das sicher lösen aber nur mit großem Aufwand und dafür sind wir einfach zu wenig Leute.

Wenn du dich erinnerst, hatten wir ja zig verschiedenen Hersteller Services welche die Daten von Herstellern abholen.

jederHersteller Service muss eine preisberechnung machen für alle Daten die er verarbeitet. Derzeit macht das der Master, wenn er die Daten bekommt und speichert.

Wenn wir hingehen und jeden Hersteller Service eine Datenbank geben, müsste ja pro tenant eine Datenbank existieren und das bei jedem Service. Erst dann hätten wir echte Microservices. Dann wäre es einfacher einen Hersteller Updates zu können in dem
Man dem sagt „ keine neuen Daten holen“ Dann arbeitet er nicht und kann updated werden.

dann müsste aber jeder Herstellerservice wiederum die Preiskalkulation kennen (und andere Berechnungen) wenn wir dann an den Berechnungen was ändern, muss das in jedem Service gemacht werden
 
NicoDeluxe

NicoDeluxe

@MoxxiManagarm jupp davon hab ich gelesen. Hab mir inzwischen viele verschiedene Paradigmen abgeschaut von aber nun nur noch verwirrter 😂

kurz gesagt haben wir mehrere Services welche Daten von Herstellern holen und diese für jeden User in einer Db speichern. Vor dem speichern werden Berechnungen angestellt.
Die Daten werden dann aus unserem System von externen abgeholt.
Diese Daten müssen stündlich wieder abgeholt werden und bei uns updated werden.
 
D

Dukel

dann müsste aber jeder Herstellerservice wiederum die Preiskalkulation kennen (und andere Berechnungen) wenn wir dann an den Berechnungen was ändern, muss das in jedem Service gemacht werden
Das geht doch mit Microservices super.
Du hast z.B. Version 1.0 eines Dienstes in einem Container. Startest diesen mehrmals mit Unterschiedlichen Environment Variablen (pro Hersteller oder pro Kunde) und bei einem Update auf die Version 1.1 sagst du deinem Kubernetes, dass es eine neue Version gibt und diese gestartet wird (und nach beendigung der letzten Aktion) wird der alte Container mit 1.0 entfernt.
Optional werden die Container automatisch gestartet und beendet.
D.h. es wird von außen getriggert, es starten x Container für die Kunden oder Hersteller und wenn jeder fertig ist beendet dieser sich wieder.
 
NicoDeluxe

NicoDeluxe

So hab ich das nich nicht gesehen. Meinst du jeder Service startet mit einem Container, pro Kunde einmal, macht seine Arbeit und fährt dann wieder runter? Hmm wie würde der von außen getriggered werden „mach was“
 
mrBrown

mrBrown

Was mich stört ist zb: ein Service arbeitet ewig und bespielt die tenante Datenbank. Da wir ja alles über einen zentralen Service leiten (der in die DB speichert) kann man den nicht updated solange der noch gebraucht wird. Die Zeiträume wo der nicht arbeitet sind super kurz. Man könnte das sicher lösen aber nur mit großem Aufwand und dafür sind wir einfach zu wenig Leute.
Wie in dem anderem Thread schon gesagt: wenn man das asynchron über Events löst, kann man jeden Service beliebig ein- und ausschalten. Wenn der Master offline ist, holt eben niemanden die entsprechenden Events ab, aber das interessiert ja alle anderen Services nicht.

jederHersteller Service muss eine preisberechnung machen für alle Daten die er verarbeitet. Derzeit macht das der Master, wenn er die Daten bekommt und speichert.
Kann doch der Master Problemlos machen? Oder was spricht dagegen?


Ich bezieh mich da auf grob sowas:
Da ist jeder Service einfach updatebar, alle sind voneinander unabhängig.
 
NicoDeluxe

NicoDeluxe

Da hatten wir eine Art Cache wo alle Daten der Hersteller in einer DB beim Service gespeichert werden. Wir haben da einen Hersteller, der schickt 180 MB Daten die wir für jeden Kunden nochmal speichern müssen (jeder Kunde andere Preise, andere Beschreibungen weil die irgendwie lizenzabhängig sind) und dann werden diese rohdaten vom Master nochmal in die „echte“ Datenbank geschrieben (mit den berechneten Werten usw)

da kommt eine Riesen Menge an Daten zusammen. Hab das daauch eingebaut dass mittels Envers Änderungen verfolgt werden- das macht sich super.
Nur hat diese „rohdaten Tabelle“ mit 5 Testkunden gut 4 mio Datensätze :(
 
mrBrown

mrBrown

Da hatten wir eine Art Cache wo alle Daten der Hersteller in einer DB beim Service gespeichert werden. Wir haben da einen Hersteller, der schickt 180 MB Daten die wir für jeden Kunden nochmal speichern müssen (jeder Kunde andere Preise, andere Beschreibungen weil die irgendwie lizenzabhängig sind) und dann werden diese rohdaten vom Master nochmal in die „echte“ Datenbank geschrieben (mit den berechneten Werten usw)

da kommt eine Riesen Menge an Daten zusammen. Hab das daauch eingebaut dass mittels Envers Änderungen verfolgt werden- das macht sich super.
Nur hat diese „rohdaten Tabelle“ mit 5 Testkunden gut 4 mio Datensätze :(
Durch da "Cachen" in jedem Service hast du höchstens die doppelte Datenmenge. Wenn allein das ein Problem ist, würde ich das Problem an anderer Stelle sehen...

Du kannst natürlich auch auf den Cache verzichten, der "Master" muss dann mehr Arbeit machen und es müssen mehr Daten herumgeschickt werden (das übliche "Speicher gegen Zeit tauschen").

Aber die Datenmengen bleiben ja in der Größenordnung, daran, dass es so viele Produkte gibt, kannst du ja nicht wirklich was ändern.
 
NicoDeluxe

NicoDeluxe

Die Datenmenge macht mir eher weniger Sorgen, kostet ja kaum was so HDD Speicher. Allerdings wird das stündliche updated immer langsamer desto mehr Daten in der Tabelle sind hab ich das Gefühl.

ich lese jetzt alle Daten pro Kunde ein und erstelle für jeden Artikel aus der Hersteller Datei ein Objekt, welches dann in eine Liste kommt. Am Ende wird die List mit saveAll gespeichert (geänderte Werte Updates sich dann, was envers merkt und in eine andere Tabelle schreibt)
 
mrBrown

mrBrown

Die Datenmenge macht mir eher weniger Sorgen, kostet ja kaum was so HDD Speicher. Allerdings wird das stündliche updated immer langsamer desto mehr Daten in der Tabelle sind hab ich das Gefühl.
Die Tabelle sollte nicht wachsen, da sollte nur der jeweils letzte Datensatz enthalten sein.
 
NicoDeluxe

NicoDeluxe

Ja das ist so, es sind pro Kunde sagen wir 500.000 Datensätze (wenn neue Artikel hinzukommen, werden die natürlich auch gespeichert und es wächst) diese 500.000 werden dann updated.
 
mrBrown

mrBrown

Achso, und mit "langsamer desto mehr Daten in der Tabelle sind" meinst du, dass es langsamer wird wenns 100 statt 5 Kunden sind?

Das wird ja auch nur schlimmer, wenn es keine "Caches" mehr gibt, die sind ja dazu da, das zu beschleunigen. Wenn das wirklich zu langsam ist (es muss ja nur schnell genug sein, dass ein Durchlauf pro Stunde klappt), kann man das auch noch skalieren, im Extremfall auf 1 Service pro Kunde & Hersteller.

Wenn die einzelnen Services so schon "langsam" sind (und das nicht an der Kommunikation zwischen denen liegt), wird es durch einen Monolithen eher noch langsamer.
 
Thema: 

Strukturplanug Klappe die 2. Microservices zu ModulMonolith

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben