Les ingénieurs cadrent parfois la mise à l'échelle des WebSockets comme "est-ce que l'exécution X peut gérer N connexions ?"
C'est trop étroit.
La question plus difficile est généralement :
"Ce système peut-il gérer un état de connexion à long terme, un fanout sélectif et des clients lents sans s'effondrer ?"
Les Vrais Coûts
Un système WebSocket doit gérer :
- l'état de connexion persistant
- l'authentification et la gestion des reconnexions
- le fanout vers de nombreux abonnés
- la pression de retour des consommateurs lents
- la coordination entre nœuds si vous scalez horizontalement
Le nombre de connexions est important. La forme du fanout l’est encore plus.
Dix mille connexions principalement inactives constituent un problème différent de dix mille abonnés recevant des diffusions fréquentes.
Pourquoi Node a Souvent Du Difficulté
Node peut absolument alimenter des systèmes WebSocket.
La pression commence lorsque l'application effectue trop de travail par message sur la même boucle d'événements responsable du maintien de la santé des sockets. Une fois que les boucles de diffusion, la sérialisation et la comptabilité par client s'accumulent, la latence devient rapidement visible.
Ce n'est pas une indictment de Node. C'est un rappel que le modèle d'exécution et la forme de la charge de travail doivent correspondre.
Pourquoi Elixir/Phoenix est Souvent Mentionné
Elixir et l'écosystème BEAM sont populaires dans cet espace car ils sont conçus autour d'un grand nombre de processus légers et du passage de messages. Cela peut rendre les systèmes orientés connexion plus simples à appréhender opérationnellement.
Le véritable avantage n'est pas que "Elixir peut gérer un million de sockets" comme slogan. C'est que la supervision, l'isolation et la concurrence font partie du modèle plutôt que d'être quelque chose de rajouté autour.
La Règle de Design Qui Compte
Si vous avez besoin d'une livraison en temps réel à grande échelle, concentrez-vous sur :
- maintenir l'état par connexion petit
- partitionner proprement les salles ou les sujets
- appliquer la pression de retour
- mesurer le coût du fanout
- choisir un modèle d'exécution adapté à la charge de travail
Parfois, Node est suffisant. Parfois, Go ou Elixir est un meilleur choix.
La véritable question d'ingénierie n'est pas quelle langue remporte les arguments sur Internet. C'est quel modèle d'exécution rend les modes de défaillance gérables pour votre schéma de trafic.
Lecture Supplémentaire