Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Web PubSub bietet mehrere Möglichkeiten, eine Anwendung in Echtzeit zu kommunizieren. Du kannst mit flexiblen Messaging-Primitiven beginnen, ein etabliertes Protokoll und Programmiermodell beibehalten oder APIs verwenden, die für ein bestimmtes Anwendungsszenario entwickelt wurden.
Die richtige Entscheidung ermöglicht es Ihnen, Funktionen zu vermeiden oder zu bauen, die Ihre Anwendung nicht unterscheiden. Dieser Artikel erklärt, was jede Option bietet, was unter Ihrer Kontrolle bleibt und wo jede Option den größten Wert bietet.
Wähle basierend darauf, was du bauen möchtest.
| Wenn Sie Folgendes tun müssen ... | Fang an mit... | Warum? |
|---|---|---|
| Entwickle benutzerdefinierte Echtzeit-Verhaltensweisen für Dashboards, Spiele, Benachrichtigungen, KI-Token-Streaming, Signalisierung oder andere Anwendungsszenarien | Web PubSub (Basisdienst) | Sie steuern das Anwendungsprotokoll und die Geschäftslogik, während Azure Verbindungen und Nachrichtenzustellung verwaltet. |
| Skalieren Sie eine bestehende Socket.IO Anwendung oder nutzen Sie die Socket.IO APIs und das Ökosystem | Socket.IO Azure | Du behältst das Socket.IO Programmiermodell, ohne Socket.IO Verbindungsinfrastruktur oder einen Adapter zu betreiben. |
| Verbinden Sie MQTT-Clients über WebSocket oder tauschen Sie Nachrichten zwischen MQTT und Web PubSub-Clients aus | MQTT-Unterstützung | Du kannst MQTT-Client-Bibliotheken verwenden und Web PubSub zwischen unterstütztem MQTT und nativen Konzepten übersetzen lassen. |
| Füge Einzelgespräche oder Gruppenchats mit Räumen, Mitgliedschaft, Nachrichtenreihenfolge und Historie hinzu | Web PubSub Chat | Man erhält chat-spezifische APIs und verwaltete Chat-Funktionen, anstatt sie aus niedrigstufigen Messaging-Primitiven zu entwerfen. |
Verstehen Sie, wie sich die Fähigkeiten unterscheiden
Betrachten Sie das Basis-Web PubSub als eine flexible Echtzeit-Basis. Es gibt dir Bausteine wie Verbindungen, Nutzer, Gruppen und Ereignisse. Du entscheidest, was diese Bausteine in deiner Bewerbung bedeuten.
Die anderen Funktionen entfernen Arbeit für einen spezifischeren Bedarf:
- Socket.IO auf Azure bewahrt das Programmiermodell, das Socket.IO Entwickler bereits kennen.
- Die MQTT-Unterstützung passt eine unterstützte Teilmenge von MQTT an Web PubSub an, sodass MQTT-Clients an Echtzeit-Nachrichten teilnehmen können.
- Web PubSub Chat bietet ein höherwertiges Anwendungsmodell für Räume, Mitglieder, Nachrichten und Verlauf.
Es sind keine austauschbaren Namen für dieselbe API. Die beste Option ist die, die zu den Abstraktionen passt, die deine Anwendung bereits verwendet oder sonst bauen müsste.
| Area | Web PubSub (Basisdienst) | Socket.IO Azure | MQTT-Unterstützung | Web PubSub Chat |
|---|---|---|---|---|
| Primärer Wert | Flexible Echtzeit-Bausteine | Vertraute Socket.IO Entwicklung ohne selbstgehostetes Skalieren | MQTT-Client-Kompatibilität und Protokollinteroperabilität | Ein einsatzbereites Chat-Modell |
| Programmierfläche | Web PubSub SDKs, WebSocket-Subprotokolle, Ereignishandler und REST-APIs | Socket.IO Client- und Server-APIs | Unterstützte MQTT-Pakete und -Konzepte über WebSocket | Chat-Client- und Server-APIs |
| Hauptanwendungskonzepte | Verbindungen, Nutzer, Gruppen und Veranstaltungen | Sockets, Räume, Namensräume und Ereignisse | Kunden, Themen, Abonnements und Nachrichten | Nutzer, Räume, Mitglieder, Nachrichten und Verlauf |
| Azure handles | Verbindungslebenszyklus, Skalierung, Routing und Nachrichten-Fanout | Verbindungshosting, Skalierung und Koordination zwischen App-Servern | Übersetzung zwischen unterstützten MQTT- und Web-PubSub-Konzepten | Echtzeit-Zustellung, Fan-Out, Zimmermitgliedschaft, Nachrichtenbestellung und Persistenz |
| Du entwirfst | Ereignismodell, Nutzlasten, Autorisierungsfluss, Geschäftslogik und jegliche Persistenz | Anwendungsereignisse und Geschäftslogik | Themendesign, Geschäfts-Logik und Funktionen außerhalb des unterstützten MQTT-Subsets | Chat-Erfahrung, Anwendungsidentitäten, Autorisierungszuweisungen und Geschäftslogik |
| Beste Passform | Benutzerdefinierte oder gemischte Echtzeit-Arbeitslasten | Neue oder bestehende Socket.IO Anwendungen | Webclients, die MQTT-Bibliotheken oder gemischte MQTT- und Web-PubSub-Clients verwenden | Anwendungen, bei denen Chat ein Produktfeature ist |
Web PubSub (Basisdienst)
Wählen Sie das Basis-Web PubSub, wenn Flexibilität wertvoller ist als ein speziell entwickeltes Anwendungsmodell. Es bietet einen verwalteten Echtzeit-Transport und Routing, während Ihr Ereignismodell und Ihr Geschäftsverhalten Ihrer Kontrolle überlassen werden.
Zum Beispiel kann Ihre Anwendung:
- Senden Sie ein Update an alle verbundenen Clients, eine Gruppe, einen Benutzer oder eine Verbindung.
- Empfangen Sie Client-Ereignisse in einem Anwendungsserver oder Azure Functions.
- Erlauben Sie autorisierten Clients, Nachrichten direkt an eine Gruppe zu veröffentlichen.
- Verwenden Sie benutzerdefinierte Nutzlasten und Ereignisse für anwendungsspezifische Workflows.
Diese Flexibilität ist nützlich für Live-Dashboards, Mehrspieler-Koordination, Benachrichtigungen, kollaborative Erlebnisse, Geräte-Updates, Signalisierung und KI-Token-Streaming. Sie vermeiden den Betrieb von WebSocket-Servern, entwerfen aber dennoch Domänenfunktionen wie Nachrichtenpersistenz, Verlauf oder Chat-Mitgliedschaft, wenn Ihre Anwendung sie benötigt.
Socket.IO Azure
Wählen Sie Socket.IO auf Azure, wenn Ihr Team bereits Socket.IO nutzt oder seine ereignisgesteuerten APIs und das Ökosystem möchte.
In einer selbstgehosteten Socket.IO-Anwendung muss Ihr Team zustandsbehaftete Client-Verbindungen pflegen und mehrere Socket.IO Server mithilfe eines Adapters koordinieren. Socket.IO auf Azure verwaltet die Verbindungsinfrastruktur und die Serverkoordination. Dieses Management ermöglicht es Ihren Anwendungsservern, sich auf die Ereignisbehandlung und die Geschäftslogik zu konzentrieren.
Der entscheidende Wert ist die Kontinuität: Man kann das Socket.IO Programmiermodell beibehalten und eine bestehende Anwendung mit nur begrenzten Codeänderungen migrieren, anstatt sie um eine andere Echtzeit-API herum neu zu gestalten.
Um mehr zu erfahren, siehe Übersicht Socket.IO zu Azure.
MQTT-Unterstützung
Wählen Sie MQTT-Unterstützung, wenn Clients MQTT-Bibliotheken nutzen und sich über WebSocket verbinden, oder wenn MQTT-Clients Nachrichten mit nativen Web PubSub-Clients austauschen müssen.
Web PubSub erkennt unterstützte MQTT-Nachrichten und verbindet MQTT-Konzepte wie Themen und Abonnements mit Web-PubSub-Konzepten. Dieses Mapping erspart dir den Aufbau und Betrieb einer separaten Protokollübersetzungsschicht.
Die MQTT-Unterstützung in Web PubSub ist eine leichte Anpassung, kein vollständiger MQTT-Broker. Es unterstützt nur die MQTT-Funktionen, die auf Web PubSub abgebildet sind. Funktionen wie Wildcard-Abonnements, behaltene Nachrichten, geteilte Abonnements und Themenaliase werden nicht unterstützt.
Wenn Ihre Lösung einen umfassenden MQTT-Broker erfordert, sollten Sie MQTT-Unterstützung in Azure Event Grid in Betracht ziehen. Für unterstützte Web PubSub-Szenarien und Protokolldetails siehe MQTT im Azure Web PubSub-Service.
Web PubSub Chat
Wählen Sie Web PubSub Chat, wenn Chat ein Produktfeature ist und Sie Entwicklungszeit in die Benutzererfahrung investieren möchten, anstatt das zugrundeliegende Chat-Modell zu erstellen.
Mit dem Basis-Web PubSub können Sie benutzerdefinierte Chats erstellen, aber Ihr Team definiert Nachrichtenpayloads und implementiert Aspekte wie Räume, Mitgliedschaft, Nachrichtenreihenfolge und Verlauf. Web PubSub Chat bietet diese Konzepte durch speziell entwickelte APIs und SDKs.
Web PubSub Chat ist eine höherwertige Funktion, die auf der Echtzeit-Infrastruktur von Web PubSub basiert. Sie bietet:
- Eins-zu-eins und Gruppenchat.
- Zimmer und Mitgliederverwaltung.
- Bestellte Echtzeit-Nachrichten.
- Nachrichtenpersistenz und Raumverlauf.
- Rollen und Berechtigungen für Chat-Operationen.
Sie besitzen weiterhin die Identitätsintegration, das Nutzererlebnis und die Geschäftsregeln Ihrer Anwendung, während der Dienst die gemeinsame Chat-Infrastruktur betreut.
Um mehr zu erfahren, siehe Was ist Web PubSub Chat?
Triff die Entscheidung
Nutzen Sie diese Fragen, um die Entscheidung einzugrenzen:
- Muss man Socket.IO APIs erhalten oder eine Socket.IO Anwendung migrieren? Wähle Socket.IO auf Azure.
- Müssen Ihre Clients über das unterstützte MQTT-Protokoll über WebSocket kommunizieren? Wähle MQTT-Support.
- Benötigen Sie eingebaute Räume, Mitglieder, Nachrichtenreihenfolge und Nachrichtenverlauf für ein Chat-Erlebnis? Wählen Sie Web PubSub Chat.
- Benötigen Sie ein benutzerdefiniertes Ereignismodell oder ein Echtzeitszenario, das nicht zu den vorherigen Optionen passt? Wählen Sie Web PubSub (Basisdienst).
Die Wahl einer spezialisierteren Funktion kann die Entwicklungszeit verkürzen, da Azure mehr vom Anwendungsmodell bereitstellt. Die Wahl des Basisdienstes gibt Ihnen mehr Kontrolle, wenn Ihre Anforderungen einzigartig sind. Beginnen Sie mit der höchsten Fähigkeit, die Ihren Anforderungen entspricht, und nutzen Sie den Basisdienst, wenn diese Flexibilität einen Mehrwert für Ihre Anwendung schafft.