it-swarm.com.de

Tabelle zwischen verschiedenen Microservices verbinden

Ich versuche immer noch, die Micro-Service-Architektur zu verstehen.

Die Idee, verschiedene Anwendungen (einschließlich der Datenbank) zu trennen, reizt mich. Ich bin jedoch immer noch verwirrt, wenn es zwei Mikrodienste gibt, z. Produkt und Benutzer. sowohl produkt- als auch benutzereigene Tabellenprodukte und -benutzer in ihrer Datenbank. Gemäß den Best Practices in Micro Service können wir nur über den Service auf die Datenbank zugreifen. 

Das Problem ist, nehmen wir an, wir haben eine Produkttabelle mit einer user_id-Spalte. Wir möchten ein Produkt suchen, das auch den Namen des Benutzers enthält, der das Produkt erstellt. Dies erfordert einen Join zwischen der Produkttabelle im Produkt-Mikrodienst und der Benutzertabelle im Benutzermikrodienst. Wie gehst du damit um? 

10
Robert Limanto

Sie müssen jeden Microservice anrufen und die Verknüpfung manuell durchführen oder die entsprechenden Benutzer-IDs an jeden Dienst übergeben.

UserMicroservice: 

SELECT * FROM Users WHERE some condition is true

Rufen Sie die Liste der Benutzer mit ihren ids zurück.

ProduktMicroserivce: 

SELECT * FROM Products WHERE some condition is true AND userId IN (.........)

Benutzer und Produkte können sich also immer noch in zwei verschiedenen Datenbanken befinden. Die Produkte benötigen lediglich das Konzept einer Benutzer-ID.

Umgekehrt kann auch ProductMicroserivce durchgeführt werden: 

SELECT * FROM Products WHERE some condition is true

Extrahieren Sie alle UserIds und rufen Sie den UserMicroservice auf: 

SELECT * FROM Users WHERE some condition is true AND id IN (.........)

Ich denke, es ist nichts Falsches daran zu tun, wie Jan es vorgeschlagen hat. Ich möchte jedoch hinzufügen, dass der Unterschied, den Microservices Ihrem System hinzufügen sollten, eine andere Natur ist. 

Die oben erwähnte Trennung der Dienste ist das, was wir in der SOA-Welt viel gesehen haben, und es stellte sich heraus, dass es sehr schnell zu komplex wurde, ohne dass es einen großen Wert darstellte.

Wenn Sie, und ich verstehe, es ist nur ein Beispiel, haben Sie die Notwendigkeit, Benutzer, die mit Produkten verbunden sind, abzufragen - warum den Dienst aufteilen? Am Ende entwerfen Sie einen Dienst pro Datenbankeinheit, anstatt zu prüfen, welche Anforderungen an einen bestimmten, mir scheinbar begrenzten Kontext gestellt werden.

-Lars

8
Lars

Die beste Antwort auf solche Szenarien ist CQRS. Pflegen Sie die materialisierten Ansichten der Benutzer- und Produktbeziehung. Meterialisierte Ansichten können alles sein, was eine geringe Latenz beim Lesen bewirkt, wie bei NoSql-DBs. Immer, wenn Command Benutzer oder Produkte durch ihre Mikrodienste aktualisiert, sollten die entsprechenden Ereignisse generiert und von anderen Diensten erfasst werden, die diese materializedView verwalten. Dieser Dienst wird verwendet, um die Abfrage abzurufen, an der Sie interessiert sind. Denken Sie immer daran, dass die Microservices-Architektur an die eventuelle Konsistenz glaubt, die definitiv keine schlechte Sache ist :).

2
Praful