Strukturplanug Klappe die 2. Microservices zu ModulMonolith

OnDemand

Top Contributor
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?
 

MoxxiManagarm

Top Contributor
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

Super-Moderator
Mitarbeiter
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 ;)
 

OnDemand

Top Contributor
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)
 

mrBrown

Super-Moderator
Mitarbeiter

MoxxiManagarm

Top Contributor
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.
 

OnDemand

Top Contributor
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
 

OnDemand

Top Contributor
@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.
 

Dukel

Top Contributor
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.
 

OnDemand

Top Contributor
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

Super-Moderator
Mitarbeiter
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.
 

OnDemand

Top Contributor
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

Super-Moderator
Mitarbeiter
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.
 

OnDemand

Top Contributor
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)
 

OnDemand

Top Contributor
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

Super-Moderator
Mitarbeiter
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.
 

OnDemand

Top Contributor
Achso, und mit "langsamer desto mehr Daten in der Tabelle sind" meinst du, dass es langsamer wird wenns 100 statt 5 Kunden sind?
Jo genau so meint ich das. Wenn ein Monolith pro User existiert, könnten die Daten direkt in die echte Datenbank (ohne Daten vorher zu chachen) Dann würde das Hersteller Modul die Artikel nehmen, zurechtbasten, berechnen und an die Persistenz geben. In dem Monolith würde dann komplette Netzwerkgeschichte wegfallen (
 

mrBrown

Super-Moderator
Mitarbeiter
In dem Monolith würde dann komplette Netzwerkgeschichte wegfallen (
Ist das Netzwerk aktuell an irgendeiner Stelle ein Problem? An keiner Stelle klingt das irgendwie nach Netzwerkproblemen.

Jo genau so meint ich das. Wenn ein Monolith pro User existiert, könnten die Daten direkt in die echte Datenbank (ohne Daten vorher zu chachen) Dann würde das Hersteller Modul die Artikel nehmen, zurechtbasten, berechnen und an die Persistenz geben.

Der Cache dient aktuell dazu, das ganze schneller zu machen.

Durch den Cache haben die Hersteller-Services zwar viel, aber konstante Last, die Last kannst du problemlos steuern und die Services beliebig vertikal und horizontal skalieren – der Master-Service hat dadurch aber kaum konstante Last, der komplizierte Teil (das finden der Änderungen), findet in der Hersteller-Services statt, und hat damit genug Reserven für das Frontend.

Wenn du das jetzt wieder in einen Service mergest, hat der sowohl die hohe Grundlast, muss aber zusätzlich noch Reserven für das Frontend haben.

(Service meint jeweils DB + Applikation)

Vor allem landest du damit dann aber auch wieder beim Ursprungsproblem:
Wir hatten das System bereits als Monolith aber wenn der Service abgestürzt ist> Alle Herstellerimporte betroffen, Frontend konnte keine Daten mehr anzeigen usw.


Mach dir einfach mal eine Pro- und Contra-Liste, in der du alle möglichen Relevanten Punkte zwischen beiden (und anderen) Lösungen vergleichst. Relevant wären zB Ausfallsicherheit, Deployment, Monitoring, ... und was auch immer euch wichtig ist.

Und zusätzlich solltest du deine Probleme mit der aktuellen Lösung mal konkret rausfinden. Hier hast du Gefühl ein Duzend Probleme erwähnt, aber keines davon so wirklich. Aber alle davon klingen relativ klein und einfach behebbar.
 

OnDemand

Top Contributor
Vor allem landest du damit dann aber auch wieder beim Ursprungsproblem:
Damals hatten wir einen Monolith für 50 Kunden, dabei konnte der RAM zu Ende gehen etc. Jetzt würden wir pro Kunden einen Monolith auf einen eigenen Server stellen. Je nach dem was der Kunde gebucht hat würde er einen entsprechend starken Server bekommen.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
OnDemand Microservices StrukturPlanung Application Tier 153

Ähnliche Java Themen

Neue Themen


Oben