Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich habe ein Problem mit dem Aufbau meines Systems:
Ich habe 15 Services die alle samt das gleiche machen, nur anders.
Beispiel:
Jeder Service gehört einem Autohersteller an, der Service holt alle 10 Minuten über eine API die aktuellen Fahrzeuge vom Hersteller.
Dabei werden Objekte vom Typ Auto erstellt und gespeichert in einer DB.
Wenn ich nun in jedem Service eine Entity "Auto" erstelle und irgendwann was anpasse, muss ich das i allen 15 Services machen, dass kann nicht im Sinne des Erfinders sein.
Ich habe nun testweise ein jar gewacht welches ich einbinde, so muss ich nur 1 x das Auto verwalten und alle Services die dieses jar implementiert haben, haben Zugriff auf das neue Auto oder dessen Änderungen.
Gibts da noch eine bessere Möglichkeit sowas zu handeln?
Aus diesem Grunde solltest du Microservices eher an Domain Boundaries errichten und nicht an Funktionen innerhalb einer Domäne. Wenn sich die Definition dessen, was ein Auto ist/ausmacht, ändert, dann sollte das nur einen einzigen Service betreffen. Das sollte dann entweder dein einziger Microservice sein oder es sollte derjenige sein, der sich für das geänderte Detail des Autos interessiert. Nicht jeder Microservice sollte dasselbe Verständnis davon haben, was ein Auto ist/was es ausmacht.
Ich würde mal sagen, der Trick beim Microservice-Schnitt ist, dass eben gerade nicht alle Microservices dasselbe Datenmodell verwenden, sondern dass sie nur ein gemeinsames Verständnis von der "Identität" eines Datensatzes haben und jeder Service sich für einen anderen Teil des Datensatzes interessiert und diesen verwaltet.
Denn sonst hast du mit Microservices gegenüber einem Monolithen ja nicht viel gewonnen, außer, dass du das Deployment-Modell auf mehrere Prozesse verteilst. Aber die Kopplung/Kohäsion besteht ja trotzdem zwischen allen Services und dem gemeinsamen Datenmodell.
EDIT: Wenn aber, wie du sagst, die einzige Variabilität/Parameterisierung deines Services darin besteht, jeweils unterschiedliche APIs zu bedienen, die für den jeweiligen Hersteller ein Auto holen und das Auto dabei dann auch immer dasselbe Schema hat, dann hast du ja sowieso nur eine Codebasis mit Adaptern für die einzelnen Autohersteller. Da würde ich nicht von mehreren Microservices sprechen, sondern nur von einer horizontalen Skalierung/Instanziierung deines einen Services. Wahrscheinlich benutzen dann alle Instanzen auch dieselbe Datenbankinstanz?
Mein Plan war je Hersteller einen eigenen Service laufen zu lasse, da die Daten echt umfangreich sind die ich da bekomme.
So würde der eine Service weiter laufen, auch wenn der andere nicht mehr funktioniert.
Du hast geschrieben, jeder Service sollte die für einen eigenen Teil des Datensatzes interessieren, kannst du am
Autobeispiel bitte erklären? Ich verstehe es so, dass ein Service die technischen Daten wie PS, Hubraum verwaltet, ein andere die Ausstatuutung innen und so weiter?!
Plan war:
1 MS für BMW
1 MS für Audi
1 MS für VW
1 MS für DB CRUD
die zapfen die Hersteller API an und senden es an den Service DB CRUD welcher die Daten speichert, updated usw
Die DB sollte dann noch tenant werden, da jeder User eine eigene DB bekommen soll, damit er seine Autos selbst bearbeiten kann und eigene hinzufügen kann
Wenn die Software unterschiedliche Problembereiche abdeckt, dann erhältst Du für jeden Bereich ggf. ganz unterschiedliche Beschreibungen für ein Auto. D. h. jeder Bereich modelliert das Auto auf seine eigene Weise. Im Extremfall haben diese Modelle nur noch die VIN gemeinsam. So werden Vertrieb und Produktion von einem Auto teils erheblich unterschiedliche Vorstellungen haben.
Umfangreich im Sinne von viel. 500.000 Datensätze prüfen Hersteller, daher jeder Hersteller ein eigener Service.
Ich habe nun erstmal jedem Herstellerservice seine eigene Verbindung zur DB erstellt, somit entfällt der Datenbankservice, welcher mit CRUD völlig zugeballert wurde. Jeder Hersteller-Service verwaltet nun seine Fahrzeuge selber. So das passt, damit komme ich denke am besten. Zwar hab ich jetzt nach wie vor meine jar welche immer das aktuelle "Auto" hat aber es funktioniert. Wenn ich nun Änderungen am "Auto" mache, können alle Hersteller-Services dieses Attribut nutzen
Das ist evtl. ein Grund für jeweils eine eigene Instanz eines Services aber nicht für jeweils eigene Services. Siehe dazu den letzten Abschnitt des Posts von @httpdigest.
Ich habe nun erstmal jedem Herstellerservice seine eigene Verbindung zur DB erstellt, somit entfällt der Datenbankservice, welcher mit CRUD völlig zugeballert wurde.