スケーリングWebSocketsからのレッスン-jsチュートリアル-php.cn

スケーリングWebSocketsからのレッスン

DDD

リリース： 2025-01-25 04:49:11

オリジナル

417 人が閲覧しました

WebSocket: リアルタイムアプリには不可欠ですが、スケーリングには慎重な計画が必要です

リアルタイムの同期アプリケーションに対する需要が高まっているため、WebSocket は最新のソフトウェア開発において重要なコンポーネントになっています。 Compose では、WebSocket がサービスの基盤であり、バックエンド SDK がバックエンドコードのみを使用して低遅延のインタラクティブアプリケーションを配信できるようにします。ただし、WebSocket のスケーリングには大きな課題があります。学んだ重要な教訓は次のとおりです:

正常なデプロイメント: 接続の永続性の維持

シームレスな展開は非常に重要です。ユーザーは決して中断を経験すべきではありません。デプロイメント中に WebSocket 接続の持続性を確保するために、当社では堅牢な再接続戦略を採用しています。

新しいサーバーが起動されます。
古いサーバーは正常になると、ヘルスチェックに対して 503 (サービス利用不可) 応答を返し始めます。
503 が 4 回連続した後、ロードバランサーは異常なサーバーを削除します。 (ヘルスチェックは 5 秒ごとに行われ、プロセスには最大 25 秒かかります。)
古いサーバーはカスタム WebSocket クローズメッセージを送信し、クライアントにランダムな間隔で再接続を遅らせるよう指示し、再接続の急増を防ぎます。このメッセージには次のものが含まれます:
- 短い切断中 (約 10 秒) のユーザーフレンドリーなメッセージ。
- 雷のような群れの問題を避けるためのランダムな遅延。また、クライアントは、展開関連の再接続のバックオフを急激に増加させます。
- ロードバランサーがトラフィックをリダイレクトできるようにするための 20 秒の遅延。

クライアントの切断後、古いサーバーは完全にシャットダウンします。 Render や Railway などのマネージドサービスでは、展開中にクライアント接続を適切に転送するために特別な注意が必要です。これらのサービスは、すべてのリクエストが完了するまで待ってからシャットダウンすることが多いため、永続的な WebSocket 接続のダウンタイムが大幅に長くなる可能性があります。

一貫したメッセージスキーマ: 明確なコミュニケーションの定義

HTTP の組み込みルーティング規則とは異なり、WebSocket にはカスタムメッセージスキーマが必要です。 Compose では、メッセージの分類に 2 バイトのタイプのプレフィックスを使用します:

スペース効率が高く (わずか 2 バイト)、65,536 種類まで拡張可能。
クライアントはデータに影響を与えることなく、型プレフィックスを簡単に解析できます。
バージョン管理されたメッセージタイプを通じて API のアップグレードを簡素化します。

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

ログイン後にコピー

メッセージフィールドの区切りにも区切り文字を使用し、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>

ログイン後にコピー

TypeScript を使用すると、フロントエンドとバックエンドの間でメッセージスキーマを共有でき、不一致を防ぐことができます。

ハートビートメカニズム: サイレント切断の検出

close イベントが発生せずに予期せず接続が切断されると、接続が失効する可能性があります。堅牢なハートビートメカニズムが不可欠です:

サーバーは、30秒ごとにPingメッセージを送信し、ポンの応答を期待しています。
サーバーは、45秒以内にポンの応答を逃す接続を閉じます。
この双方向のハートビート監視は、クライアントのネットワークが機能的に見えるが、サーバーが応答を受け取らない状況を検出および処理します。

httpフォールバック：ネットワーク制限の処理

WebSocketsは、制限的なネットワークでブロックできます。 Composeは、アップデートを受信するためのフォールバックとしてサーバーセントイベント（SSE）を使用し、クライアント間通信のためのHTTPリクエストを使用します。

SSEのHTTPベースの性質により、ブロッキングの影響を受けにくくなり、比較的低いレイテンシーで信頼できる代替品を提供します。

さらなる考慮事項 Lessons from Scaling WebSockets

スケーリングWebSocketsには、追加の複雑さが含まれます

標準ツールの欠如：レート制限やデータの検証などの機能がしばしばカスタム実装が必要です。

応答のキャッシュ不能：

httpとは異なり、websocketsには標準的なキャッシングメカニズムがありません。

処理前に各メッセージの有効性がセキュリティに不可欠であることを確認します。これらの課題にもかかわらず、WebSocketsは、高速、リアルタイム、および共同アプリケーションを構築するための最適なソリューションのままです。 Composeでは、WebSocketsがプラットフォーム全体に電力を供給し、開発者がSDKを使用してBackEndロジックから完全なWebアプリケーションを作成できるようにします。詳細については、ドキュメントをご覧ください。

以上がスケーリングWebSocketsからのレッスンの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。