Miroservices interservice Kommunikation mit Sockets

Question

Ich entwerfe gerade ein System für das folgende Szenario: Daten werden von einem Client gestreamt, wobei Prozesse von mehreren Diensten nacheinander ausgeführt werden (keine Parallele). Anschließend werden die Daten während der Analyse zurück zum Client gestreamt. Es ist wichtig, dass der Server während des Prozesses zu den teilweise analysierten Daten des Clients zurückkehrt (deshalb brauche ich Sockets).

Der Client kann während der Analyse auf dem Server sogar mehr Informationen senden, was sich auf die Analyseergebnisse auswirken kann.

A high level sketch I made

Ich habe eine Menge Forschung in dieser gemacht, und ich habe nur REST Microservice OR Asynchron-Verarbeitung mit Steckdosen mit allen Arten von Messaging-Warteschlangen gesehen. Ich habe niemanden gesehen, der Microservices mit so vielen geöffneten Sockets direkt zwischen den Diensten implementiert.

Jetzt für meine Frage: Mache ich das Richtige hier? Ist das Öffnen von Sockets zwischen all meinen Servern falsch oder unzuverlässig?

Answer 1

Dies ist eine sehr weit gefasste Frage, ich werde so versuchen Ihnen ein paar großen Gedanken dazu geben:

Zunächst einmal denke ich, dass die allgemeine Idee ist völlig in Ordnung. Alle Microservices benutzen Sockets auf die eine oder andere Weise, du nimmst es nur auf eine niedrigere Ebene, ohne die verschiedenen Abstraktionen oben. Das macht Sinn, besonders wenn Sie sehr spezifische Anforderungen haben.

Die Anzahl der Sockel scheint mir nicht so groß. Ich habe gesehen, dass Systeme tausende gleichzeitig geöffneter Sockets halten vor zehn Jahren. Was Sie vorschlagen, scheint auf modernen Hardware- und Betriebssystemen trivial zu sein.

Also insgesamt ist das Design total machbar. Aber das Problem ist, dass Sie gezwungen sein werden, einige Räder auf dem Weg neu zu erfinden. Ich werde einige von ihnen erwähnen.

Zuerst benötigen Sie Service Discovery für die Microservices, um einander zu finden.

Dann müssten Sie ein Protokoll zwischen jedem Paar von Diensten entwerfen - Sie müssten Nachrichten und Regeln angeben, wann und wie sie gesendet werden. Sie würden Message Builder und Parser benötigen; sowie Logik zum Behandeln verschiedener Nachrichtenfehler und Vorwärts-/Rückwärtskompatibilität. Das ist kniffliger als es klingt, besonders wenn die Kommunikation robust sein muss, was mich zum nächsten Punkt bringt - der Umgang mit Netzwerkausfällen.

Welche Netzwerkausfälle? TCP ist zuverlässig, oder? Nun, nicht ganz. Erstens gibt es die Trennungen und verschiedene Netzwerkfehler. Dann gibt es einige stille Fehler - Versuchen Sie, einen Socket zu einem Remote-Computer zu öffnen, dann plötzlich zieht das Netzwerkkabel. Wie lange dauert es, bis der lokale Socket eine Ausnahme auslöst? Nun, es stellt sich heraus, dass es dauert Minuten, Minuten, in denen Sie lokalen Socket denkt, dass die Maschine entfernen ist lebendig und gut. Sicher, wenn es ankommt, dann kommt es ohne Fehler und in der richtigen Reihenfolge an. Aber das ist nur wenn es ankommt.

Dann gibt es das Threading. Obwohl das Threading nicht für reine Sockets typisch ist, ist es bei niedrigeren Abstraktionsebenen eher schmerzhaft.

So, während es getan werden kann, möchten Sie möglicherweise versuchen zu vermeiden, hier einige der Räder neu zu erfinden. Zum Beispiel, wie wäre es mit einer RPC Bibliothek? Sie existieren für alle modernen Sprachen und lösen bereits einige der Probleme, mit denen Sie umgehen müssen.