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

  • Artikel

Den här artikeln ger 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 Socket.IO app med egen värd

Följande diagram visar en typisk arkitektur för en Socket.IO app med egen värd.

Diagram över en typisk arkitektur för en lokalt installerad Socket.IO app, inklusive klienter, servrar, en lastbalanserare och ett kort.

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 räknar ut vilka servrar som klienterna är anslutna till och instruerar servrarna att skicka meddelanden.

Att lägga till en adapterkomponent medför komplexitet för både utveckling och distribution. 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 avleder 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 med 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 resurskrävande. 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.

Skärmbild av en typisk arkitektur för en fullständigt hanterad Socket.IO app.

Precis som en lokalt installerad 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.
  • Klienterna 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.