it-swarm.com.de

Microservice JOIN-Abfrage

Ich weiß, dass diese Frage von vielen Leuten hier und im Internet gestellt wurde, aber ich konnte keine wirklich klare Erklärung finden, wie Abfragen über mehrere Microservices hinweg durchgeführt werden können.

Stellen Sie sich vor, ich habe 2 Dienste, einer ist Verwalten von Benutzerbeziehungen und einer ist verantwortlich für Blog-Beiträge. Wenn ich nur die 20 neuestenBeiträge erhalten möchte, muss ich die Beziehungsdatenbank abfragen für ALLE meine Freunde/folgt. Das könnte ein tausend Einträge sein. Dann übergebe diese an den Blog-Service und es gibt 20 Blog-Beiträge zurück. Dann scrolle ich ein wenig nach unten und (stellen Sie sich vor, ich speichere nicht) dieser Vorgang wird wiederholt. Dies ist ein Overkill meiner Meinung nach.

Die meisten Antworten auf diese Fragen besagten, dass die Trennung von Domänen nicht gut ist. Wenn diese beiden Dienste immer zusammen verwendet werden, gehören sie zu einem Dienst. Das ist auch für mich inakzeptabel, weil die meisten von uns ihre Programme nur auf Microservice-Art schreiben, aber alle Funktionen sind irgendwie kohärent . Wenn ich also am Ende viele Verbindungen hätte, würde ich immer Monolithen bauen? Oder sollte ich die Ineffizienz akzeptieren, wenn ich den Microservice-Pfad beschreite?

8
Peter

"Die meisten von uns schreiben ihre Programme nur im Microservice-Stil". Seien Sie vorsichtig mit dieser Aussage, denn was "Microservice Way" ist, ist definitiv kein einziger Weg und ich würde sagen, dass es oft falsch gemacht wird. Der Grund dafür ist, dass viele Entwickler Microservices basierend auf Entitäten erstellen: Benutzer, Blog, Kommentar, Kategorie, Zahlung usw. Diese Art von Design erstellt ein Beziehungsnetz, in dem alle Services von allen anderen Services und den Anforderungen zum Erstellen von Abfragen abhängig sind mit Verknüpfungen werden Daten von mehreren Diensten angezeigt.

Ich würde also sagen, das erste, was Sie tun sollten, ist: Akzeptieren Sie, dass Ihre Servicegrenzen wahrscheinlich falsch sind. Ein Dienst sollte in der Lage sein, seine Geschäftsziele zu erreichen, ohne Daten von anderen Diensten zu benötigen. Ich habe das starke Gefühl, dass dies Ihre Situation ist. Dies bedeutet, dass Sie in der Lage sein sollten, eine Abfrage in einem einzelnen Dienst durchzuführen und eine Liste der Ergebnis-IDs zurückzugeben. Verwenden Sie diese IDs dann, um einen anderen oder mehrere Dienste abzufragen und die vollständigen Informationen zu erstellen, die an den Benutzer zurückgegeben werden müssen (z. B. werden der Benutzername, die Benutzerreputation und der Text des Blogposts wahrscheinlich in drei verschiedenen Diensten gespeichert). .

Wenn Sie jetzt zu 100% sicher sind, dass Ihre Servicegrenzen korrekt sind und Sie dennoch Situationen finden, in denen Sie Abfragen über mehrere Services hinweg durchführen müssen, haben Sie mehrere Möglichkeiten:

  1. Erstellen einer Suchmaschine: Dies kann mehrere Suchvorgänge parallel zu mehreren Diensten auslösen und die Ergebnisse kombinieren oder eine Suche in einem Dienst durchführen und dann andere Dienste aufrufen, um die Ergebnisse aus dem vorherigen herauszufiltern.
  2. Verwenden eines Suchdienstes: Dieser Dienst aggregiert Daten aus mehreren Diensten und indiziert sie so, dass eine effiziente Suche möglich ist. Dies ist nützlich, wenn Sie komplexe Abfragen wie die Volltextsuche in allen Blogs und Kommentaren, Suchen basierend auf mehreren Kategorien oder Tags, Benutzern usw. durchführen möchten. Diese Dienste sortieren die Ergebnisse normalerweise nach% der Übereinstimmung. Wenn die Suche komplex ist, ist es am besten, einen Dienst eines Drittanbieters zu verwenden und nicht zu versuchen, einen eigenen zu erstellen.

Zu Ihrer letzten Frage "Oder sollte ich die Ineffizienz akzeptieren, wenn ich den Microservice-Pfad beschreite?" Ich würde sagen, dass eine ordnungsgemäß gestaltete Microservices-Anwendung nicht ineffizienter sein sollte als ein Monolith, da "Effizienz" nicht nur die Geschwindigkeit einer einzelnen Abfrage, sondern auch eine Eigenschaft der gesamten Anwendung (Leistung, Stabilität, Wartbarkeit usw.) berücksichtigt. Wenn Ihr Microservice-Design nicht besser ist als Ihr Monolith-Design, entscheiden Sie sich auf jeden Fall für den Monolithen.

9

Wenn Sie einen Join für die Daten von zwei Microservices benötigen, ist Ihr Microservices-Design einfach nicht korrekt. Daten, die in Ihrem System logisch zusammenarbeiten, gehören zum selben Microservice.

Eine andere Alternative besteht darin, die Daten des Benutzer-Mikrodienstes nach Bedarf unter Verwendung von Ereignissen, z. Beziehungen zu Posts (aber nicht zu Adressen) und Adressen zu Abrechnungen (aber nicht zu Beziehungen). Beachten Sie, dass Sie auf diese Weise ziemlich schnell einen verteilten (tm) großen Schlammball (tm) erhalten können.

3
marstato

Definieren Sie eine Ansichtsdatenbank, bei der es sich um ein schreibgeschütztes Replikat handelt, das diese Abfrage unterstützt. Die Anwendung hält das Replikat auf dem neuesten Stand, indem sie Domänenereignisse abonniert, die von dem Dienst veröffentlicht wurden, dem die Daten gehören.

https://microservices.io/patterns/data/cqrs.html

2
Ali Bayat