Ingenieure rahmen die Skalierung von WebSockets manchmal als "Kann Laufzeit X N Verbindungen halten?"
Das ist zu eng gefasst.
Die schwierigere Frage lautet normalerweise:
"Kann dieses System langanhaltenden Verbindungszustand, selektiven Fanout und langsame Clients verwalten, ohne zusammenzubrechen?"
Die wahren Kosten
Ein WebSocket-System muss sich mit folgenden Aspekten auseinandersetzen:
- persistentem Verbindungszustand
- Authentifizierung und Wiederverbindungsmanagement
- Fanout zu vielen Abonnenten
- Backpressure von langsamen Verbrauchern
- Koordination über Knoten hinweg, wenn Sie horizontal skalieren
Die Anzahl der Verbindungen ist wichtig. Die Form des Fanouts ist noch wichtiger.
Zehntausend größtenteils inaktive Verbindungen sind ein anderes Problem als zehntausend Abonnenten, die häufige Übertragungen empfangen.
Warum Node Oft Probleme Hat
Node kann WebSocket-Systeme absolut betreiben.
Der Druck beginnt, wenn die Anwendung zu viel Arbeit pro Nachricht in derselben Ereignisschleife verrichtet, die dafür verantwortlich ist, die Sockets gesund zu halten. Sobald Broadcast-Schleifen, Serialisierung und klientenspezifische Buchhaltung sich anhäufen, wird die Latenz schnell sichtbar.
Das ist kein Vorwurf an Node. Es ist eine Erinnerung daran, dass das Laufzeitmodell und die Arbeitslast zusammenpassen müssen.
Warum Elixir/Phoenix So Oft Erwähnung Findet
Elixir und das BEAM-Ökosystem sind in diesem Bereich beliebt, weil sie für große Mengen leichter Prozesse und Nachrichtenweiterleitung konzipiert sind. Das kann es einfacher machen, zustandsorientierte Systeme operationell zu durchdenken.
Der wirkliche Vorteil ist nicht "Elixir kann eine Million Sockets" als Slogan. Es ist, dass Überwachung, Isolation und Nebenläufigkeit Teil des Modells sind, anstatt etwas, was danach angebaut wurde.
Die Entscheidende Entwurfsregel
Wenn Sie eine großangelegte Echtzeitbereitstellung benötigen, konzentrieren Sie sich auf:
- den Zustand pro Verbindung klein zu halten
- Räume oder Themen sauber zu partitionieren
- Backpressure anzuwenden
- die Kosten des Fanouts zu messen
- eine Laufzeit zu wählen, die zur Arbeitslast passt
Manchmal ist Node gut genug.
Manchmal ist Go oder Elixir besser geeignet.
Die ernsthafte ingenieurtechnische Frage ist nicht, welche Sprache in Internet-Diskussionen gewinnt. Es ist welche Laufzeit die Fehlermodi für Ihr Verkehrsaufkommen handhabbar macht.
Weiterführende Literatur