Wo sollte Geschäftslogik in der Microservice-Architektur stehen?

Ich versuche immer noch, mich mit der Microservice-Architektur zu beschäftigen, da ich an einen monolithischen Ansatz gewöhnt bin

Angenommen, wir versuchen, ein extrem vereinfachtes Uber-Buchungssystem aufzubauen. Um die Dinge zu vereinfachen wir sagen wir , wir haben 3 - Dienste und einen Gateway - api für die Kunden: Booking, Drivers, Notificationund wir haben die folgenden Workflow:

Beim Erstellen einer neuen Buchung:

1. Überprüfen Sie, ob der bestehende Benutzer bereits eine Buchung hat
2. Liste der verfügbaren Treiber abrufen
3. Senden Sie eine Benachrichtigung an die Fahrer, um die Buchung abzuholen
4. Der Fahrer holt die Buchung ab

Nehmen wir an, alle Nachrichten werden über einen http-Aufruf und nicht über einen Messaging-Bus wie kafka gesendet, um die Dinge einfach zu halten.

In diesem Fall dachte ich, dass der BookingService die Überprüfung auf vorhandene Buchungen durchführen kann. Aber wer sollte dann die Liste der verfügbaren Treiber und Benachrichtigungen erhalten? Ich denke darüber nach, es auf Gateway-Ebene zu tun, aber jetzt ist die Logik in zwei Bereiche unterteilt:

• Gateway - Liste der verfügbaren Treiber abrufen + Benachrichtigungen senden
• Booking - Überprüfen Sie die bestehende Buchung

Und ich bin mir ziemlich sicher, dass das Gateway nicht der richtige Ort dafür ist, aber ich habe das Gefühl, wenn wir es im BookingService tun , wird es eng miteinander verbunden?

Was passiert, wenn wir ein anderes Projekt haben, das das Buchungssystem wiederverwenden möchte, aber über eine eigene Geschäftslogik verfügt? Aus diesem Grund habe ich darüber nachgedacht, dies auf Gateway-Ebene zu tun, damit das neue Projekt-Gateway eine eigene Geschäftslogik haben kann, die von der vorhandenen getrennt ist.

Ich nehme an, eine andere Möglichkeit besteht darin, dass jedes Projekt einen eigenen Buchungsservice hat, der mit dem Hauptbuchungsservice spricht, aber ich bin mir nicht sicher, was hier der beste Ansatz ist :-)

Die Leute hören oft "Mikro-Service" und denken "Nano-Service", was zu Verwirrung führen kann. Dies sind Mikro -services, so dass Sie nicht über einen separaten Service für jede einzelne Einheit benötigen. Alles, was Sie versuchen zu tun, sollte in den bookingund notificationDiensten sein. Sie benötigen den driverService nicht (für eine der von Ihnen beschriebenen Aktivitäten).

Das Abrufen einer Liste der zur Buchung verfügbaren Treiber fällt unter den bookingDienst. Eine häufige Gefahr besteht darin, verwandte Aktivitäten nicht in demselben Dienst zu gruppieren. Dies wird als geringe Kohärenz bezeichnet und ist sehr schlecht. Denken Sie daran, dass Sie Dinge nach Problemdomänen und nicht nach Entitäten in einem Dienst gruppieren.

Was die Wiederverwendung betrifft, besteht der Vorteil eines separaten Mikrodienstes darin, dass Sie jetzt drei separate Teams haben können, die Apps für Endverbraucher erstellen. Ein Team für die Standard-HTML-Web-App, eine Android-App und eine iOS-App. Alle diese verschiedenen Anwendungen können völlig unterschiedlich erstellt werden und sehen für ihre jeweilige Plattform angemessen aus (ohne Code zu wiederholen). Der bookingServicecode wird von allen drei Apps wiederverwendet, da alle drei Apps http-Anrufe an den Service tätigen und stattdessen einen eigenen Buchungscode haben.

Ein typischer Buchungsablauf würde folgendermaßen aussehen:

1. Die Android-App ruft den bookingDienst auf, um eine Liste der verfügbaren Treiber zu erhalten
2. Der Buchungsservice gibt eine Liste der Fahrer an die App zurück
3. Der Benutzer wählt dann seinen Treiber aus und die App ruft die "Buch" -Methode des bookingDienstes auf
4. Der bookingService-Service ruft den notificationService mit den Buchungsdetails an
5. Der notificationService sendet eine Benachrichtigung an den Fahrer und benachrichtigt ihn über die Buchung
6. Die Fahrer-App sendet eine Nachricht an den notificationDienst, wenn sie sich innerhalb einer Meile vom Kunden befinden
7. Der notificationDienst sendet die Warnung an den Kunden, dass sein Fahrer fast da ist

Hoffe das hat geholfen; Denken Sie daran, es handelt sich um Mikrodienste, nicht um Nanodienste. Versuchen Sie nicht, dieselbe Problemdomäne aufzuteilen. Um den Titel Ihrer Frage zu beantworten: Wenn Sie einen Mikrodienst in der richtigen Größe halten, kann die gesamte oder der größte Teil der Geschäftslogik für diese Problemdomäne in diesem Mikrodienst enthalten sein.

Es hängt alles von Ihrer genauen Anforderung ab.

Angenommen, Sie haben zwei Anwendungen, die die Buchung durchführen:

1. Erster Fall: In einer Anwendung kann ein Benutzer möglicherweise mehrmals buchen, in der anderen nur. Dies bedeutet, dass die Einschränkung der Buchung auf Anwendungsebene liegt. Daher haben Sie entweder zwei Einstiegspunkte in Ihrem Buchungssystem (einen, der Mehrfachbuchungen zulässt, einen, der dies nicht zulässt) oder Sie überprüfen dies einfach in den Microservices der jeweiligen Buchung Anwendung.
2. Zweiter Fall: Es ist Teil der Definition einer "Buchung", dass ein Benutzer nicht mehrere haben kann, unabhängig von der Anwendung. Diese Regel gilt für das gesamte System: Dies bedeutet, dass Sie den Scheck in den Buchungsmikroservice einfügen können.

Für das Benachrichtigungssystem können Sie Microservices für Ihren Buchungsservice abonnieren lassen, um auf neue Buchungen zu warten. Daher benachrichtigt der Buchungsmikroservice alle Abonnenten und handelt entsprechend.

Das einzige Problem bei dieser Art von Architektur ist, was passiert, wenn nach der Veröffentlichung der Benachrichtigung ein Fehler auftritt, da die beiden Microservices nicht wie zwei Funktionen funktionieren, die in derselben Datenbanktransaktion ausgeführt werden. Sie müssen Fehler ordnungsgemäß behandeln und schließlich die Prozesse wiedergeben die fehlgeschlagen sind (automatisch oder manuell)

Die einfache Antwort lautet, dass Clients von Microservices die Geschäftslogik in einer "reinen" Microservices-Architektur verwalten. Betrachten Sie zum besseren Verständnis ein noch einfacheres Beispiel. Ein Dienst, der nur Byteströme basierend auf einem URI zurückgibt. An sich ist es nicht besonders nützlich. Ohne zu wissen, welche URIs was enthalten, können Sie nur raten, wohin die Dinge gezogen werden sollen. Angenommen, Sie haben einen anderen Microservice, der eine Suchfunktion bietet. Sie senden eine Anfrage mit einer Abfragezeichenfolge und sie gibt URIs zurück. Jetzt wird es interessanter. Ich kann Verweise auf URIs für den ersten Dienst in einen Index einfügen.

Trotzdem müssen wir uns irgendwie zwischen diesen beiden abstimmen. Es gibt eine einfache Antwort: Sie verwenden einen Browser, um URIs vom Indexdienst abzurufen und dann die Daten vom Datendienst abzurufen. Keiner der Dienste "weiß" über den anderen Bescheid und es gibt absolut keine Kopplung zwischen ihnen. Ich kann den Indexdienst mit jedem anderen Datendienst verwenden und umgekehrt.

Es ist nicht unbedingt der Fall, dass dies in allen Szenarien der beste Ansatz ist, aber es gibt viele Vorteile, Dinge auf diese Weise zu erstellen, insbesondere die Wiederverwendbarkeit in Szenarien, die derzeit nicht bekannt sind.