it-swarm.com.de

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. Zur Vereinfachung nehmen wir an, wir haben 3 Dienste und eine Gateway-API für den Client: Booking, Drivers, Notification und wir haben den 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

Angenommen, alle Nachrichten werden über einen http-Aufruf und nicht über einen Nachrichtenbus wie kafka) gesendet, um die Dinge einfach zu halten.

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

  • Gateway - Liste der verfügbaren Treiber abrufen + Benachrichtigungen senden
  • Booking - auf vorhandene Buchung prüfen

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 Booking -Dienst 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 :-)

11
GantengX

Die Leute hören oft "Mikro-Service" und denken "Nano-Service", was zu Verwirrung führen kann. Dies sind Mikro - Dienste, sodass Sie nicht für jede einzelne Entität einen separaten Dienst benötigen. Alles, was Sie versuchen, sollte sich in den Diensten booking und notification befinden. Sie benötigen den Dienst driver nicht (für eine der von Ihnen beschriebenen Aktivitäten).

Das Abrufen einer Liste der Treiber, die für das Buch verfügbar sind, fällt unter den Dienst booking. 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äne und nicht nach Entität in einem Dienst gruppieren.

Was die Wiederverwendung betrifft, so 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 für ihre jeweilige Plattform geeignet aussehen (ohne Code zu wiederholen). Der Servicecode booking 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 App Android App ruft den Dienst booking auf, um eine Liste der verfügbaren Treiber abzurufen
  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 Dienstes booking auf
  4. Der Service booking ruft den Service notification mit den Buchungsdetails auf
  5. Der notification -Dienst sendet eine Benachrichtigung an den Fahrer und benachrichtigt ihn über die Buchung
  6. Die Treiber-App sendet eine Nachricht an den Dienst notification, wenn sie sich innerhalb einer Meile vom Kunden befinden
  7. Der Dienst notification 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.

12
TheCatWhisperer

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 mehrere Male 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 Mikrodienste 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)

1
Walfrat

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.

0
JimmyJames