Lehren aus der Skalierung von WebSockets

WebSockets: Unverzichtbar für Echtzeit-Apps, aber die Skalierung erfordert sorgfältige Planung

Die steigende Nachfrage nach synchronisierten Echtzeitanwendungen hat WebSockets zu einer entscheidenden Komponente in der modernen Softwareentwicklung gemacht. Bei Compose bilden WebSockets die Grundlage unseres Dienstes und ermöglichen es unseren Backend-SDKs, interaktive Anwendungen mit geringer Latenz bereitzustellen, die nur Backend-Code verwenden. Die Skalierung von WebSockets stellt jedoch erhebliche Herausforderungen dar. Hier sind die wichtigsten Erkenntnisse:

Graceful Deployments: Aufrechterhaltung der Verbindungspersistenz

Nahtlose Bereitstellungen sind entscheidend; Benutzer sollten niemals Unterbrechungen erleben. Um die Persistenz der WebSocket-Verbindung während der Bereitstellung sicherzustellen, verwenden wir eine robuste Strategie für die erneute Verbindung:

1. Neue Server werden gestartet.
2. Sobald alte Server fehlerfrei sind, geben sie bei Gesundheitsprüfungen 503-Antworten (Dienst nicht verfügbar) zurück.
3. Nach vier aufeinanderfolgenden 503-Fehlern entfernt der Load Balancer die fehlerhaften Server. (Zustandsprüfungen erfolgen alle 5 Sekunden, maximal 25 Sekunden lang.)
4. Alte Server senden eine benutzerdefinierte WebSocket-Schließungsnachricht und weisen Clients an, die Wiederverbindung um ein zufälliges Intervall zu verzögern, um einen Anstieg der Wiederverbindung zu verhindern. Diese Nachricht enthält:
   • Eine benutzerfreundliche Meldung während der kurzen Trennung (~10 Sekunden).
   • Eine zufällige Verzögerung, um donnernde Herdenprobleme zu vermeiden. Clients erhöhen auch den Backoff für bereitstellungsbezogene Wiederverbindungen exponentiell.
   • Eine Verzögerung von 20 Sekunden, damit der Load Balancer den Datenverkehr umleiten kann.

Alte Server werden vollständig heruntergefahren, nachdem Client-Verbindungen getrennt wurden. Verwaltete Dienste wie Render oder Railway erfordern besondere Aufmerksamkeit, um eine reibungslose Client-Verbindungsübertragung während der Bereitstellung sicherzustellen. Diese Dienste warten oft, bis alle Anfragen abgeschlossen sind, bevor sie heruntergefahren werden, was die Ausfallzeit für dauerhafte WebSocket-Verbindungen erheblich verlängern kann.

Konsistentes Nachrichtenschema: Klare Kommunikation definieren

Im Gegensatz zu den integrierten Routing-Konventionen von HTTP erfordern WebSockets ein benutzerdefiniertes Nachrichtenschema. Bei Compose verwenden wir ein 2-Byte-Typpräfix für die Nachrichtenkategorisierung:

• Platzsparend (nur 2 Bytes), skalierbar auf 65.536 Typen.
• Ermöglicht Clients das einfache Parsen des Typpräfixes ohne Auswirkungen auf die Daten.
• Vereinfacht API-Upgrades durch versionierte Nachrichtentypen.

const MESSAGE_TYPE_TO_HEADER = {
  RENDER_UI: "aa",
  UPDATE_UI: "ab",
  SHOW_LOADING: "ac",
  RENDER_UI_V2: "ad",
  /* ... */
};

Wir verwenden auch Trennzeichen zum Trennen von Nachrichtenfeldern, um die Kodierungs-/Dekodierungsgeschwindigkeit und die Speichereffizienz im Vergleich zu JSON zu verbessern.

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 };
}

Durch die Verwendung von TypeScript können wir Nachrichtenschemata zwischen Frontend und Backend teilen und so Inkonsistenzen verhindern.

Heartbeat-Mechanismus: Stille Verbindungsabbrüche erkennen

Unerwartete Verbindungsabbrüche ohne Abschlussereignisse können zu veralteten Verbindungen führen. Ein robuster Herzschlagmechanismus ist unerlässlich:

• Der Server sendet alle 30 Sekunden Ping -Nachrichten und erwartet Pong -Antworten.
• Clients trennen und verbinden sich wieder, wenn ein Ping nicht innerhalb von 45 Sekunden empfangen wird.
• Der Server schließt Verbindungen, die die Pong -Antworten innerhalb von 45 Sekunden verpassen.

Diese bidirektionale Herzschlagüberwachung erkennt und behandelt Situationen, in denen das Netzwerk des Kunden funktional erscheint, der Server jedoch keine Antworten erhält.

http fallback: Handhabungsnetzwerkbeschränkungen

Websockets können in restriktiven Netzwerken blockiert werden. Compose verwendet Server-Sent-Ereignisse (SSE) als Fallback für den Empfang von Updates und HTTP-Anforderungen für die Client-zu-Server-Kommunikation.

Die HTTP-basierte Natur von

SSE macht sie weniger anfällig für das Blockieren und bietet eine zuverlässige Alternative mit relativ geringer Latenz.

Weitere Überlegungen

Skalierung von Websockets beinhaltet zusätzliche Komplexitäten:

• Mangel an Standard -Tools: Funktionen wie Ratenlimitierungs- und Datenvalidierung erfordern häufig eine benutzerdefinierte Implementierung.
• Unfähigkeit, Antworten zu cache: Im Gegensatz zu HTTP fehlen Websockets Standard -Caching -Mechanismen.
• pro-message-Authentifizierung: Sicherstellen, dass die Gültigkeit jeder Nachricht vor der Verarbeitung für die Sicherheit entscheidend ist.

Trotz dieser Herausforderungen bleiben Websockets die optimale Lösung für den Aufbau schneller, Echtzeit- und kollaborativer Anwendungen. Bei Compose, WebSockets führen unsere gesamte Plattform mit und ermöglicht es Entwicklern, mithilfe unserer SDKs vollständige Webanwendungen aus der Backend -Logik zu erstellen. Erfahren Sie mehr in unserer Dokumentation.

Das obige ist der detaillierte Inhalt vonLehren aus der Skalierung von WebSockets. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!