Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure Web PubSub erbjuder flera sätt att lägga till realtidskommunikation i en applikation. Du kan börja med flexibla meddelandeprimitiv, behålla ett etablerat protokoll och en programmeringsmodell, eller använda API:er designade för ett specifikt applikationsscenario.
Rätt val låter dig undvika att bygga eller driva funktioner som inte särskiljer din applikation. Den här artikeln förklarar vad varje alternativ erbjuder, vad som förblir under din kontroll och var varje alternativ ger mest värde.
Välj baserat på vad du vill bygga
| Om du behöver... | Börja med... | Varför |
|---|---|---|
| Designa anpassade realtidsbeteenden för instrumentpaneler, spel, notiser, AI-tokenströmning, signalering eller andra applikationsscenarier | Web PubSub (bastjänst) | Du styr applikationsprotokollet och affärslogiken medan Azure hanterar anslutningar och meddelandeleverans. |
| Skala upp en befintlig Socket.IO applikation eller använd Socket.IO API:er och ekosystem | Socket.IO på Azure | Du behåller Socket.IO programmeringsmodellen utan att driva Socket.IO anslutningsinfrastruktur eller en adapter. |
| Anslut MQTT-klienter över WebSocket eller utbyt meddelanden mellan MQTT och Web PubSub-klienter | MQTT-stöd | Du kan använda MQTT-klientbibliotek och låta Web PubSub översätta mellan stödda MQTT och inbyggda koncept. |
| Lägg till en-till-en- eller gruppchatt med rum, medlemskap, meddelandeordning och historik | Web PubSub-chatt | Du får chattspecifika API:er och hanterade chattfunktioner istället för att designa dem från lågnivå-meddelandeprimitiv. |
Förstå hur förmågorna skiljer sig åt
Tänk på basversionen av Web PubSub som en flexibel realtidsgrund. Den ger dig byggstenar som kopplingar, användare, grupper och händelser. Du bestämmer vad dessa byggstenar betyder i din applikation.
De andra funktionerna tar bort arbete för ett mer specifikt behov:
- Socket.IO på Azure bevarar programmeringsmodellen som Socket.IO utvecklare redan känner till.
- MQTT-stöd anpassar en stödd delmängd av MQTT till Web PubSub så att MQTT-klienter kan delta i realtidsmeddelanden.
- Web PubSub-chatt erbjuder en högre nivå av applikationsmodell för rum, medlemmar, meddelanden och historik.
De är inte utbytbara namn för samma API. Det bästa alternativet är det som matchar de abstraktioner som din applikation redan använder eller annars skulle behöva bygga.
| Area | Web PubSub (bastjänst) | Socket.IO på Azure | MQTT-stöd | Web PubSub-chatt |
|---|---|---|---|---|
| Primärt värde | Flexibla byggstenar i realtid | Utveckling av bekant Socket.IO utan självhostad skalning | MQTT-klientkompatibilitet och protokollinteroperabilitet | En färdig chattmodell |
| Programmeringsyta | Web PubSub SDK:er, WebSocket-subprotokoll, händelsehanterare och REST-API:er | Socket.IO klient- och server-API:er | Stödda MQTT-paket och koncept över WebSocket | API:er för chattklient och server |
| Huvudsakliga applikationskoncept | Anslutningar, användare, grupper och evenemang | Sockets, rum, namnrymder och händelser | Klienter, ämnen, prenumerationer och meddelanden | Användare, rum, medlemmar, meddelanden och historik |
| Azure handles | Anslutningens livscykel, skalning, routing och meddelandeutlösning | Anslutningshosting, skalning och samordning mellan appservrar | Översättning mellan stödda MQTT- och Web PubSub-koncept | Leverans i realtid, utsläpp, rumsmedlemskap, beställning av meddelanden och uthållighet |
| Du designar | Händelsemodell, nyttolaster, auktorisationsflöde, affärslogik och eventuell persistens | Applikationshändelser och affärslogik | Ämnesdesign, affärslogik och funktioner utanför den stödda MQTT-delmängden | Chattupplevelse, applikationsidentiteter, auktoriseringsuppgifter och affärslogik |
| Bästa passform | Anpassade eller blandade realtidsarbetsbelastningar | Nya eller befintliga Socket.IO applikationer | Webbklienter som använder MQTT-bibliotek eller blandade MQTT- och Web PubSub-klienter | Applikationer där chatt är en produktfunktion |
Web PubSub (bastjänst)
Välj bas-Web PubSub när flexibilitet är mer värdefullt än en specialbyggd applikationsmodell. Den tillhandahåller hanterad realtidstransport och routing samtidigt som din händelsemodell och affärsbeteende lämnas under din kontroll.
Till exempel kan din applikation:
- Skicka en uppdatering till alla anslutna klienter, en grupp, en användare eller en anslutning.
- Ta emot klienthändelser i en applikationsserver eller Azure Functions.
- Tillåt auktoriserade klienter att publicera meddelanden direkt till en grupp.
- Använd anpassade payloads och händelser för applikationsspecifika arbetsflöden.
Denna flexibilitet är användbar för live-dashboards, samordning av multiplayer, notiser, samarbetsupplevelser, enhetsuppdateringar, signalering och AI-tokenströmning. Du undviker att driva WebSocket-servrar, men du designar ändå domänfunktioner som meddelandepersistens, historik eller chattmedlemskap när din applikation behöver det.
Socket.IO på Azure
Välj Socket.IO på Azure när ditt team redan använder Socket.IO eller vill ha sina händelsedrivna API:er och ekosystem.
I en självhostad Socket.IO applikation måste ditt team upprätthålla tillståndsfulla klientanslutningar och samordna flera Socket.IO servrar med hjälp av en adapter. Socket.IO på Azure hanterar anslutningsinfrastrukturen och serverkoordineringen. Denna hantering låter dina applikationsservrar fokusera på händelsehantering och affärslogik.
Det viktigaste värdet är kontinuitet: du kan behålla den Socket.IO programmeringsmodellen och migrera en befintlig applikation med endast begränsade kodändringar istället för att designa om den kring ett annat realtids-API.
För att lära dig mer, se Översikt Socket.IO om Azure.
MQTT-stöd
Välj MQTT-stöd när klienter använder MQTT-bibliotek och ansluter via WebSocket, eller när MQTT-klienter behöver utbyta meddelanden med inbyggda Web PubSub-klienter.
Web PubSub känner igen stödda MQTT-meddelanden och kopplar MQTT-koncept, såsom ämnen och prenumerationer, till Web PubSub-koncept. Denna mappning sparar dig från att bygga och driva ett separat protokollöversättningslager.
MQTT-stöd i Web PubSub är en lättviktig anpassning, inte en fullständig MQTT-mäklare. Den stöder endast MQTT-funktionerna som mappas till Web PubSub. Funktioner som wildcard-prenumerationer, behållna meddelanden, delade prenumerationer och ämnesaliaser stöds inte.
Om din lösning kräver en omfattande MQTT-mäklare, överväg MQTT-stöd i Azure Event Grid. För stödda Web PubSub-scenarier och protokolldetaljer, se MQTT i Azure Web PubSub-tjänsten.
Web PubSub-chatt
Välj Web PubSub chat när chatt är en produktfunktion och du vill lägga utvecklingstid på användarupplevelsen istället för att skapa den underliggande chattmodellen.
Genom att använda basversionen Web PubSub kan du bygga en egen chatt, men ditt team definierar meddelandepayloads och implementerar frågor som rum, medlemskap, meddelandeordning och historik. Web PubSub-chatt tillhandahåller dessa koncept genom specialbyggda API:er och SDK:er.
Web PubSub chat är en högre nivå av funktionalitet byggd på Web PubSubs realtidsinfrastruktur. Den innehåller:
- En-till-en och gruppchatt.
- Rum och medlemshantering.
- Beställde meddelanden i realtid.
- Meddelandets beständighet och rumshistorik.
- Roller och behörigheter för chattoperationer.
Du fortsätter att äga din applikations identitetsintegration, användarupplevelse och affärsregler, medan tjänsten hanterar gemensam chattinfrastruktur.
För att lära dig mer, se Vad är Web PubSub chat?
Gör valet
Använd dessa frågor för att begränsa beslutet:
- Behöver du bevara Socket.IO API:er eller migrera en Socket.IO applikation? Välj Socket.IO på Azure.
- Behöver dina klienter kommunicera genom att använda det stödda MQTT-protokollet över WebSocket? Välj MQTT-support.
- Behöver du inbyggda rum, medlemmar, meddelandeordning och meddelandehistorik för en chattupplevelse? Välj Web PubSub chat.
- Behöver du en anpassad händelsemodell eller ett realtidsscenario som inte passar de föregående alternativen? Välj Web PubSub (bastjänst).
Att välja en mer specialiserad funktion kan förkorta utvecklingstiden eftersom Azure tillhandahåller mer av applikationsmodellen. Att välja bastjänsten ger dig mer kontroll när dina behov är unika. Börja med den högsta kapaciteten som uppfyller dina behov, och använd bastjänsten när den flexibiliteten skapar värde för din applikation.