Spring Boot Microservices und Entitäten

Diskutiere Spring Boot Microservices und Entitäten im Application Tier Forum; Hallo zusammen, ich habe ein Problem mit dem Aufbau meines Systems: Ich habe 15 Services die alle samt das gleiche machen, nur anders....

  1. NicoDeluxe
    NicoDeluxe Mitglied
    Hallo zusammen,

    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?
     
  2. Vielleicht hilft dir dieses Training hier weiter.
  3. httpdigest
    httpdigest Aktives Mitglied
    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?
     
    Zuletzt bearbeitet: 26. Juli 2018
  4. NicoDeluxe
    NicoDeluxe Mitglied
    Hi ja genau, die nutzen eine DB vorerst.

    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
     
    Zuletzt bearbeitet: 27. Juli 2018
  5. mihe7
    mihe7 Bekanntes Mitglied
    Definiere "umfangreich".

    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.
     
  6. NicoDeluxe
    NicoDeluxe Mitglied
    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
     
  7. mihe7
    mihe7 Bekanntes Mitglied
    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.

    Why not? Die DB ist auch nur ein Service :)
     
  8. Wenn du Java lernen möchtest, empfehlen wir dir diese Online-Training hier
Die Seite wird geladen...

Spring Boot Microservices und Entitäten - Ähnliche Themen

Spring Boot Test
Spring Boot Test im Forum Datenbankprogrammierung
Authentifizieren mit SpringBoot
Authentifizieren mit SpringBoot im Forum Netzwerkprogrammierung
Spring Boot javax.mail
Spring Boot javax.mail im Forum Application Tier
Spring Boot: Logfiles wie organisieren?
Spring Boot: Logfiles wie organisieren? im Forum Web Tier
Spring Boot GET
Spring Boot GET im Forum Web Tier
Thema: Spring Boot Microservices und Entitäten