"Backend" bei Microservices

[AndiE]

Mir ist eine Frage gekommen, und vielleicht kann mir jemand helfen. Es ist übrigens keine Hausaufgabe oder so, da ich das Programmieren als Hobby betreibe.

Ich nehme mal diese Usestory an. Es geht um den Einkauf von Stühlen per Internet:

Der Nutzer meldet sich an, oder registriert sich. Dann wählt der Nutzer aus dem Katalog Form und Bezug der Stühle und legt die Anzahl fest, die er haben möchte. Dann bestellt er die Stühle, wobei er verschiedene Zahlungsarten auswählen kann: Vorauskasse und Rechnung. Die abgeschickten Bestellungen werden nun von der Finanzabteilung überprüft. Dabei wartet man entweder auf den Geldbetrag, um dann die Bearbeitung freizugeben. Oder es wird gleich mit der Bearbeitung begonnen. Nach der Bearbeitung erfolgt die Auslieferung. Wurde Vorauskasse gewählt, ist der Auftrag hiermit zu Ende. Wurde Rechnungskauf gewählt, erfolgt mit der Auslieferung die Rechnungsstellung. Ist die Rechnung bezahlt, ist der Auftrag zu Ende.

In der Swimlane- Darstellung hätte ich hier drei Bahnen, denn ich habe den Nutzer, die Bearbeitung und die Finanzbuchhaltung als Akteure. Den Nutzer würde ich ja über eine Webseite mit Microservices zugreifen lassen( Spring Boot).

Wie würde man den Zugriff der anderen beiden Akteure lösen? Auch mit Microservices, nur ohne Webseite? Könnte ich damit auch die CRUD-Funktionalität lösen, um z.B. neue Preise einzupflegen oder das Sortiment zu ändern?

 

[mihe7]

Ich verstehe die Frage irgendwie nicht. Ob eine Funktionalität zur Verfügung steht, hängt doch nicht davon ab, ob diese von einem Monolithen oder einem Microservice angeboten wird und natürlich kann eine Funktionalität an Rollen und Berechtigungen hängen.

 

[AndiE]

Ich versuche das mal anders zu erklären. In einem üblichen Tutorial wird die Erstellung der Webseite mit den Microservices behandelt, die für den Umgang mit dem Besteller wichtig sind. Ich würde, nach meinem rudimentären Wissen über Spring Boots, hier Services für den Nutzer, die Ware, die Bestellung und die Zahlungsart erstellen, da diese sich alle mit einer UID beschreiben lassen.

Ich in mir nicht ganz sicher, aber ic glaube, dass ich etwa so eine Struktur hätte:
/seat/
/seat/customer
/seat/item
/seat/paying
/seat/bill

Damit würde man die vier Microservices aufrufen, wobei "seat" für den Einsprungspunkt in das Projekt steht.

Aus gegebenen Gründen wären die Microservices für "bill"-Rechnung hier nur für einen Vorgang "schreibend und lesend".

Die Finanzabteilung und die Fertigung braucht aber natürlich Listen mit mehreren Vorgängen.

Wie würde man das planen und umsetzen?

 

[mihe7]

Das sind erstmal einfach nur Endpunkte für Webservices. Microservice-Architektur bedeutet nicht, für jeden Endpunkt einen Microservice zu schreiben, sondern mehrere unabhängige Anwendungen (Prozesse) zu haben, die lose gekopptelt zusammenarbeiten (können).

Man könnte also ein Bestellsystem (z. B. in Form eines Webshops) haben, das Artikel-, Kunden- und Bestelldaten verwaltet. Wird die Bestellung aufgegeben, gibts eine Benachrichtigung, die z. B. vom Finanzsystem behandelt wird. Hier kann dann eine Freigabe erfolgen. Dieses fachliche Ereignis wird dann z. B. vom Bestellsystem in der Art behandelt, dass der Status der Bestellung geändert wird, während das Fertigungssystem einen Fertigungsauftrag erzeugt.

Klar ist: Microservices führen Komplexität ein. Es braucht Kommunikation und die kann schiefgehen. Die ACID-Eigenschaften gibts in verteilten Systemen nicht, hier gibts nur eventual consistency (BASE Transactions) aufgrund des CAP-Theorems, d. h. das "Versprechen", dass die Daten "irgendwann einmal" einen konsistenten Zustand erreichen werden. Das führt zur Notwendigkeit, den Fehlerfall fachlich zu entscheiden.

 

[temi]

Spring Boots

Sind damit Springerstiefel gemeint?

Sorry, musste sein..

 

[temi]

Man könnte also ein Bestellsystem (z. B. in Form eines Webshops) haben, das Artikel-, Kunden- und Bestelldaten verwaltet. Wird die Bestellung aufgegeben, gibts eine Benachrichtigung, die z. B. vom Finanzsystem behandelt wird. Hier kann dann eine Freigabe erfolgen. Dieses fachliche Ereignis wird dann z. B. vom Bestellsystem in der Art behandelt, dass der Status der Bestellung geändert wird, während das Fertigungssystem einen Fertigungsauftrag erzeugt.

Kurz eingehakt: Wie geschieht die Kommunikation von Microservices untereinander? Über die "normale" REST-Schnittstelle oder was anderes oder am besten gar nicht?

 

[LimDul]

Kurz eingehakt: Wie geschieht die Kommunikation von Microservices untereinander? Über die "normale" REST-Schnittstelle oder was anderes oder am besten gar nicht?

Ich hab zwar wenig Erfahrung mit Microservice Architektur, aber REST halte ich für eine nicht ideale Alternative. Rest ist synchron, damit hängt die Verfügbarkeit des Service A automatisch von der Verfügbarkeit des Service B ab. Wenn das an jeder Stelle zur Kommunikation genutzt wird, erreicht man am Ende einen verteilten Monolithen.

Daher sind so Sachen Apache Kafka, wo es eine asynchrone Kommunikation gibt, der deutlich bessere und fehlertolerantere Ansatz.

 

[temi]

Daher sind so Sachen Apache Kafka, wo es eine asynchrone Kommunikation gibt, der deutlich bessere und fehlertolerantere Ansatz.

Ist das dann eine zusätzliche Schnittstelle? Die Services müssen ja nicht zwangsläufig auf der selben Maschine laufen, es kann damit also keine interne Kommunikation sein.

 

[thecain]

Mal so als Input: https://microservices.io/patterns/data/transactional-outbox.html Das ist jetzt aber dann viel mehr im detail als die Frage... Finde abee die Seite allgemein sehr informativ

 

[LimDul]

Ist das dann eine zusätzliche Schnittstelle? Die Services müssen ja nicht zwangsläufig auf der selben Maschine laufen, es kann damit also keine interne Kommunikation sein.

Das ist - simpel gesprochen - eine Message-Queue. Du kannst da Dinge reinschreiben oder auf Events lauschen. Die Kommunikation zu Kafka hin kann über diverse Schnittstellen auch Rest - erfolgen. Aber damit entkoppelt man Sender und Empfänger voneinander.

 

[mihe7]

Sorry, war gerade verhindert. Ergänzend: am besten ist es natürlich, wenn die Services untereinander gar nicht kommunizieren müssen. Das Problem ist: wenn ein Service A zur Verarbeitung einer Anfrage einen Service B hart benötigt, dann bilden die beiden bzgl. der Anfrage eine Einheit.

 

[LimDul]

Sorry, war gerade verhindert. Ergänzend: am besten ist es natürlich, wenn die Services untereinander gar nicht kommunizieren müssen. Das Problem ist: wenn ein Service A zur Verarbeitung einer Anfrage einen Service B hart benötigt, dann bilden die beiden bzgl. der Anfrage eine Einheit.

Was ich da wichtig finde, ist das was ich rot markiert habe. Das ein Service aktiv wird, weil ein anderer eine Anfrage verarbeitet hat oder das ein Service mit Verarbeitung einer Anfrage dafür sorgt, das nun jemand anders aktiv wird - ist vollkommen normal. Und genau dafür eignen sich Message Queues sehr gut, weil ich da nach dem Prinzip "Fire & Forget" arbeiten kann.

 

[mihe7]

Was ich da wichtig finde, ist das was ich rot markiert habe.

Ja, das wollte ich mit "hart benötigt" ausdrücken.

Ein einfach mal eben aufgeteilter Monolith macht keinen Sinn, weil dann der Bestellservice für eine Bestellung z. B. die Kundendaten aus dem Kundenservice abrufen würde, um die Anschriften zu ermitteln und damit zwangsweise fehlschlägt, wenn der Kundenservice nicht zur Verfügung steht. Das führt die Microservice-Architektur ad absurdum.