WebSocketベースのWebアプリがありますが、デプロイするとすべての接続が切断され、クライアントが再接続する必要があるため、デプロイするのをためらうことがよくあります。私は現在、優れたオフライン同期機能を組み込んでいませんが、それでもこれに依存したくありません。
デプロイの場合、更新中にサーバーをローテーションから外し、サーバーをローテーションから外すことを計画していました。これは、サーバーインスタンスの1つが、他のインスタンスが稼働しているときにクラッシュするという状況には対処していません。
彼らの証明された技術はこれに対処するためのものですか？
クライアント側でerrorまたはイベントをリッスンし、必要に応じてソケットを再起動できるはずです。closeそれはあなたの問題を解決しますか？
Kaazing を使用して、socket.io をスケーラブルにデプロイできます。Kaazing でサポートされているクラスタリングにより、ゲートウェイをクラスター内外でホットスワップできます。一部のお客様は、クラスター化された二重 dmz を構成して展開を管理しています。このセットアップの最も優れた点は、クライアントが現在利用可能な接続パスに適切に接続しようとしている状態で、任意のゲートウェイを再展開できることです。これは安全で非常にスケーラブルです。
追加の利点は、socket.IO のトランスポートを websocket のみに切り替えると、Kaazing がエミュレーションも処理し、socket.io よりも少し進んで、いかなる種類のポーリングにも依存しないエミュレーションを提供することです。エミュレーションは Internet Explorer バージョン 6 までさかのぼります。
大量生産に関しては、クラスタリングと負荷分散を堅牢な方法で処理することをお勧めします。
これを試す場合は、ws を使用するように socket.io トランスポートを変更し、クライアントの Kaazing ライブラリ上で実行してください。サーバー側で行う必要があるのは、Node.JS への接続をプロキシすることだけです。追加のアダプターを作成してブローカーと socket.IO を活用し、各ゲートウェイの背後でさらに多くの負荷分散を行うことができるため、複数のノードが特定のゲートウェイで接続をラウンドロビンすることができます。