Microservices StrukturPlanung

Diskutiere Microservices StrukturPlanung im Application Tier Bereich.
mrBrown

mrBrown

Jap, aber auch nach 5 minuten kommt in der remote db nix an :( Die remote DB hat eine 1gbit Anbindung und ich hier 200.000 das muss doch flutschen oder?
Wenn da irgendwas 5min dauert, läuft da zumindest irgendwas nicht richtig...

Entweder weil ein Request ewig lange dauert, oder weil es sehr viele requests innerhalb einer Transaktion sind. Klappt das ganze denn mit einzelnen Artikeln?

Lese ich da unterschwellig heraus, dass ich die DB auf dem selben Server installieren soll? :D
Man sollte zumindest drüber nachdenken, ob und warum man die DB auf einem extra Server laufen lässt (und die gleiche Überlegung dann natürlich für den Fall, dass man beides auf einem Server laufen hat).

Dann kann man sinnvoll entscheiden. Die DB einfach auf einem externen Server laufen lassen "weil das macht man halt so" ist nicht sinnvoll :)
 
NicoDeluxe

NicoDeluxe

wir haben extra einen starken server für die ganzen dbs, die werden da immer brav gesichert usw. Und der Adminaufwand hält sich in grenzen mit einem Server. Hab jetzt mal ne mongo aufgesetzt bei irgend nem free gedöns. Da importiert es, zwar auch nicht übelst schnell aber es tut sich was. Hmm muss der Datenbankmensch wohl mal gucken was da los ist.
 
NicoDeluxe

NicoDeluxe

Ah jetzt hab ich noch was interessantes. Ich hab nen ping von teilweise 1000ms zum db server. Das trägt natürlich nicht positiv bei

1591992462126.png
 
mrBrown

mrBrown

wir haben extra einen starken server für die ganzen dbs
Ist halt die Frage, ob ein extra starker Server sinnvoller ist, als uU mehrere kleine...

Bei den einzelnen Herstellerservices, dir ziemlich genau voraussagbare und planbare Last erzeugen, gäbe es vielleicht bessere Möglichkeiten.
Mit einer zentralen DB fängt man sich uU die gleichen Probleme wieder ein. (alle Hersteller-Services und der Master-Service arbeiten gleichzeitig => hohe Last auf zentraler DB; zentrale DB hat Aussetzer => Alle Services sind betroffen, auch wenn sie eigentlich völlig problemlos noch arbeiten könnten)

Das soll jetzt kein "Nehm auf jeden Fall einzelne Datenbanken pro Service" sein, aber man sollte es zumindest in beiden Fällen gut begründen können.

die werden da immer brav gesichert usw. Und der Adminaufwand hält sich in grenzen mit einem Server.
Sowas gehört eh automatisiert, dann ist es kaum ein Unterschied, ob einer oder 100 Server :)

Hab jetzt mal ne mongo aufgesetzt bei irgend nem free gedöns.
Dafür kann man zB Docker nutzen, das ist prädestiniert für solche Fälle
 
NicoDeluxe

NicoDeluxe

verstehe was du meinst danke. Wenn ich zb 5 services habe die auf einem laufen und dann muss ich einen service auf einen anderen server ziehen, weil so viele user kommen oder sonst was, dann muss ich alle daten mit nehmen. So schieb ich den service wo anders hin, starte ihn und fertig. hmmm
 
NicoDeluxe

NicoDeluxe

Auf nem anderen Server gehts auch nicht schneller. Tjoa dann bleibt wohl nur lokale DB für jeden Service :(
Hab mal das Looging aktiviert für saveAll gibt es folgendes aus:
Generated identifier: component
Loading entity:...
select product0_...
Done entity load...

das dauert halt..


kann das mit der ID zu tun haben?
public class Product {
Code:
@EmbeddedId
private ProductId id;

...
}

public class ProductId implements Serializable {
    @Column
    private String productsSku;
    @Column
    private String tenant;
}
 
T

thecain

Wenn du eine Sekunde Ping hast, brauchst du den Code nicht mehr gross anschauen.

Da scheint irgendwas am Netzwerk nicht zu stimmen.
 
NicoDeluxe

NicoDeluxe

Selbst auf einem linux server, der einen ping zur db von 15ms hat gehts nicht schneller. Hätte ich nicht gedacht, dass ein Netzwerk so starken Einfluss haben kann. Von mir lokal zum Server ok, aber von einem Server zum Server...die haben beide 1gibt hin und her.

Dann bleibt mir ja nur noch die Services mit einer DB auf eine Maschine zu packen. Das wird a bissl teuer. Cloudzeug wie AWS will ich nicht nutzen, ist mir zu kompliziert und Geld haben die ohnehin schon genug, möchte meinen lokalen Anbieter unterstützen, dann muss ich mit dem irgend ne Lösung finden.

Dumme Frage; H2 nutzen mit Speichern auf der Platte ist keine gute Idee oder?
 
Zuletzt bearbeitet:
NicoDeluxe

NicoDeluxe

Ah ne h2 wird ja glaube gelöscht bei neustart. oook dann hab ich ein Problem :D
 
mrBrown

mrBrown

Selbst auf einem linux server, der einen ping zur db von 15ms hat gehts nicht schneller. Hätte ich nicht gedacht, dass ein Netzwerk so starken Einfluss haben kann. Von mir lokal zum Server ok, aber von einem Server zum Server...die haben beide 1gibt hin und her.
Der Ping hat vor allem dann nen Einfluss, wenn es sehr viele kleine Pakete sind. Wenn die 40.000 Artikel alle einzeln gesendet werden, bist du mit einfachem Ping schon bei 40.000*15ms = 10min. Deshalb eben Batching, damit du weniger einzelne Requests hast.

Dann bleibt mir ja nur noch die Services mit einer DB auf eine Maschine zu packen. Das wird a bissl teuer. Cloudzeug wie AWS will ich nicht nutzen, ist mir zu kompliziert und Geld haben die ohnehin schon genug, möchte meinen lokalen Anbieter unterstützen, dann muss ich mit dem irgend ne Lösung finden.
Die Services laufen doch sicherlich schon irgendwo? Probier vorher mal aus, ob überhaupt ein größerer Server notwendig wäre. Die Anforderungen sind da an die Datenbank sehr gering. Du hast völlig planbare Last, brauchst also keinerlei Reserven, und die Last ist auch noch beliebig steuerbar, besser kann es gar nicht laufen

Dumme Frage; H2 nutzen mit Speichern auf der Platte ist keine gute Idee oder?
[...]
Ah ne h2 wird ja glaube gelöscht bei neustart. oook dann hab ich ein Problem :D
Mit H2 kann man auch Problemlos auf der Platte speichern. Die Datenbank nur im RAM halten ist nur eine der möglichen Optionen.
 
L

LimDul

Ah ne h2 wird ja glaube gelöscht bei neustart. oook dann hab ich ein Problem :D
Nö, wenn du bei h2 als Protokoll File und nicht Memory nimmst, wird die Datei nicht gelöscht.

Ich hab es jetzt nicht im Detail verfolgt - aber man kann sich auch die Frage stellen, wie "schlimm" wäre ein Datenbankverlust beim Herstellerservice? Man könnte in der Architektur des Systems zwei verschiedene "Varianten" der Kommunikation Hersteller Service => Master vorsehen.

a) Differentiell (Der Hersteller Service schickt nur die Änderungen, die er aus seiner lokalen DB berechnet rübert)
b) Voll (Der Hersteller Service schickt die kompletten Daten rüber, der Master schmeisst alle alten des Hersteller Service weg und übernimmt sie neu)

Dann kann man es sich leisten beim Hersteller Service auf eine leichtgewichtige Datenbank ohne besonders große Sicherheit in Richtung Backups und Co setzen - denn im Falle eines Problems, macht man erst mal einen Vollabgleich und ist dann wieder sauber.
 
NicoDeluxe

NicoDeluxe

Ich habe jetzt mal postgres auf einem testserver installiert und den service da drauf > 10 Sek für 40k Produkte. Also lag es definitiv am Netzwerk. Hätte ich nicht gedacht.

Ich werde das also so machen mit einer "echten" Datenbank. Postgres hab ich zwar noch nie genutzt, wird aber mal Zeit es kennen zu lernen :)

Nun noch eine Frage, wie würdet ihr die Infrastruktur aufbauen? Ich möchte die Services der Einfachheit halber als linux service installieren also kein Docker o.ä.

Wir haben derzeit micro server im Einsatz auf denen die Services verteilt sind (mehrere Services pro Server). Damit bin ich bisher eigentlich zufrieden Es gäbe nun aber auch eine Alternative, eine Art VM in der Cloud. Wir könnten ein Template hinterlegen und beim deployen eines neuen Servers würde postgres, java usw automatisch installiert werden.

Je Service ein Server wäre bestimmt etwas übertrieben oder was meint ihr? Wenn es eng würde auf den Micro kann man ja immer noch umziehen. Wobei aber getrennt natürlich super sauber wäre.

Mein Plan ist jetzt wie folgt:

Artikel werden in die lokale Hersteller DB geladen. Beim Speichen schickt ein Interceptor eine Message mit dem Produkt an den Broker (entweder neu, preis geändert, stock geändert usw). Die Queues würde ich nach Fachlickeit sortieren, also Import-Queue, Update-Queue, Delete-Queue
Jeder Hersteller-Service stellt die Nachrichten dann in den entsprechenden Queue. Das sollte ActiveMQ abkönnen wenn da paar hundert tausend Messages zu verarbeiten sind oder (Hardware vorausgesetzt)?

Der Master hat je Queue einen Listener und holt die Messages ab und verarbeitet den Inhalt. Den Master kann ich bei Bedarf sogar teilen oder duplizieren? Wenn ein Listener eine Message abgeholt hat, wird sie für andere Listener auf den selben Queue geblockt oder?

Im Master werden dann die Verarbeitungen vorgenommen und in die "echte" entgültige Kunden-DB geschrieben.

Over and out. Einwände sind gern gesehen ;)
 
Zuletzt bearbeitet:
mrBrown

mrBrown

Nun noch eine Frage, wie würdet ihr die Infrastruktur aufbauen? Ich möchte die Services der Einfachheit halber als linux service installieren also kein Docker o.ä.

Wir haben derzeit micro server im Einsatz auf denen die Services verteilt sind (mehrere Services pro Server). Damit bin ich bisher eigentlich zufrieden Es gäbe nun aber auch eine Alternative, eine Art VM in der Cloud. Wir könnten ein Template hinterlegen und beim deployen eines neuen Servers würde postgres, java usw automatisch installiert werden.

Je Service ein Server wäre bestimmt etwas übertrieben oder was meint ihr? Wenn es eng würde auf den Micro kann man ja immer noch umziehen. Wobei aber getrennt natürlich super sauber wäre.
Ich würde das auch nicht ohne Container und zB Kubernetes aufbauen. Das ganze händisch zu managen dürfte einfach deutlich mehr Arbeit sein und kaum einen Vorteil bringen.
 
NicoDeluxe

NicoDeluxe

Kubernetes oder Docker hab ich bisher noch nie benutzt. Müsste ich mir erstmal ansehen :/
 
mrBrown

mrBrown

mindestens Docker lohnt sich ganz generell, auch zum entwickeln auf dem lokalen System.
 
NicoDeluxe

NicoDeluxe

Mein Serveradmin meint auch, docker angucken. Hab ich auf meiner Liste, aber nun möchte ich erstmal mit den Services voran kommen :D

hast du ne Idee wie ich prüfe ob ein Artikel noch in der Datei enhalten ist? Hibernate hat doch auch irgend ne Annotation (find die nur nich) wo es automatisch einen Wert setzt, wenn updated wird.

Dann könnte man doch eine Spalte status erstellen und vor jedem Import auf 0 setzen. Dann Alle drüber und die dann immer noch 0 haben, waren nicht mehr in der Datei enthalten.
 
mihe7

mihe7

Hibernate hat doch auch irgend ne Annotation (find die nur nich) wo es automatisch einen Wert setzt, wenn updated wird.
Meinst Du @PreUpdate udn @PostUpdate?

Dann könnte man doch eine Spalte status erstellen und vor jedem Import auf 0 setzen.
Du könntest beim Aktualisieren auch einfach ein Timestamp (Start des Imports) oder eine Versionsnummer (Import-Lauf-ID) setzen. Dann sparst Du Dir das vorherige auf 0 setzen.
 
NicoDeluxe

NicoDeluxe

Nö aber danke die kann ich ja auch nutzen :D dann setze ich einfach status true in einer mit @PreUpdate annotierten Methode :) Danke
 
mrBrown

mrBrown

Hibernate hat doch auch irgend ne Annotation (find die nur nich) wo es automatisch einen Wert setzt, wenn updated wird.
Ja, aber du die wird dir in Bezug auf gelöschte Einträge nichts bringen. Gelöscht und "nicht geändert" bewirken ja beide keine Versionsänderung.

Dann könnte man doch eine Spalte status erstellen und vor jedem Import auf 0 setzen. Dann Alle drüber und die dann immer noch 0 haben, waren nicht mehr in der Datei enthalten.
Ja, möglich wäre das. Alternativ Timestamp oder "Versionsnummer", die mit jedem Update steigt.

Eine andere Möglichkeit wäre, einfach alles als neue Werte in die DB zu schreiben (sodass alte Werte und nur Werte beide vorhanden sind), und dann ein Diff aus alten und neuen Werten erstellen. (Die alten Werte danach dann noch löschen, sonst blähst du die DB unnötig auf.)
Damit bekämet du sowohl Änderungen als auch gelöschte Werte, und bräuchtest nur ein INSERT und ein SELECT.

EDIT: grob etwa so: http://sqlfiddle.com/#!9/38c8b4/6/0
 
Zuletzt bearbeitet:
Thema: 

Microservices StrukturPlanung

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben