Microservice Design


#1

Hallo zusammen,

ich überlege grad, wie ich meine Services am besten Designe. Folgende Überlegung:

Ich habe 3 Services, die Daten von Herstellern holen, sagen wir Fahrzeugdaten. Diese Fahrzeugdaten sollen alle in eine Datenbank geschrieben werden.

Dazu habe ich:

  • Datenbankservice der via REST Fahrzeuge entgegennimmt und ausgibt
  • Entityservice der FahrzeugPOJOs bereit stellt, diese POJOs stehen dann jedem Service zur Verfügung (eine Änderung sofort überall verfügbar)
  • je Hersteller einen Service, der wiederum die HerstellerAPI konsumiert und Fahrzeug-Objekte erstellt, die dann dem DB Service fürs speichern übergeben werden.

Was würdet ihr daran verbessern? Sollte jeder Hersteller vielleicht seine eigene Datenbankverbindung haben? Dann müsste man aber in jedem Service die DB Einstellungen ändern, wenn es Änderungen gibt.

Gleiches für den Entity-Service. Angenommen ich erweitere mein Fahrzeug um das Attribut Farbe. Dann müsste ich in jedem Service erstmal der Fahrzeug.java die neue Variable hinzufügen. Mit der Dependancy zu dem Service, kann ich direkt beim Objekt erstellen setFarbe() nutzen, wenn ich das Attribut in der “Fahrzeug-Klasse” im Entity-Service eingefügt hab.

Ich freue mich auf eure Anregungen!

Edit: grad das hier gefunden

Jeder Service sollte also seine eigene Datenverbindung haben? Das verwirrt mich jetzt. Wie würdet ihr meinen Case hier aufbauen. zb hab ich 3 Hersteller Audi, VW, BMW jeder hat eine (jeweils unterschiedliche) API von denen ich die aktuellen Fahrzeugdaten holen kann und lokal speichern will.


#2

Ja.

MS sollen “unabhaengig” sein und sollen keinen Code teilen.


#3

Danke Maki, hab ich befürchtet.

Also hab ich meinen AudiService, der die API anzapft, Fahrzeug-Objekte erstellt und in die DB schreibt. Der Service hat dann auch ein Fahrzeugrepository usw?

Dann hab ich das Gleiche für VW und BMW? jeweils der gleiche Code? Widerspricht das nicht der Konvention “Code wiederverwenden”? Aber gut bei MS macht das Sinn, da ja jeder Service sein eigenes Programm ist quasi


#4

Kommt natürlich immer auf die größe an. Aber es kann durchaus als ein Service durchgehen - welcher die Daten abholt und in einem einheitlichen Datenformat bereit stellt. Deine Anwendung könnte dann eben diese Resource abfragen.


#5

@Tomate_Salat in Wirklichkeit sind es 60 Hersteller. Problem ist, dass die APIs teilweise nicht gut sind und immer mal wieder offline sind. Ich würde daher alles von einander getrennt halten wollen, dann kann die “Hyundai-API” offline sein, was dann den HyundaiService stört, aber die anderen funktionieren weiter.

Aber alle 60 Hersteller, sollen auf ein Typ Fahrzeug Mappen, sodass die Fahrzeuge alle einheitlich sind.


#6

Ich hab den Eindruck dass deine Erwartungshaltung nicht richtig ist.

Warum genau willst du MicroServices einsetzen?

zb. haben MS u.a. den Vorteil, dass die Organisation skalieren kann, man kann die Einzelteile des Systems sehr gut gegeneinander abschirmen durch APIs, die Details der Implementierung der einzelnen Services ist abstrahiert, bis hin zur Sprache und welche Art von Datastore verwendet wird.
Das alles “kostet”, MS sind kein Allheilmittel das alle Probleme loest, man tauscht einen Satz Probleme gegen einen anderen Satz Probleme.

Mir ist nicht klar ob dir klar ist was du dir da ausgesucht hast :slight_smile:
Es gibt viele Wege ein Problem zu loesen, fuer mich klingt es so als ob du dir erst die Loesung ausgesucht hast bevor dir das zu loesende Problem klar ist und vor allem welche Konsequenzen die von dir ausgesuchte Loesung hat.

Monolithen haben auch Vor- & Nachteile, Code Wiederverwendung ist ein grosser Vorteil.
Kapselung, Skalieren und Abstraktion sind keine.


#7

meine aktuelle Anwendung ist ein Monolith. Die ist nicht skalierbar, stetig gibt es irgendwelche Probleme die den Reboot der gesamten Anwendung erfordern oder wenn ich Erweiterungen einbaue, muss ich das gesamte System neu deployen. Dem will ich mit MS entgegen wirken. Zudem will ich unterschiedliche Clients anbinden (app, web, desktopanwendung zb) würde im Monolithen auch gehen, aber mit MS ist das etwas einfacher find ich.


#8

IMHO muessen da schon sehr gute Gruende da sein um nun alles neu zu schreiben.

Wie aeussert sich das bzw. welche Limitierungen gibt es konkret?

“irgendwelche Probleme” gibt es mit MS dann fuer jeden einzelnen Service.

Dafuer musst du dich nicht um Versionierung und Aufwaerst-/Abwaertskompatiblitaeten der einelzen Dienste kuemmern, ist ja ales aus einem Guss.

Genau, geht auch mit Monolithen.

Irgendwie glaube ich nicht dass das eine Einsicht ist zu der der rational gekommen bist wenn du gerade erst anfaengst die Konsequenzen von MS Architekturen zu entdecken wie man an deinem Ausgangsbeitrag sieht.

Ist aber egal wenn du das sowieso machen willst um dabei etwas zu lernen :slight_smile:


#9

Als Beispiel fuer MS: Uber
Von 300 Entwicklern auf ueber 2500 Entwicklern in zwei (?) Jahren angewachsen (und Millionen von Kunden/Usern weltweit), die haben mittlerweile ueber 3000 MS am laufen, jeder Entwickler im Schnitt ueber 10000 Source Repos ausgecheckt.
Die MS Architektur hat ihren Preis der da gerechtfertigt war.


#10

Meine Anwendung ist von Anfang nicht wirklichbgut aufgebaut. Mit der Zeit kamen immer neue Dinge dazu die man zu beginn nicht bedacht hat oder nicht gefordert waren. Wenn ich da nun was neues einbaue gibt es immer wieder stellen wo was aufgrund der Neuerung umgebaut werden muss. Wenn ich mit MS nun ein neues Feature einbauen will zb User kann Rechnungen für die Fahrzeuge schreiben. Der ich das als einfacher an: neuer Service für die Rechnungslegung , Frontend erweitern und fertig. Wenn ich das in meiner bestehenden Lösung machen will wäre das nicht so einfach möglich.

Die alte Anwendung ist schon abgeschrieben, an der will ich gar nicht weiter festhalten.


#11

Das ist vollkommen normal in der SW Entwicklung.
Staendiges refactoring und ein Agiles Prozessmodell helfen um das Chaos im Griff zu behalten.

Das wird IMMER so sein!

Ganz ehrlich, ich habe den Eindruck dass du da sehr naiv bzw. unerfahren bist.
Du wirst bestehende MS auch aendern muessen wenn du etwas neues hinzufuegst, aber mit MS muessen dann die Aenderungen in mehreren Schritten in mehreren MS gemacht werden, und zwar so, dass die APIs sowohl Vorwaerts- als auch Rueckwaertskompatibel zwischen den unterschiedlichen MS Versionen sind.
Configurationmanagement ist recht komplex mit MS verglichen mit Monolithen.

Genau das ist einfacher mit einem Monolithen!

Ich hab bis jetzt nichts gelesen was den Einsatz von MS rechtfertigen wuerde, nur falsche Vorstellungen von MicroServices und SW Entwicklung im allgemeinen.

Wie dem auch sei, ich denke ich kann da nix mehr hinzufuegen, wuensche dir viel Erfolg :slight_smile:


#12

vielen Dank :slight_smile: Denk ich werd da viel neues bei lernen, auch wenn es vielleicht unnötig scheint MS zu nutzen, so bringt es mich persönlich weiter