Microservice Projekt verwalten

Schuriko

Bekanntes Mitglied
Ich möchte ein kleines Microservice Projekt realisieren. Mein Testprojekt soll aus den Services

- registrieren
- anmelden
- katalog anfordern
- buchen
- bezahlen

bestehen. Muss ich jetzt für den Service einen eigenes Projekt aufstellen oder kann man es auch in einem Projekt realisieren?
BTW ich arbeite mit der Eclipse IDE
 
Wenn es ein Projekt ist, ist kein Microservice (zumindest nach reiner Leerer)

Ein Microservice ist unabhängig von anderen, daher sollten sie unterschiedliche Projekte sein. Den es soll ohne Probleme möglich sein, dass verschiedene Teams sich um verschiedene Microservices kümmern.
 
Und Funktionalitäten, die zusammen gehören, sollte man zusammen lassen. Du machst nicht für jeden möglichen Request einen eigenen Microservice.

Also z.B. hört es sich so an, als ob registrieren und anmelden zusammen gehören - als das, was ich User Verwaltung nennen würde.
 
Wenn es ein Projekt ist, ist kein Microservice (zumindest nach reiner Leerer)

Ein Microservice ist unabhängig von anderen, daher sollten sie unterschiedliche Projekte sein. Den es soll ohne Probleme möglich sein, dass verschiedene Teams sich um verschiedene Microservices kümmern.
Ja, genau, deshalb frage ich mich gerad wie man diese ggf. zusammenhalten kann? Deshalb wäre es ja an und für sich nicht schlecht es in einem Projekt zu halten - so zumindest meine Überlegung. Aber ansonsten gebe ich dir voll und ganz recht.
 
Und Funktionalitäten, die zusammen gehören, sollte man zusammen lassen. Du machst nicht für jeden möglichen Request einen eigenen Microservice.

Also z.B. hört es sich so an, als ob registrieren und anmelden zusammen gehören - als das, was ich User Verwaltung nennen würde.
Vom Prinzip ja, aber anmelden wird zig mal durchgeführt wird und registrierung nur einmal. (Immer pro User gesehen)
 
Vom Prinzip ja, aber anmelden wird zig mal durchgeführt wird und registrierung nur einmal. (Immer pro User gesehen)
Darum geht es ja nicht. Es geht darum, dass ein Microservice eine abgeschlossene Funktionalität hat, die für sich alleine Nutzen hat. Die für sich vollständig beschreibbar ist. Die jemand alleine - ohne (größere) Absprache mit Personen, die andere Microservices entwickeln kann.

Sie sollten auch eigene Datenhaltungen haben - sofern sie überhaupt Daten halten.
 
Sie sollten auch eigene Datenhaltungen haben - sofern sie überhaupt Daten halten.
Das ist der ganz entscheidende Punkt!
- Ein User registriert sich: Wo landen denn die Daten? Doch wohl in dem Datenpool, in dem auch ist:
- Ein User meldet sich an.

Ist ja klar: Der User, der sich registriert hat, will sich danach ja dann auch anmelden.
 
Und den anderen Punkt Zusammenarbeit:

Die Projekte sollen getrennt sein. Aber natürlich kann es Abhängigkeiten untereinander geben. Da geht es aber um Zugriffe auf die definierte API.

Daher macht es z.B. Sinn, die API als erstes festzulegen. Swagger bietet sich da z.B. an.
 
Darum geht es ja nicht. Es geht darum, dass ein Microservice eine abgeschlossene Funktionalität hat, die für sich alleine Nutzen hat. Die für sich vollständig beschreibbar ist. Die jemand alleine - ohne (größere) Absprache mit Personen, die andere Microservices entwickeln kann.

Sie sollten auch eigene Datenhaltungen haben - sofern sie überhaupt Daten halten.
Okay. Wie würdest du es denn realisieren, wenn ein Datenbestand von einem anderen Datenbestand abhängig ist. In meinem obigen Beispiel z.B. muss "Buchen" wissen, wer (User) was (Katalog) gebucht hat.
 
Dann greift der über Services darauf zu.

Aber beschreib doch mal deinem Microservice "Buchen". Welche Funktionalität stellt der nach außen bereit?
 
Aber beschreib doch mal deinem Microservice "Buchen". Welche Funktionalität stellt der nach außen bereit?
Kunde (User) sucht aus einem Katalog irgendetwas aus. Meldet sich an, bzw. wenn er nicht regisitriert ist, dann muss er sich vorher registrieren und bucht (kauft) dann aus dem Katalog das gewünschte Produkt.

Dann greift der über Services darauf zu.
Aber bei getreten Datenhaltung. Hier ein Beispiel soweit ich dich verstanden habe. N User sind über einer Tabelle auf N Datenbanken verteilt greifen auf N Produkte aus N Kataltogen auf N Datenbanken zu.
 
Zuletzt bearbeitet:
Kunde (User) sucht aus einem Katalog irgendetwas aus. Meldet sich an, bzw. wenn er nicht regisitriert ist, dann muss er sich vorher registrieren und bucht (kauft) dann aus dem Katalog das gewünschte Produkt.
Das ist keine Service Beschreibung. Sondern eine Operation.

Ein Service bietet Funktionalität und einen Business Case. Es geht um die Beschreibung deines "Buchen" Services. Da dürfen keine Dinge vorkommen, die in der Hoheit anderer Services liegen. Es muss lose gekoppelt sein und seine eigene Identität haben.

Buchen klingt für mich nicht nach einem Service sondern nach einer Operation in einem Service.

Du läufst gefühlt gerade hier rein: http://chrisrichardson.net/post/antipatterns/2019/05/21/antipattern-more-the-merrier.html 🙂
 
Mal so in den Raum gesponnen, ich würde da maximal drei Services sehen:;

User-Service: Kümmert sich um die gesamte User-Verwaltung, Anmeldung, Registrierung, Dinge wie Passwort vergessen etc.

Zahlungs-Service: Kümmert sich um die Zahlung und die Kommunikation mit einem externen Zahlungsdienstleister (egal ob Paypal, Stripe, Klarna, etc.)

Buchungs-Service: Kümmert sich um das gesamte Buchungszeug

Das heißt z.B. der User-Service braucht definitiv keinerlei Informationen vom Rest.
Der Buchungs-Service braucht auch nicht unbedingt den User-Service, er braucht Informationen wer da buchen will. Ob der User authentifiziert ist oder nicht ist ihm egal. E
Der Zahlungs-Service braucht die Informationen die nötig sind, um eine Zahlung abzuwickeln - er muss nicht zwangsweise wissen was exakt bezahlt wird.
 
Das heißt z.B. der User-Service braucht definitiv keinerlei Informationen vom Rest.
Okay das stimmt
Der Buchungs-Service braucht auch nicht unbedingt den User-Service, er braucht Informationen wer da buchen will. Ob der User authentifiziert ist oder nicht ist ihm egal. E
Dieses Verstehe ich gerade gar nicht, denn der Buchungsservice muss doch wissen von welchem User was gebucht wird, oder verstehe ich da gerad etwas falsch?

Der Zahlungs-Service braucht die Informationen die nötig sind, um eine Zahlung abzuwickeln - er muss nicht zwangsweise wissen was exakt bezahlt wird.
Der Zahlungs-Service muss schon wissen, was gezahlt werden muss und von wem. Oder scherzhaft ausgedrückt. Ich zahle doch nicht deine Rechnung für Sachen, die du gar nicht bestellt hast. 😀 😀 😀
 
Okay das stimmt

Dieses Verstehe ich gerade gar nicht, denn der Buchungsservice muss doch wissen von welchem User was gebucht wird, oder verstehe ich da gerad etwas falsch?
Er muss eine User-Information bekommen. Aber wo diese Information herkommt, ist ihm egal. Das heißt, der bekommt vielleicht eine User-ID oder User-Namen.

Der Zahlungs-Service muss schon wissen, was gezahlt werden muss und von wem. Oder scherzhaft ausgedrückt. Ich zahle doch nicht deine Rechnung für Sachen, die du gar nicht bestellt hast. 😀 😀 😀
Doch, für den Zahlungsservice ist das egal. Der braucht Informationen darüber was er auf der Rechnung anzeigen soll. Ob da gebucht wurde oder wo immer die Information herstammt - ist ihm egal.
 
Das ist meines Erachtens Fluch & Segen von Microservices. Einerseits sind schön gekapselt und in sich konsistent.

Ein Buchunggservice interessiert sich ob und wie ein User authentifiziert wurde - da ist wer anders für zuständig.
Ein Zahlungsservice interessiert sich dafür, ob das wirklich verbindlich gebucht wurde - da ist wer anders für zuständig.

Das macht die Services selber managebar. Aber dafür ist managen "Wer ist eigentlich für was zuständig" und "was ist eigentlich der richtige Schnitt" aufwendiger.
 
Was auch noch nicht wichtig ist - es gibt keine Methode, die dazu führt, dass Komplexität verschwindet. Microservices lassen Komplexität, die es bei einem Monolithen existiert nicht verschwinden. Sie wird nur auf andere Ebenen transformiert, wo sie (hoffentlich) managebarer ist - aber sie ist immer noch da.
 
Also z.B. hört es sich so an, als ob registrieren und anmelden zusammen gehören - als das, was ich User Verwaltung nennen würde.
User-Service: Kümmert sich um die gesamte User-Verwaltung, Anmeldung, Registrierung, Dinge wie Passwort vergessen etc.

Das kann man auch anders schneiden, User-Verwaltung und Anmeldung sind relativ gut trennenbar und beides ist (im wesentlichen) getrennt voneinander nutzbar.
Ein Service kümmert sich um Registrieren, Passwort-Vergessen, Nutzer-Profil-Verwaltung etc, das ist in sich geschlossen und allein entwickelbar. Das, was zum Anmelden nötig ist (Nutzername, Passwort, Rollen, etc) veröffentlicht der direkt per Event an andere Services.
Und ein andere Service ist für's reine Anmelden da, der hält selbst Nutzernamen, Passwörter etc, und ist damit nicht von anderen Services abhängig, und kümmert sich nur um Authentifizierung.
 
Das kann man auch anders schneiden, User-Verwaltung und Anmeldung sind relativ gut trennenbar und beides ist (im wesentlichen) getrennt voneinander nutzbar.
Ein Service kümmert sich um Registrieren, Passwort-Vergessen, Nutzer-Profil-Verwaltung etc, das ist in sich geschlossen und allein entwickelbar. Das, was zum Anmelden nötig ist (Nutzername, Passwort, Rollen, etc) veröffentlicht der direkt per Event an andere Services.
Und ein andere Service ist für's reine Anmelden da, der hält selbst Nutzernamen, Passwörter etc, und ist damit nicht von anderen Services abhängig, und kümmert sich nur um Authentifizierung.
ich zitiere mich selber
und "was ist eigentlich der richtige Schnitt" aufwendiger.
😀
 

Zurück
Oben