Microservices StrukturPlanung

Diskutiere Microservices StrukturPlanung im Application Tier Bereich.
NicoDeluxe

NicoDeluxe

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
- 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.
 
L

LimDul

Warum kann nicht jeder Service selber mit dem korrekten Tenant in eine gemeinsame DB schreiben? Warum das über den Master-Service delegiert werden. In der Regel läuft die Datenbank ja eh auf einer eigene Instanz mit entsprechend "WUMMS" dahinter und ist dafür ausgelegt, dass das X User gleichzeitig reinschreibem.
 
NicoDeluxe

NicoDeluxe

Hi LimDul, stimmt, jeder Service kann ja das Tenant-Gedöns auch haben und jeder Service einen eigenen Pool auf die DB.

Was aber wenn 10 Services parallel neue Teile speichern, kommt die DB damit klar (nicht dass ID doppelt vergeben werden oder sonst was)

Ich nutzer HikariPool, je Tenant hat 2 Connections ,b ei 100 TenantUsern und jeder nutzt vielleicht durchschnittlich 20 Hersteller, macht dass einiges an Connections. Die Datenbank ist ein guter Server mit knapp 25GB Ram, SSD & Co der hat gut wumms und kann bei Bedarf erweitert werden. Da mach ich mir keine Sorgen.

Der Master macht noch weiteres, hab ich ganz vergessen. Zb Kann jeder Benutzer Einstellungen auf Ersatzteil-Artikel-Ebene treffen zb:
- Soll der Artikel deaktiviert werden wenn Bestand < XX
- Preise gewählter Artikel nicht berechnen
- User möchte nicht, dass die Beschreibungen updated/überschrieben werden, weil er es selber macht
usw

Diese "Prüfungen" macht der Master, ist auch nicht richtig.

Im Prinzip müsste jedes Ersatzteil durch eine Art "Filter" welcher das Ersatzteil entsprechend den User-Settings nach dem Lesen manipuliert, bevor es dann in die DB geht. Dieser "Filter" ist für alle Hersteller gleich, und wird immer wieder erweitert. Dafür war der Master mal gedacht, damit nicht in jedem Hersteller Service alles doppelt drin ist (Stichwort Code-Wiederverwendung) aber iwie trifft das bei Microservices nicht zu oder? Ich finde Code Wiederverndung und Unabhängigkeit beißen sich
 
L

LimDul

Hi LimDul, stimmt, jeder Service kann ja das Tenant-Gedöns auch haben und jeder Service einen eigenen Pool auf die DB.

Was aber wenn 10 Services parallel neue Teile speichern, kommt die DB damit klar (nicht dass ID doppelt vergeben werden oder sonst was)
Dann nutzt du die DB "falsch".
Datenbanken ist dafür ausgelegt das zu können. Die ID Vergabe muss halt entweder außerhalb der DB so sein, dass Kollisionen ausgeschlossen sind (UUID) oder die IDs werden über Sequencen aus der DB vergeben - dann sind Kollisionen auch ausgeschlossen.
 
J

JustNobody

Dieser Master-Service irritiert mich auch ein bisschen. Ich kenne es eigentlich so, dass jeder Service seine Daten in einer eigenen Datenbank hält. Also auch nicht einmal eine gemeinsame Datenbank.

Siehe dazu evtl. auch https://microservices.io/patterns/data/database-per-service.html

Und jeder Service ist für einen klaren Bereich zuständig und da mischt sich auch niemand sonst mit rein. Wenn da ein anderer Service etwas braucht, dann spricht er den entsprechend verantwortlichen Service an.

Oder war das Problem jetzt, dass Du mehrere Instanzen eines Services hast? Da musst du dann halt, wie von LimDul vorgeschlagen vorgehen.
 
T

thecain

Meiner Meinung nach ist der Schnitt der Services schon falsch.

Ich würde Microservices nicht nach Hersteller, sondern nach "Anwendungszweck" trennen. Beispiel für eigene Services:
- Ersatzteile erfassen/ändern/abrufen
- Aufträge erfassen/ändern/abrufen
- Kunden verwalten

Diese Microservices, haben wenn ganz sauber getrennt auch je eigene Datenbanken. Wenn du also nicht eine rechtliche Anforderung hast, nach Hersteller die Datenbanken zu trennen (kann ich mir bei Ersatzteilen nicht vorstellen) macht das auch keinen grossen Sinn.

Wobei ich auch sagen muss, ein Microservice Ansatz ist EINE Lösung. Nur weil das im moment viel gemacht wird, ist es nicht die einzig wahre Lösung.
 
H

httpdigest

Meiner Meinung nach ist der Haupttreiber für Microservices - oder einfach nur dafür, mehrere Services zu haben - organisatorischer Natur. Wenn ich mehrere Teams in meinem Unternehmen habe, dann habe ich zwangsläufig auch mehrere Services. Also ganz klassisch Conways Gesetz.
Wenn das nicht gegeben ist, muss man schon nach wirklich guten Gründen für mehrere Services suchen, da man sich bei Aufteilung in mehrere Services alle Probleme und höhere Komplexität eines verteilten Systems hereinholt. Es gibt natürlich gute Gründe für Microservices, aber wie @thecain schon sagt, ist die Verwendung von Microservices eine Lösung. Ein guter, horizontal skalierbarer Monolith wäre auch eine gute Lösung.
 
NicoDeluxe

NicoDeluxe

Wir hatten das System bereits als Monolith aber wenn der Service abgestürzt ist> Alle Herstellerimporte betroffen, Frontend konnte keine Daten mehr anzeigen usw.

Durch das Aufteilen in mehrere Services die über REST kommunizieren, konnten wir das Problem weitestgehend aus der Welt schaffen.

Wenn der Server down ging, war ein Service binnen 10 Minuten auf einen anderen gezogen und wieder online. Ich sehe in den Microservices wesentlich mehr Flexibilität als wir es mit dem Monolithen hatten. Bringt natürlich Verwaltungsaufwand mit sich, den ich aber auch weiter geben kann wenn es nur um das installieren/umziehen einens Services geht.

Aktuell ist der Importablauf so, was meine Ansicht nach bei einem Monolithen viiiiel Resource braucht. Angenommen 50 User werden mit Daten versogt:

1. Der Hersteller Service holt aus der DB "welche User haben HerstellerAB freigeschaltet und bekommen jetzt den Import", als Antwort bekommt er 50
3. Der Hersteller-Service ruft je im eigenen Thread pro User die CSV Daten ab oder API oder was auch immer, macht 50 Threads die je 10-100MB Daten holen. (Jeder User kann andere Daten haben, einmal Daten für alle ziehen is nich)
3. Die gelesenen Daten werden verarbeitet und an den Master gegeben, der dann die Daten in die DB geschrieben hat

Schritt 1-3 wird jetzt für ALLE 50 Hersteller gemacht im schlimmsten Fall alle zur gleichen Zeit. Heißt also 50 Hersteller x 50 User macht 500 Threads mit jeweils 50MB CSV Daten lesen.

Nutze ich kleine Services, kann ich flexibler reagieren. Wenn nun HersterllerXY 100 statt nur 50 User abarbeiten muss, kann ich den auf einen stärkeren Server packen, wobei ein HerstellerBLA mit nur 2 Usern auf einer kleinen VM für 1 EUR dümpeln könnte.

@thecain die ID wird bereits von der DB vergeben, dann ist das ja schon mal iO
 
L

LimDul

Mal als Idee, wenn man beim Master bleiben will. Warum nicht Master & Einzel-Services entkoppeln. Anstelle das die Clients direkt mit dem Master reden pumpen die ihre Daten in eine MessageQueue rein (Kafka und was es da sonst noch so gibt).

Dann hast du den Vorteil:
* Master down => Clients können dennoch weiter nach Kafka Daten pumpen.
* Alle Clients pumpen zufällig gleichzeitig massive Datenmengen rein => Der Master braucht halt länger zum abarbeiten, aber die Clients merken nix davon.
 
mrBrown

mrBrown

Klang in einem anderem Thread glaub ich schon mal durch, aber für Unabhängigkeit zwischen den Services könnte man auf ein eher Event-Getriebenes Modell setzen. Kommt natürlich auf die genauen Anforderungen an, in wie weit das umsetzbar ist, zB in wie weit das Abholen der Daten beim Hersteller von irgendwelchen Einstellungen betroffen ist.

Grob etwa:
Ein "Master-Service", der Zugriff auf die DB hat. Dieser enthält die gesamte Business-Logik sowie die API (könnte man trenne, je nach Anforderung).
Ein "Hersteller-Service", der die Daten bei den Herstellen abholt (entweder einer für alle, jeder einen einzelnen, oder irgendeine andere Variante). Der macht nichts anderes, als Daten von den Herstellern regelmäßig pollen und in dein Format bringen (ohne Preis-Berechnung, Kundeneinstellungen berücksichtigen, etc).

Der "Hersteller-Service" veröffentlicht die Daten dann über eine Message-Queue.
Der "Master-Service" holt sie aus der Queue ab, konvertiert die Daten nach Nutzer-Bedingungen etc. pp. und schreibt sie in die Datenbank.


Die einzelnen Komponenten sind unabhängig, man braucht nur ein gemeinsames Format für die Events. Jede Komponente darin kann man beliebig replizieren, Ausfallwahrscheinlichkeit sollte damit sinken. Fällt zB ein Hersteller-Service aus, interessiert das alle anderen nicht. Fällt der Master-Service aus, interessiert das die Hersteller-Services nicht, und dem ganzen kann man durch X parallele Master-Services entgegenarbeiten.

Wenn man es bidirektional braucht (also Master gibt vor, welche Daten die Hersteller-Services holen), dann kann der das ebenso über die MQ veröffentlichen.
 
NicoDeluxe

NicoDeluxe

@mrBrown das klingt gut. Dann liegen wir nicht soooo weit weg von dem was wir haben. Wir haben jüngst besprochen, dass wir die Importer dumm machen könnten und die wirklich nur die Daten holen und speichern.

Nur müsste die Logik irgendwie informiert werden wenn: Bestand geändert, ekpreis geändert usw. außerdem müsste er über neue artikel informiert werden. Aber die "logik" kann ja gar nicht wissen OB sich was geändert hat, ohne die bestehenden Daten zu lesen.

bisher hat der jedes Produkt genommen, das bestehende geholt und abgeglichen. Das ist natürlich großer Mist, aber es hat geklappt. Bei der Menge an Daten nun ist das nicht mehr praktikabel.

Messaging ist das hier nehm ich an? https://spring.io/guides/gs/messaging-jms/
Das steht mir noch in einem Kurs bevor.
 
Zuletzt bearbeitet:
mrBrown

mrBrown

@mrBrown das klingt gut. Dann liegen wir nicht soooo weit weg von dem was wir haben. Wir haben jüngst besprochen, dass wir die Importer dumm machen könnten und die wirklich nur die Daten holen und speichern.
Auf der Ebene Rest vs MessageQueue ist es schon relativ weit weg, es bleibt halt nur bei verschiedenen Services für verschiedene Dinge, die gesamte Kommunikation dazwischen ändert sich allerdings.

Nur müsste die Logik irgendwie informiert werden wenn: Bestand geändert, ekpreis geändert usw. außerdem müsste er über neue artikel informiert werden. Aber die "logik" kann ja gar nicht wissen OB sich was geändert hat, ohne die bestehenden Daten zu lesen.

bisher hat der jedes Produkt genommen, das bestehende geholt und abgeglichen. Das ist natürlich großer Mist, aber es hat geklappt. Bei der Menge an Daten nun ist das nicht mehr praktikabel.
Die Frage ist dabei immer, in wie weit man das überhaupt braucht.

Beispiel Preis:
Deine Variante ist, jede Stunde zu fragen, ob der Preis immer noch 10€ beträgt, und dann den neuen Preis gesagt zu bekommen.
Die andere Variante wäre, das du jede Stunde einfach gesagt bekommst, wie der aktuelle Preis ist.

Statt:
A: Ist der Preis noch 10€?
B: Ja.
A: Ist der Preis noch 10€?
B: Ja.
A: Ist der Preis noch 10€?
B: Nein, 15€.
A: Ist der Preis noch 15€?
B: Ja.

Ist es dann ein:
B: Der Preis ist 10€
B: Der Preis ist 10€
B: Der Preis ist 15€
B: Der Preis ist 15€


Wenn das nicht praktikabel ist, können die "Hersteller-Services" die Daten auch selber speichern, und dann nur Änderungen publishen. Erfordert dann natürlich Datenbanken pro Service, wobei die relativ klein dimensioniert sein können, dort entsteht ja nur sehr kontrollierbare Last.

Hängt aber auch z.B. davon ab, wie aktuell die Daten sein müssen. Aktuell können sie eine Stunde lang falsch sein (wenn ich das oben richtig verstanden hab, abgefragt z.B. um 12:00, Änderung um 12:01, dein Service fragt aber erst um 13:00 wieder nach). Ist das ein hartes Limit oder ein weiches Limit? Wie tragisch ist es, wenn der Client die Daten nicht nur eine Stunde, sondern 2, 3, 4 Stunden lang falsch angezeigt bekommt, oder sogar über mehrere Tage? Damit, dass die Daten nicht aktuell sind, muss das System ja sowieso klar kommen.



Das ist eine mögliche Umsetzung, die praktikabel sein kann. Interessant könnte auch etwas in Richtung reaktive Streams sein.
 
NicoDeluxe

NicoDeluxe

Sollte schon jede Stunde glücken, 2,3 h ist noch verkraftbar.

Wenn ich die Daten aus dem Hersteller Service ohne Prüfung auf Änderung speichere, wann soll ich in deinem Beispiel den Preis berechnen? Wir haben schon einen Trigger in MSQL gesetzt, der eine Spalte als "preis wurde geändert" auf true setzt wenn er sich ändert. Ein anderer Service hat dann die Preise neu berechnet wo true hatte.

Funktionabel, aber nicht komfortabel.

Das reine Importieren ist iwie nicht das Problem, sondern die ganze Datenaufbereitung. Vielleicht ist es das schlauste wirklich jedem Hersteller Service ein Pojo vorzulegen, "so muss es an den Master gehen" der Master empfängt die Liste an Ersatzteilen und verarbeitet diese, berechnet den Preis usw. und speichert am Ende ab.

Irgendwie nicht so einfach
 
mrBrown

mrBrown

Sollte schon jede Stunde glücken, 2,3 h ist noch verkraftbar.
Mal ganz plump gefragt:
* wie wirkt es sich aus, wenn der angezeigte Preis seit 50min nicht mehr stimmt?
* wie wirkt es sich aus, wenn der Preis seit drei Tage nicht mehr stimmt?

Irgendwie muss ja sowieso schon mit dem nicht stimmenden Preis umgegangen werden?

Wirklich relevant wird das aber nur dafür, wie Ausfallsicher das sein muss. Ist es verkraftbar, wenn (im Fehlerfall!) mal 3 Stunden keine Änderung erkannt wird? Ist es schlimm, wenn einzelne Änderungen im Nirvana verloren gehen? Reicht es vielleicht auch, dass zwar im Normalfall stündlich Änderungen kommen, aber verlorenen Änderungen nicht schlimm sind, weil Sonntag um Mitternacht immer ein voller Abgleich durchgeführt wird?
(Keine Fragen an dich, nur Gedanken die man sich machen sollte.)


Wenn ich die Daten aus dem Hersteller Service ohne Prüfung auf Änderung speichere, wann soll ich in deinem Beispiel den Preis berechnen? Wir haben schon einen Trigger in MSQL gesetzt, der eine Spalte als "preis wurde geändert" auf true setzt wenn er sich ändert. Ein anderer Service hat dann die Preise neu berechnet wo true hatte.
Das klingt schon sehr fragil...

Die Prüfung auf Änderung kann ja trotzdem statt finden, die muss nicht übersprungen werden.

In der einfachsten Variante pullt der Hersteller-Service Daten vom Hersteller und veröffentlicht dann einfach ein Event "Artikel X: 10€"
Master-Service bekommt das Event, und kann damit jetzt machen was er will. Direkt in die DB schreiben und ein Flag setzen, oder direkt den neuen Preis berechnen und nur das fertige Resultat in die DB schreiben.
Oder sogar einen weiteren Service dazwischen schalten, der empfängt das "Artikel X: 10€", berechnet den neuen Preis, veröffentlicht das dann wieder als Event, und erst das bekommt der Master-Service, der es in die DB schreibt.

Denkbar sind die viele Varianten.

(Das ganze ist übrigens auch innerhalb eines Monolithen genauso umsetzbar, Fehler beeinträchtigen dann natürlich das Gesamtsystem und nicht einzelne Services, aber als Zwischenschritt kann das durchaus praktikabel sein.)

Vielleicht ist es das schlauste wirklich jedem Hersteller Service ein Pojo vorzulegen, "so muss es an den Master gehen"
Die Services nur Daten veröffentlichen lassen, die die anderen Services auch verstehen, ist so oder so meist sinnvoll, sonst kann ja niemand was damit anfangen :)


Irgendwie nicht so einfach
Du musst dir halt bewusst machen, an welchen Punkten man sinnvoll schneiden kann, welche Grenzen es innerhalb des Systems gibt, welche "Bounded Contexts"es gibt, was für Anforderungen du in Bezug auf Skalierbarkeit, Ausfallsicherheit etc hast.

Wenn man due Grundlegenden Fragen beantwortet hat, man sinnvolle Modelle etc hat, kann man damit relativ gut weiterarbeiten.
Wenn man allerdings weder Domäne noch Anforderungen klar genug kennt, ist es wirklich schwierig :)
 
mrBrown

mrBrown

Generell noch als Anmerkung: Aus dem Monolithen einen "verteilten Monolithen" machen, bei dem alle Services über Rest kommunizieren, ist meistens nicht der beste Weg und kann potentiell sogar zu mehr Problemen führen. Bevor das einfach überstürzt gemacht wird, sollte man sich das gut überlegen - und in jedem Fall ist eine Modularisierung innerhalb des Monolithen sinnvoll und schon fast Voraussetzung.
 
D

Dukel

Wieso lässt man das pushen nicht weg und die Ziele greifen auf die gemeinsame DB zu. Dann gäbe es keinen Zeitversatz und alle hätten einen Stand.
 
mrBrown

mrBrown

Wieso lässt man das pushen nicht weg und die Ziele greifen auf die gemeinsame DB zu. Dann gäbe es keinen Zeitversatz und alle hätten einen Stand.
Den Zeitversatz gibt es durch das stündliche Pollen, das hat man in jedem Fall.

Eine gemeinsame DB kann Vorteile haben, kann aber eben auch Probleme mit sich bringen, zT wurden ja schon welche genannt. Die Services müssen alle das passende DB-Format kennen, die Daten-Verarbeitung muss man entweder in jedem Service duplizieren (zb das Preis berechnen), oder man muss das in der DB mit Flags hinterlegen und regelmäßig pollen, Probleme mit der DB betreffen dann alle Systeme, ...
 
D

Dukel

Wenn ich den Workflow richtig verstanden habe gibt es einen Import von unterschiedlichen Quellen in eine DB. Daten aus der DB werden regelmäßig an die Kunden gepusht (oder die Kunden pullen) in derren tenant DB.
Wenn man die tenant DB weg lässt und die Kunden greifen auf die Zentrale DB zu hat man keinen Zeitversatz. U.u. kann im hintergrund regemäßig in die tenant DB gecacht werden, wenn die Verbindung wegfallen sollte.
 
T

temi

Ich will mich nicht groß einmischen, aber nur zum Verständnis:

Hersteller ist nicht gleich Kunde, oder?

Kann man sich das grob so vorstellen, dass es sich um eine Ersatzteil-DB handelt, die Ersatzteile von verschiedenen Herstellern für verschiedene Kunden verwaltet? Die Preise kommen von den Herstellern und werden von den Kunden aus deiner DB abgerufen? Stellen die Hersteller eine API zum Abruf zur Verfügung oder sitzt da einer vorm Computer und tippt Preislisten? Was legt fest, welcher Kunde auf welche Ersatzteile zugreifen kann? Kann ein Ersatzteil dann auch mehreren Kunden zugeordnet sein?

Edit: Ganz naiv klingt das nach einer DB für die Teile und für jeden Hersteller ein Service, der die aktuellen Daten, wie auch immer, abruft und in der DB aktualisiert. Dazu noch ein Service, der die API für die Kunden bereitstellt, um auf die Daten zugreifen zu können.
 
Zuletzt bearbeitet:
NicoDeluxe

NicoDeluxe

Ich will mich nicht groß einmischen, aber nur zum Verständnis:

Hersteller ist nicht gleich Kunde, oder?

Kann man sich das grob so vorstellen, dass es sich um eine Ersatzteil-DB handelt, die Ersatzteile von verschiedenen Herstellern für verschiedene Kunden verwaltet? Die Preise kommen von den Herstellern und werden von den Kunden aus deiner DB abgerufen? Stellen die Hersteller eine API zum Abruf zur Verfügung oder sitzt da einer vorm Computer und tippt Preislisten? Was legt fest, welcher Kunde auf welche Ersatzteile zugreifen kann? Kann ein Ersatzteil dann auch mehreren Kunden zugeordnet sein?
Jeder der 50 Hersteller stellt seine Daten in verschiedenen Formaten bereit, einer CSV per FTP, einer hat eine REST Api, ein anderer wiederum TXT. Wie der Hersteller die Daten erfasst, kein Schimmer. Wir holen die Daten ab, stellen Sie dem User in seine DB. Der User kann dann seine Ersatzteildaten bearbeiten (Beschreibungen erstellen etc, ähnlich wie in einem Webshop) Im Anschluss stellt unser Programm API bereit zu Werkstätten. Die Werkstätten können Bestände, Preise ziehen usw. sowie Bestellungen auslösen usw

Unser Kunde+User ist der zwischen Hersteller und Werkstatt. Unser User gibt uns an, welchen Hersteller er angebunden haben möchte und diese werden dann in seine DB importiert. Der User gibt uns quasi seine Logindaten vom Hersteller und wir holen die Daten ab. Jeder Hersteller-Kunde hat dabei aber verschiedene Artikel, Preise usw die der Hersteller für seinen Kunden (unseren User) verfügbar macht. Der Quelldaten-Aufbau ist bei jedem Hersteller unterschiedlich. User A und B von HerstellerXY haben die selbe CSV-Struktur, aber nicht den selben Inhalt.

Ein Ersatzteil wird auch mehreren Kunden zugewiesen, dass ist richtig.
 
Thema: 

Microservices StrukturPlanung

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben