it-swarm.com.de

Große Datei- / Datenübertragung in einer Microservice-Architektur

Mein Unternehmen arbeitet derzeit an der Einführung einer Microservice-Architektur, aber wir stoßen auf dem Weg zu wachsenden Schmerzen (Schock!). Einer der Hauptstreitpunkte, mit denen wir konfrontiert sind, ist die Kommunikation großer Datenmengen zwischen unseren verschiedenen Diensten.

Als Hintergrund haben wir einen Dokumentenspeicher, der als Repository für alle Dokumente dient, die wir möglicherweise im gesamten Unternehmen verarbeiten müssen. Die Interaktion mit diesem Geschäft erfolgt über einen Dienst, der einem Kunden eine eindeutige ID und einen Ort zum Streamen des Dokuments zur Verfügung stellt. Auf den Speicherort des Dokuments kann später über eine Suche mit der angegebenen ID zugegriffen werden.

Das Problem ist folgendes: Ist es sinnvoll, dass alle unsere Microservices diese eindeutige ID als Teil ihrer API akzeptieren, um mit Dokumenten zu interagieren, oder nicht? Für mich fühlt sich das von Natur aus falsch an - die Dienste sind nicht mehr unabhängig und verlassen sich auf den Dienst des Dokumentenspeichers. Obwohl ich anerkenne, dass dies das API-Design vereinfachen und möglicherweise sogar zu Leistungssteigerungen führen kann, gleicht die resultierende Kopplung die Vorteile mehr als aus.

Weiß jemand, wie die Rainbow-Einhörner (Netflix, Amazon, Google usw.) mit dem Austausch großer Dateien/Daten zwischen ihren Diensten umgehen?

22
PremiumTier

Weiß jemand, wie die Rainbow-Einhörner (Netflix, Amazon, Google usw.) mit dem Austausch großer Dateien/Daten zwischen ihren Diensten umgehen?

Leider weiß ich nicht, wie sie mit solchen Problemen umgehen.

Das Problem ist folgendes: Ist es sinnvoll, dass alle unsere Microservices diese eindeutige ID als Teil ihrer API akzeptieren, um mit Dokumenten zu interagieren, oder nicht?

Es verstößt gegen das Prinzip der Einzelverantwortung, das in der Architektur Ihres Microservices enthalten sein sollte. Ein Microservice - logisch eins, physisch viele Instanzen, die einen darstellen - sollte sich mit einem Thema befassen.

Im Fall Ihres Dokumentenspeichers haben Sie einen Punkt, an dem alle Abfragen für Dokumente ablaufen (natürlich können Sie diese logische Einheit für mehrere Arten von Dokumenten in mehrere Dokumentenspeicher aufteilen).

  • Wenn Ihre "Anwendung" an einem Dokument arbeiten muss, fragt sie den jeweiligen Microservice und verarbeitet dessen Ergebnisse.

  • Wenn ein anderer Dienst ein tatsächliches Dokument oder Teile davon benötigt, muss er den Dokumentendienst fragen.

Einer der Hauptstreitpunkte, mit denen wir konfrontiert sind, ist die Kommunikation großer Datenmengen zwischen unseren verschiedenen Diensten.

Dies ist ein architektonisches Problem:

  1. Verringern Sie die Notwendigkeit, große Datenmengen zu übertragen

    Im Idealfall verfügt jeder Dienst über alle Daten und muss nicht übertragen werden, um lediglich Anforderungen zu erfüllen. Als Erweiterung dieser Idee - wenn Sie Daten übertragen müssen, denken Sie an Redundanz (* positiv_): Ist es sinnvoll, die Daten an vielen Stellen redundant zu haben (wo sie benötigt werden)? Überlegen Sie, wie mögliche Inkonsistenzen Ihre Prozesse beeinträchtigen können. Es gibt keine schnellere Übertragung als tatsächlich keine.

  2. Verringern Sie die Größe der Daten selbst

    Überlegen Sie, wie Sie komprimieren Ihre Daten: Beginnen Sie mit den tatsächlichen Komprimierungsalgorithmen bis zu intelligente Datenstrukturen . Je weniger über den Draht geht, desto schneller sind Sie.

7
Thomas Junk

Persönlich würde ich lieber keinen separaten Dokumentenspeicherdienst und keine separate Dokument-ID verwenden, sondern eine URL, um auf die Dokumente zuzugreifen (mit ordnungsgemäßer Header-Authentifizierung). Bei diesem Ansatz benötigen Sie keine anderen Dienste, um sich auf den Dokumentendienst zu verlassen. Stattdessen kann nur die vollständige URL für den Zugriff auf das Dokument verwendet werden. Auch bei der Skalierung ist es sinnvoll, mehrere Dokumentenspeicher als und zu verwenden wenn der Speicher wächst und geben Sie die URL an.

Möglicherweise benötigen Sie jedoch einen oder mehrere Dienste, um ein Dokument hochzuladen und dessen URL abzurufen.

2

Wenn die von Ihrem Dokumentenspeicher zurückgegebene ID the ist, um Dokumente im gesamten System zu referenzieren, ist es für alle Dienste sinnvoll, diese 'Dokument-ID' in ihrer API zu akzeptieren, wenn der Dienst wissen muss, welches Dokument vorhanden ist es muss damit arbeiten.

Dies führt nicht unbedingt zu einer engeren Kopplung zwischen den Diensten als erforderlich. Dienste, die auf Dokumente zugreifen müssen, müssen ohnehin auf den Dokumentenspeicherdienst zugreifen, und sie benötigen diese ID, um dem Speicher mitzuteilen, auf welches Dokument zugegriffen werden soll.
Dienste, die nicht direkt auf Dokumente zugreifen, müssen möglicherweise die Dokument-ID weitergeben, aber an diese Dienste ist es nur eine beliebige Zeichenfolge, die keine Abhängigkeit erzeugt.

Weiß jemand, wie die Rainbow-Einhörner (Netflix, Amazon, Google usw.) mit dem Austausch großer Dateien/Daten zwischen ihren Diensten umgehen?

Kasse Amazon S3 REST API-Spezifikationen, anscheinend geben sie das vollständige Objekt in Bytes zurück. Scheint nicht viele Optionen zu haben, wenn Sie einen Microservice entwerfen. Link zum Antwortformat von Amazon S

1
suresh