Leçons tirées de la mise à l'échelle des WebSockets

WebSockets : essentiels pour les applications en temps réel, mais la mise à l'échelle nécessite une planification minutieuse

La demande croissante d'applications synchronisées en temps réel a fait des WebSockets un élément crucial du développement de logiciels modernes. Chez Compose, les WebSockets constituent la base de notre service, permettant à nos SDK backend de fournir des applications interactives à faible latence en utilisant uniquement du code backend. Cependant, la mise à l’échelle des WebSockets présente des défis importants. Voici les principales leçons apprises :

Déploiements gracieux : maintien de la persistance de la connexion

Les déploiements transparents sont cruciaux ; les utilisateurs ne devraient jamais subir d’interruptions. Pour garantir la persistance de la connexion WebSocket lors des déploiements, nous utilisons une stratégie de reconnexion robuste :

1. De nouveaux serveurs sont lancés.
2. Une fois sains, les anciens serveurs commencent à renvoyer des réponses 503 (Service non disponible) aux vérifications de l'état.
3. Après quatre 503 consécutifs, l'équilibreur de charge supprime les serveurs en mauvais état. (Les contrôles de santé ont lieu toutes les 5 secondes, pour un processus maximum de 25 secondes.)
4. Les anciens serveurs envoient un message de fermeture WebSocket personnalisé, demandant aux clients de retarder la reconnexion d'un intervalle aléatoire, empêchant ainsi une poussée de reconnexion. Ce message comprend :
   • Un message convivial lors de la brève déconnexion (~10 secondes).
   • Un délai aléatoire pour éviter des problèmes de troupeau tonitruants. Les clients augmentent également de manière exponentielle l’intervalle de temps pour les reconnexions liées au déploiement.
   • Un délai de 20 secondes pour permettre à l'équilibreur de charge de rediriger le trafic.

Les anciens serveurs s'éteignent complètement après la déconnexion des clients. Les services gérés tels que Render ou Railway nécessitent une attention particulière pour garantir un transfert fluide des connexions client lors des déploiements. Ces services attendent souvent que toutes les requêtes soient terminées avant de s'arrêter, ce qui peut prolonger considérablement le temps d'arrêt des connexions WebSocket persistantes.

Schéma de message cohérent : définir une communication claire

Contrairement aux conventions de routage intégrées de HTTP, les WebSockets nécessitent un schéma de message personnalisé. Chez Compose, nous utilisons un préfixe de type de 2 octets pour la catégorisation des messages :

• Espace efficace (seulement 2 octets), mise à l'échelle jusqu'à 65 536 types.
• Permet aux clients d'analyser facilement le préfixe de type sans affecter les données.
• Simplifie les mises à niveau de l'API grâce à des types de messages versionnés.

<code class="language-typescript">const MESSAGE_TYPE_TO_HEADER = {
  RENDER_UI: "aa",
  UPDATE_UI: "ab",
  SHOW_LOADING: "ac",
  RENDER_UI_V2: "ad",
  /* ... */
};</code>

Nous utilisons également des délimiteurs pour séparer les champs de message, améliorant ainsi la vitesse d'encodage/décodage et l'efficacité de la mémoire par rapport à JSON.

<code class="language-typescript">const DELIMITER = "|";

function createDelimitedMessage(type: string, args: any[]) {
  return [MESSAGE_TYPE_TO_HEADER[type], ...args].join(DELIMITER);
}

function parseDelimitedMessage(message: string) {
  const [type, ...args] = message.split(DELIMITER);
  return { type, args };
}</code>

L'utilisation de TypeScript nous permet de partager des schémas de messages entre le frontend et le backend, évitant ainsi les incohérences.

Mécanisme de battement de cœur : détection des déconnexions silencieuses

Des interruptions de connexion inattendues sans événements de fermeture peuvent conduire à des connexions obsolètes. Un mécanisme de battement de cœur robuste est essentiel :

• Le serveur envoie des messages de ping toutes les 30 secondes, en attendant des réponses pong.
• Les clients se déconnectent et se reconnectent si un ping n'est pas reçu dans les 45 secondes.
• Le serveur ferme les connexions qui manquent les réponses Pong dans les 45 secondes.

Cette surveillance bidirectionnelle du rythme cardiaque détecte et gère les situations où le réseau du client semble fonctionnel, mais le serveur ne reçoit pas de réponses.

HTTP Fallback: Gestion des restrictions du réseau

Websockets peut être bloqué sur des réseaux restrictifs. Compose utilise des événements de serveur (SSE) comme repli pour recevoir des mises à jour et des demandes HTTP pour la communication client-serveur.

La nature basée sur HTTP

SSE le rend moins susceptible de bloquer, offrant une alternative fiable avec une latence relativement faible.

Considérations supplémentaires

La mise à l'échelle des web avec des complexités supplémentaires:

• Manque d'outillage standard: Les fonctionnalités comme la limitation du taux et la validation des données nécessitent souvent une implémentation personnalisée.
• Incapacité à mettre en cache les réponses: Contrairement à HTTP, les lignes Web manquent de mécanismes de mise en cache standard.
• Authentification par message: Assurer la validité de chaque message avant le traitement est cruciale pour la sécurité.

Malgré ces défis, les lignes Web restent la solution optimale pour créer des applications rapides, en temps réel et collaboratives. Chez Compose, WebSockets alimente toute notre plate-forme, permettant aux développeurs de créer des applications Web complètes à partir de la logique backend à l'aide de nos SDK. En savoir plus dans notre documentation.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!