Microservices StrukturPlanung

Diskutiere Microservices StrukturPlanung im Application Tier Bereich.
NicoDeluxe

NicoDeluxe

Hi,
der Speicherplatz macht mir da eher weniger sorgen, kostet ja nix mehr heututuage. Eher die Anzahl der Zeilen, wenn ich mir den einen Hersteller anschaue, der hat 200k Artikel x 10 User (da jeder andere Preise, usw haben kann) dann dauern die Updates ewig oder? Ich könnte die Tabelle der Hersteller auch pro Kunde anlegen, dann hab ich aber da wieder bisschen overhead, dann müsste ich mich ums löschen der DB und anlegen kümmern wenn ein neuer User kommt. Andere Möglichkeit wäre, einmal alle Daten abzuspeichern mit den Daten die unser Testlogin vom Hersteller bekommt und dann die kundenspezifischen Änderungen abspeichern, aber da kann es wieder passieren dass ein Kunde Artikel XYZ nicht bekommen darf (ist dann in seinem API, CSV Feed nicht enthalten)

Mit dem Listener bekomm ich echt nicht gebacken, ich hätte am liebsten für jeden User einen eigenen Query (macht das Sinn?) Übersichtlich ist es auch jeden Fall. Dann könnte der Grohandelservice schön in jeden "Briefkasten" für den Kunden pumpen und ein Listener arbeitet nur dieses Query nach und nach ab. (Parallel zu anderen Listenern, welche andere Queries abarbeiten).

Ein anderes Problem dass ich grad mit dem Test-Service sehe ich dass am 14.07. Wartungsarbeiten angekündigt wurden vom Hoster. Nun liegt der Service und die DB auf einem Server - somit wäre morgen der gesamte Hersteller nicht online. Ich müsste jetzt die DB und den Service wo anders hin zieehen wenn der morgen unbedingt laufen müsste. Aber da könnte man mit einer zentralen DB iwo anders Abhilfe schaffen was aber wiederum Netzwerklatenz mit sich bringt und andere Netzwerkprobs. Ich geh jetzt mal nicht davon aus, dass der Service da morgen 1 Tag weg ist, aber so ein Server kann ja auch mal abschmieren.
 
mrBrown

mrBrown

Eher die Anzahl der Zeilen, wenn ich mir den einen Hersteller anschaue, der hat 200k Artikel x 10 User (da jeder andere Preise, usw haben kann) dann dauern die Updates ewig oder?
Ewig ist relativ – es muss nur schnell genug gehen, und bei 10 Usern wären das 6min für 200k Artikel, das sollte in jedem Fall machbar sein.

Ein anderes Problem dass ich grad mit dem Test-Service sehe ich dass am 14.07. Wartungsarbeiten angekündigt wurden vom Hoster. Nun liegt der Service und die DB auf einem Server - somit wäre morgen der gesamte Hersteller nicht online. Ich müsste jetzt die DB und den Service wo anders hin zieehen wenn der morgen unbedingt laufen müsste. Aber da könnte man mit einer zentralen DB iwo anders Abhilfe schaffen was aber wiederum Netzwerklatenz mit sich bringt und andere Netzwerkprobs. Ich geh jetzt mal nicht davon aus, dass der Service da morgen 1 Tag weg ist, aber so ein Server kann ja auch mal abschmieren.
Jetzt stell dir zum Vergleich mal vor, der zentrale Datenbankserver wird gewartet. Statt einem einzelnen Service wären dann alle Services betroffen :)

Und in dem Fall lässt sich das ja einfach über's Einspielen des Backups lösen, macht man im Idealfall sowieso öfters mal um's zu testen. Alten Server stoppen, Backup der DB machen, auf neuem Server starten und die Wartung kann dir egal sein :)
 
NicoDeluxe

NicoDeluxe

Joa da hast Recht, wenn man genug Vorlauf hat kann man ja entscheiden:

1. Wartung ist nachts, dauert nur 4 Stunden > Kunden informieren gibt keine Updates in der Zeit erledigt
2. Wenn es was längeres ist kann man das ja umziehen. Vorausgesetzt man kommt an die Sicherung ran (wenn die Möhre abgeschmiert ist)


Wie bist du oben auf die 6 Minuten gekommen? Geschätzt? das wären dann 2mio Datensätze in der Tabelle bei 10 Nutzern.
 
NicoDeluxe

NicoDeluxe

Die laufen alle parallel. Alle 10 beginnen um 10:00 zb nicht verteilt auf die Stunde oder steh ich grad auf dem Schlauch und verstehe dich falsch :D
 
mrBrown

mrBrown

Die laufen alle parallel. Alle 10 beginnen um 10:00 zb nicht verteilt auf die Stunde oder steh ich grad auf dem Schlauch und verstehe dich falsch :D
Na wie sie innerhalb dieser Stunde laufen kannst du ja beliebig festlegen.

Entweder alle hintereinander, dann im Schnitt 6min, oder alle gleichzeitig, dann müssen sie nur innerhalb einer Stunde fertig werden
 
NicoDeluxe

NicoDeluxe

Alle mit einem Mal ist der Plan. Wenn zu viele werden dann splitten wir das evtl auf in 10er Schritten oder so.

vielleicht könnte ich das alles noch reduzieren und das abspeichern, was überwacht werden soll. Daten wie EAN, MPN und solcher Nummern die ändern sich nie die brauch ich nur 1 x beim Anlegen.

Was hälst du von meiner Idee mit dem Query pro User? Ich sehe das wie eine Art Briefkasten der vollgestopft werden kann und wenn es einen Listener gibt arbeitet der das alles schön ab. Der Listener selbst sollte horizontal skalieren, also je Kunde ein Listener. Es muss nicht sein dass es pro User mehrere Listener gibt, der kann den Queue ruhig nach Prio/Fifo abarbeiten.

Hoffe das geht überhaupt. Hast du schon mal mit Sagas gearbeitet? Wäre das vielleicht auch noch eine Variante?
 
mrBrown

mrBrown

Was hälst du von meiner Idee mit dem Query pro User? Ich sehe das wie eine Art Briefkasten der vollgestopft werden kann und wenn es einen Listener gibt arbeitet der das alles schön ab. Der Listener selbst sollte horizontal skalieren, also je Kunde ein Listener. Es muss nicht sein dass es pro User mehrere Listener gibt, der kann den Queue ruhig nach Prio/Fifo abarbeiten.
Eine Query pro Nutzer würde ich vermutlich nutzen, Listener kann man allerdings unabhängig davon skalieren.

Hast du schon mal mit Sagas gearbeitet? Wäre das vielleicht auch noch eine Variante?
Wofür sollte das eine Variante sein?
 
NicoDeluxe

NicoDeluxe

Wofür sollte das eine Variante sein?
Das man zb ein neues Produkt nimmt und mittels Saga über verschiedene Services schleift zb Import > speichern in tenant DB > export nach Kundenkassensystem oder was da auch immer hängt.

Ich bekomm das iwie nicht hin zur Laufzeit einen Listener auf einen neuen Query zu erstellen. Muss mir dass dann nochmal in Ruhe ansehen.
 
NicoDeluxe

NicoDeluxe

Nochmal mit den Queries, angenommen unser Programm geht durch die Decke und wir haben 1000 User. Ist das dann nicht zu viel mit den Queries 1000 - ist ein ActiveMQ und wie sie alle heißen dafür gemacht? Stell ich mir irgendwie schwer vor
 
mrBrown

mrBrown

Das man zb ein neues Produkt nimmt und mittels Saga über verschiedene Services schleift zb Import > speichern in tenant DB > export nach Kundenkassensystem oder was da auch immer hängt.
Saga legt da nur ein Transaktions-System drüber, das dürfte in deinem Fall Unsinn sein.

Nochmal mit den Queries, angenommen unser Programm geht durch die Decke und wir haben 1000 User. Ist das dann nicht zu viel mit den Queries 1000 - ist ein ActiveMQ und wie sie alle heißen dafür gemacht? Stell ich mir irgendwie schwer vor
Klar kommt ActiveMQ damit klar, da kann man relativ einfach horizontal und vertikal skalieren.
 
NicoDeluxe

NicoDeluxe

Ich bekomme es nicht hin, pro User einen Queue zu erstellen, ist auch vielleicht nicht so sinnvoll.

Ist es denn ratsam Daten in einer Message unter zu bringen? Am Beispiel Importservice hat ein neues Produkt festgestellt:
Variante A :
Message mit allen neuen Produkten in der Payload an den Broker senden, Listener holt ab und verarbeitet.
Problem: Payload zu groß!

Variante B :
Message senden "Hey neues Produkt Artikelnummer =123", Listener holt die Message und holt sich per REST das Produkt mit der SKU 123
 
Thema: 

Microservices StrukturPlanung

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben