Dela via


Hur stöder Azure Web PubSub Socket.IO-biblioteket?

Den här artikeln innehåller ett tekniskt perspektiv på hur du kan migrera lokalt installerade Socket.IO appar till Azure med hjälp av Web PubSub för Socket.IO med minimala kodändringar. Du kan sedan dra nytta av förenklad apparkitektur och distribution, samtidigt som du uppnår 100 000 samtidiga anslutningar. Du behöver inte förstå allt i den här artikeln för att använda Web PubSub för Socket.IO effektivt.

Arkitektur för en lokalt installerad Socket.IO-app

Följande diagram visar en typisk arkitektur för en lokalt installerad Socket.IO app.

Diagram of a typical architecture of a self-hosted Socket.IO app, including clients, servers, a load balancer, and an adapter.

För att säkerställa att en app är skalbar och tillförlitlig har Socket.IO användare ofta en arkitektur som omfattar flera Socket.IO servrar. Klientanslutningar distribueras mellan Socket.IO servrar för att balansera belastningen på systemet.

En konfiguration av flera Socket.IO servrar medför en utmaning när utvecklare behöver skicka samma meddelande till klienter som är anslutna till en annan server. Utvecklare kallar ofta det här användningsfallet för "sändningsmeddelanden".

Den officiella rekommendationen från Socket.IO-biblioteket är att introducera en komponent på serversidan som kallas ett kort för att samordna Socket.IO servrar. Ett kort tar reda på vilka servrar klienterna är anslutna till och instruerar servrarna att skicka meddelanden.

Genom att lägga till en adapterkomponent blir både utveckling och distribution komplex. Om en arkitektur till exempel använder Redis-adaptern måste utvecklarna:

  • Implementera klibbiga sessioner.
  • Distribuera och underhålla Redis-instanser.

Den tekniska ansträngningen och tiden för att få en kommunikationskanal i realtid på plats distraherar utvecklare från att arbeta med funktioner som gör en app eller ett system unikt och värdefullt för användarna.

Vad Web PubSub for Socket.IO syftar till att lösa för utvecklare

Även om utvecklare ofta rapporterar att det är svårt att konfigurera en tillförlitlig och skalbar app som skapats med Socket.IO-biblioteket, kan utvecklare dra nytta av de intuitiva API:erna och det breda utbud av klienter som biblioteket stöder. Web PubSub for Socket.IO bygger på det värde som biblioteket ger, samtidigt som utvecklarna av komplexiteten i att hantera beständiga anslutningar på ett tillförlitligt och i stor skala avlastas.

I praktiken kan utvecklare fortsätta att använda Socket.IO-bibliotekets API:er utan att behöva etablera serverresurser för att underhålla WebSocket- eller long-polling-baserade anslutningar, vilket kan vara resursintensivt. Utvecklare behöver inte heller hantera och distribuera en adapterkomponent. Appservern behöver bara skicka en enda åtgärd och Web PubSub för Socket.IO sänder meddelandena till relevanta klienter.

Så här fungerar det

Web PubSub for Socket.IO bygger på Socket.IO protokoll genom att implementera adaptern och Engine.IO. Följande diagram visar den typiska arkitekturen när du använder Web PubSub för Socket.IO med din Socket.IO-server.

Screenshot of a typical architecture of a fully managed Socket.IO app.

Precis som en egen värdbaserad Socket.IO app måste du fortfarande vara värd för din Socket.IO programlogik på din egen server. Men med Web PubSub för Socket.IO-tjänsten:

  • Servern hanterar inte längre klientanslutningar direkt.
  • Dina klienter upprättar beständiga anslutningar med tjänsten (klientanslutningar).
  • Servrarna upprättar också beständiga anslutningar med tjänsten (serveranslutningar).

När serverlogik använder send to client, broadcastoch add client to rooms, skickas dessa åtgärder till tjänsten via en etablerad serveranslutning. Meddelanden från servern översätts till Socket.IO åtgärder som Socket.IO klienter kan förstå. Därför kan alla befintliga Socket.IO implementering fungera utan större ändringar. Den enda ändring som du behöver göra är att ändra slutpunkten som klienterna ansluter till. Mer information finns i Migrera en lokalt installerad Socket.IO app som ska hanteras fullständigt i Azure.

När en klient ansluter till tjänsten:

  • Vidarebefordrar Engine.IO-anslutningen (connect) till servern.
  • Hanterar transportuppgradering av klientanslutningar.
  • Vidarebefordrar alla Socket.IO meddelanden till servern.