Server zu Server Kommunikation in NodeJS

shoa66

Lt. Junior Grade
Registriert
Mai 2005
Beiträge
314
Hey Leute,

ich taste mich aktuell langsam an NodeJS heran und möchte, nach den ersten erfolgreichen kleineren Projekten/Scripts, nun folgendes implementieren:

1. Viele kleine Server sollen, unabhängig voneinander, bestimmte Operationen durchführen (schon alles implementiert)
2. Bei Erfolg (einer Suche) sollen die Ergebnisse an einen "Master Server" gemeldet werden (und dazu ein paar Variablen, am besten im JSON Format, an diesen übermittelt werden).
3. Der Master Server soll auf Meldungen der anderen Server (ca. 5 Stück) warten, und bei eingehender Meldung weitere Operationen durchführen.

Ich habe schon etwas recherchiert und bin auf das hier gestoßen:
https://stackoverflow.com/questions/14113254/node-js-server-to-server-connection

Allerdings ist das doch etwas suboptimal, da ja Strings nur als buffer übertragen werden können.

Ideal wäre es ja eine eigene API zu haben, sprich die kleinen Server senden dann einen POST Request an den Master Server und alle benötigten Daten liegen im JSON Format vor. Der Master Server nimmt diesen POST entgegen und arbeitet damit dann weiter.

Habt ihr, falls ihr solche Dinge schon implementiert habt, für mein Vorhaben ein paar Tipps, wie sowas am elegantesten und auch performantesten zu lösen ist (gerne auch in Form von weiterführender Lektüre)? Aktuell bin ich etwas erschlagen und habe fast den Eindruck, dass ich mir aktuell noch zuviel zumute (anderseits kann man ja auch nur so wachsen) ^^

Danke schon mal vorab!
 
Zuletzt bearbeitet:
Also ne klassische Microservices Architektur? Oder soll sich da was synchronisieren? Du sprichst von Master/Slave?

Ansonsten klassische RestApi + DB ist keine Option?

Vllt nen Framework wie Loopback oder Koa? Hab das aber selber auch noch nicht ausprobiert?
 
  • Gefällt mir
Reaktionen: shoa66
Nie so richtig was mit Node.js gemacht, aber der Code ist uralt und ich denke(hoffe) nicht, das Sockets State-of-the-Art sind.

Würde wie mein Vorredner in Richtung Rest API/Microservices gucken
Ergänzung ()

Frag mich auch gerade ob das eher ein HelloWorld Example ist um neue Konzepte zu testen oder hier potenziell nur eine Idee aufgegriffen wurde wo Multithreading und nicht Node.js besser wäre.
Ergänzung ()

Und wenn ich mir den vorgeschlagenen Code so angucke, geht es nur darum, dass der Code wieder als JSON interpretiert wird.

Sorry, hört sich schon fast nach einer Hausaufgaben an
 
Zuletzt bearbeitet von einem Moderator:
e_Lap schrieb:
Oder soll sich da was synchronisieren?

Nein, das wäre für meinen Kenntnisstand eh zu komplex. Wollte Stand der Dinge den Masterserver checken lassen, ob die Daten doppelt (von mehreren Slaves gleichzeitig/zeitversetzt) ankommen und falls das der Fall ist, werden diese beim 2. bis x. mal ignoriert.

e_Lap schrieb:
Du sprichst von Master/Slave?

Jein, wobei der Master nichts kontrollieren muss/soll. Ihm werden lediglich Daten zugespielt, mit denen er weiterarbeitet.

E-tech schrieb:
Frag mich auch gerade ob das eher ein HelloWorld Example ist um neue Konzepte zu testen oder hier potenziell nur eine Idee aufgegriffen wurde wo Multithreading und nicht Node.js besser wäre.

Nein, hier geht es nicht nur um Konzepte sondern um einen realen Anwendungsfall (viele kleine Crawler die Daten parsen und dann bei Erfolg dem Master zusenden).

Multithreading ist keine Option da es ein Rate Limiting gibt.

E-tech schrieb:
Sorry, hört sich schon fast nach einer Hausaufgaben an

Mit der Schule bin ich schon über 10 Jahre durch :rolleyes:
 
Zuletzt bearbeitet:
Sorry für den Spruch mit der Hausaufgabe, aber das las sich teils so.

Solange du nicht mehrere IP Adressen hast (nicht lokale!) , weiß ich nicht ob dir das was bringt. Interessant ist ja wie das Rate Limiting umgesetzt ist.

Das folgende ist ein Dirty Hack, den ich produktiv nicht umsetzen würde und auch etwas davon abhängig ist wie zeitkritisch das ganze ist:

Lass die Server doch einfach in eine Datenbank schreiben und mache dann ein Cleanup auf die Datenbank in gewissen Intervallen. Man weiß ja quasi nie, wann ein Crawler fertig wird, ob eine Ressource blockt oder was auch immer.

Denke aber definitiv, dass du in Richtung Rest API anstatt auf Sockets gehen solltest
 
Jau, Rest API ist schon mal ein guter Hinweis, danke an euch beide!

E-tech schrieb:
Solange du nicht mehrere IP Adressen hast (nicht lokale!) , weiß ich nicht ob dir das was bringt. Interessant ist ja wie das Rate Limiting umgesetzt ist

Checkt, soweit ich das sehen konnte, nur die IP. Die Crawler laufen natürlich auf kleinen und billigen VPS Servern im Netz und haben alle ne andere IPv4.
 
Auch wenn hier ein paar gegen Sockets sind, würde ich das genau damit machen. Es gibt ein extrem verbreitetes und super dokumentiertes Framework dafür: https://socket.io/.

Eine weitere Option wäre es wohl auch, wenn du einen Message-Broker wie z. B. RabbitMQ nutzt. Das ist aber in der Implementierung etwas komplizierter und man braucht einen weiteren Server ... dafür kannst du aber extrem leicht Queues bauen und ebenso dafür sorgen, dass deine Nodes nicht den gleichen Task mehrmals ausführen bzw. Tasks auf andere Nodes verteilt werden, falls einer wegen was auch immer ausgefallen ist.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: shoa66
  • Gefällt mir
Reaktionen: shoa66
Wähle das Werkzeug welches du am besten verstehst oder glaubst dein Problem lösen zu können.

Es gibt x Wege um das Problem zu lösen. Jemand der eher Backend orientiert ist wird eine andere Lösung anstreben als jemand, der zumeist im Frontend Code schreibt.

RabbitMQ, Rest API, Sockets, fetch Api,... wähle einfach irgendetwas aus und arbeite dich ein. Wir kennen den Umfang der Daten ja nicht. Das wäre auch entscheidend für Lösungsansätze. Erstelle dir einfach ein Konzept und dann beginne mit der Implementierung bzw Anpassung deines aktuellen Codes.

Ich bin dann mal raus. Viel Spaß euch allen ;)
 
  • Gefällt mir
Reaktionen: shoa66
Die Daten sind tatsächlich recht simpel, ein paar Strings, ein paar ints, das wars. Idealerweise im JSON Format.
 
Zurück
Oben