Microservices: Wie man effektiv mit Datenabhängigkeiten zwischen Microservices umgeht

Question

Ich entwickle eine Anwendung, die den Microservices-Entwicklungsansatz mit dem Mean-Stack nutzt. Ich stoße auf eine Situation, in der Daten zwischen mehreren Microservices ausgetauscht werden müssen. Nehmen wir zum Beispiel an, dass ich Benutzer-, Video-, Nachrichten- (Senden/Empfangen, Posteingang usw.) Dienste habe. Jetzt gehören die Video- und Nachrichtensätze zu einem Account-Datensatz. Wenn Benutzer Video erstellen und Nachrichten senden/empfangen, gibt es einen Fremdschlüssel (userId), der den von ihnen erstellten Video- und Nachrichtensätzen zugeordnet werden muss. Ich habe Szenarien, wo ich zum Beispiel den ersten, mittleren und letzten Namen jedes Videos anzeigen muss. Lassen Sie uns nun sagen, dass ein Benutzer am Frontend durch eine Liste von Videos blättert, die jeweils 50 auf das System hochgeladen wurden. Im schlimmsten Fall könnte ich eine Situation sehen, in der ein Zug von 50 auftritt, bei dem jedes Video an einen eindeutigen Benutzer gebunden ist.

Es scheint zwei Ansätze zu diesem Thema zu sein:

One, ich einen API-Aufruf an den Benutzer Dienst machen und jeden Benutzer zu jedem Video in der Liste gebunden bekommen. Dies scheint ineffizient, da es sehr unterhaltsam werden könnte, wenn ich einen Anruf pro Video mache. Im zweiten Szenario des api-Aufrufs würde ich die Liste der Videos abrufen und eine eindeutige Liste mit Fremdschlüsseln für Benutzer senden, die abgefragt werden, um jeden Benutzer mit jedem Video zu verknüpfen. Dies scheint effizienter zu sein, aber es scheint immer noch, als ob ich die Leistung verliere, indem ich alles wieder zusammensetze, um es zur Anzeige zu schicken, oder wie auch immer es manipuliert werden muss.

Zwei, wenn ein neuer Benutzer erstellt wird, sendet der Kontodienst eine Nachricht mit den Benutzerinformationen, die jeder andere Dienst an eine Fanout-Warteschlange benötigt, und dann liegt es in der Verantwortung der einzelnen Dienste, den neuen Benutzer zu einer Tabelle hinzuzufügen es ist eine eigene Datenbank, die lose Kopplung aufrechterhält. Der extreme Nachteil hier wäre die Datenduplizierung und die Notwendigkeit, die Fanout-Warteschlange zu handhaben, wenn Aktualisierungen vorgenommen werden müssen, um eine mögliche Konsistenz sicherzustellen. Auf lange Sicht scheint dieser Ansatz jedoch aus Performance-Sicht am effizientesten zu sein.

Ich bin zwischen diesen beiden Ansätzen hin- und hergerissen, da sie beide ihren Anteil an Kompromissen haben. Welcher Ansatz ist am sinnvollsten zu implementieren und warum?

Answer 1

Ich bin auch in dieser Frage interessiert.

Zunächst ist das von Ihnen beschriebene Szenario sehr häufig. Benutzer, Videos und Nachrichten haben definitiv drei verschiedene Microservices. Es gibt kein Problem, wie Sie das System in Stücke zerlegt haben.

Zweitens gibt es mehrere Optionen, wie das Problem der gemeinsamen Datennutzung lösen. Schauen Sie sich einen großartigen Artikel von auth0 an: https://auth0.com/blog/introduction-to-microservices-part-4-dependencies/

Answer 2

Beschränken Sie Ihre Designentscheidung nicht auf die beiden von Ihnen beschriebenen Optionen. Das Schwierigste an Microservices ist es, herauszufinden, was ein Service ist und wie man seine Anwendung in Brocken/Dienste zerlegt, die sinnvoll als "Microservice" implementiert werden können.

Nur weil Sie diese 3 Entitäten haben (Benutzer, Video & Nachricht) bedeutet nicht, dass Sie 3 Dienste implementieren müssen. Wenn Ihr tatsächlicher Anwendungsfall zeigt, dass diese Dienste (oder Entitäten) stark voneinander abhängig sind, um eine einfache Anfrage vom Front-End zu erfüllen, ist dies ein klares Signal, dass Ihr Schnitt nicht richtig war.

Von was ich aus Ihrem Beispiel sehe, würde ich 1 Microservice entwerfen, der die Anfrage erfüllt. Denken Sie daran, dass eine der Design-Grundlagen eines Microservice so unabhängig wie möglich sein soll. Es gibt keine Notwendigkeit, Dienste zu komplizieren, es ist nicht SOA.

https://martinfowler.com/articles/microservices.html -> gut zu lesen!

Grüße, Lars