Hallo ihr lieben, ich überlege grad wie ich meinen Monolith in Microservices aufteilt. Ich möchte gern mal eure Meinung hören und liebend gern Verbesserungsvorschläge. Geht nur um deinen reinen Plan wie die Services aufgebaut werden.
Beispiel : ich bin Entwickler für eine Werkstatt-Ersatzteil-Software und möchte meine Software an Distributionen verkaufen. Dafür möchte ich pro Kunde eine eigene Datenbank (tenant)
Das Programm im groben folgendes:
1. Abholung von Fahrzeug-Ersatzteil-Daten (Preis, Lagerbestand usw) von 50 verschiedenen Herstellern
2. Daten werden gelesen und aufbereitet
3. Die Daten werden in die Datenbank für den Kunden gespeichert
4. Die Daten werden an Werkstätten überspielt / Eine API steht bereit um die DAten durch eine Werkstatt abfragen zu lassen
Das Ganze passiert stündlich, bestehende Teile werden nur updated (Preis, Bestand)
Nun hab ich einen Prototyp wie folgt, bin aber nicht so richtig zufrieden da es viele Abhängigkeiten gibt.
1. Zuul als Api Gateway
2. Eureka Nameserver
3. Master-Service
4. Hersteller XY Service
5. Hersteller AB Service
6. Hersteller ZZ Service
7. Pojo Projekt
ff.
Jeder Herstellerservice holt die Daten ab, bereitet sie auf und schickt sie an den Masterservice. Der Masterservice bekommt im Header den tenant mitgeteilt, und speichert es in die entsprechende DB des Kunden. Funktioniert auch alles
Das PojoProjekt hat alle @Entity und DTOs modelliert, jeder Hersteller hat dazu eine Abhängigkeit damit ich das Objekt "Ersatzteil" nur in einem Projekt pflegen muss, und nicht in jedem Service. Ist blöd ich weiß, aber jeder Herstellerservice muss wissen was an den Master schicken muss.
Das Ganze klappt auch wie ich es will, ist aber nicht so gut wartbar und die Abhängigkeiten sind mir zu groß, vor allem aber gefällt mir nicht, dass der Masterservice "das Herzstück" ist. Wenn der Down ist, geht nix mehr > alles andere als Microservice-Vorteil
Im Prinzip sollte ja jeder Service eine eigene DB haben, aber aufgrund der Tenant-Anforderung sehe ich das nicht als sinnvoll an. Ich brauch alle Ersatzteildaten eines Kunden in einer DB. Wenn ich nun irgendwann 50 Hersteller habe, hab ich zwar den Vorteil: 1 Hersteller down, die anderen funktionieren noch. Aber der Wartungsaufwand ist schon enorm.
Daher eine weitere Überlegung:
Ich mache einen einzigen Service, der alle Hersteller kennt. Diesen Service kann ich auf den Servern 50 x deployen, aber jede Instanz ist nur für 1 Hersteller zuständig (als Startparam übergeben welchen er macht o.ä.). So hätte ich nur 1 Service zu warten, wenn ich den aber update muss ich alle neustarten.
Ich hoffe jemand erkennt den Knoten den ich hab und kann mir ein wenig helfen.
Beispiel : ich bin Entwickler für eine Werkstatt-Ersatzteil-Software und möchte meine Software an Distributionen verkaufen. Dafür möchte ich pro Kunde eine eigene Datenbank (tenant)
Das Programm im groben folgendes:
1. Abholung von Fahrzeug-Ersatzteil-Daten (Preis, Lagerbestand usw) von 50 verschiedenen Herstellern
- CSV, API oder TXT jeder Anbieter hat eine komplett andere Schnittstelle
2. Daten werden gelesen und aufbereitet
-Namen ergänzt, VK Preise berechnet
3. Die Daten werden in die Datenbank für den Kunden gespeichert
4. Die Daten werden an Werkstätten überspielt / Eine API steht bereit um die DAten durch eine Werkstatt abfragen zu lassen
Das Ganze passiert stündlich, bestehende Teile werden nur updated (Preis, Bestand)
Nun hab ich einen Prototyp wie folgt, bin aber nicht so richtig zufrieden da es viele Abhängigkeiten gibt.
1. Zuul als Api Gateway
2. Eureka Nameserver
3. Master-Service
4. Hersteller XY Service
5. Hersteller AB Service
6. Hersteller ZZ Service
7. Pojo Projekt
ff.
Jeder Herstellerservice holt die Daten ab, bereitet sie auf und schickt sie an den Masterservice. Der Masterservice bekommt im Header den tenant mitgeteilt, und speichert es in die entsprechende DB des Kunden. Funktioniert auch alles
Das PojoProjekt hat alle @Entity und DTOs modelliert, jeder Hersteller hat dazu eine Abhängigkeit damit ich das Objekt "Ersatzteil" nur in einem Projekt pflegen muss, und nicht in jedem Service. Ist blöd ich weiß, aber jeder Herstellerservice muss wissen was an den Master schicken muss.
Das Ganze klappt auch wie ich es will, ist aber nicht so gut wartbar und die Abhängigkeiten sind mir zu groß, vor allem aber gefällt mir nicht, dass der Masterservice "das Herzstück" ist. Wenn der Down ist, geht nix mehr > alles andere als Microservice-Vorteil
Im Prinzip sollte ja jeder Service eine eigene DB haben, aber aufgrund der Tenant-Anforderung sehe ich das nicht als sinnvoll an. Ich brauch alle Ersatzteildaten eines Kunden in einer DB. Wenn ich nun irgendwann 50 Hersteller habe, hab ich zwar den Vorteil: 1 Hersteller down, die anderen funktionieren noch. Aber der Wartungsaufwand ist schon enorm.
Daher eine weitere Überlegung:
Ich mache einen einzigen Service, der alle Hersteller kennt. Diesen Service kann ich auf den Servern 50 x deployen, aber jede Instanz ist nur für 1 Hersteller zuständig (als Startparam übergeben welchen er macht o.ä.). So hätte ich nur 1 Service zu warten, wenn ich den aber update muss ich alle neustarten.
Ich hoffe jemand erkennt den Knoten den ich hab und kann mir ein wenig helfen.