Ist Azure SignalR Service bereit für den Produktionseinsatz?
Ja, sowohl die Unterstützung von ASP.NET Core SignalR als auch die von ASP.NET SignalR sind allgemein verfügbar.
Wenn mehrere Anwendungsserver vorhanden sind, werden Clientmeldungen an alle Server oder nur an einen von ihnen gesendet?
Zwischen einem Client und einem Anwendungsserver besteht eine 1:1-Zuordnung. Meldungen von einem Client werden immer an denselben Anwendungsserver gesendet.
Die Zuordnung wird aufrecht erhalten, bis die Verbindung vom Client oder Anwendungsserver getrennt wird.
Wenn einer meiner Anwendungsserver nicht betriebsbereit ist, wie kann ich ihn auffinden und darüber informiert werden?
Azure SignalR Service überwacht den Heartbeat der Anwendungsserver. Wenn über einen angegebenen Zeitraum hinweg keine Heartbeats empfangen werden, gilt der Anwendungsserver als offline. Alle Clientverbindungen, die diesem Anwendungsserver zugeordnet sind, werden getrennt.
Warum löst mein benutzerdefinierter „IUserIdProvider“ eine Ausnahme aus, wenn ich vom ASP.NET Core-SignalR-SDK zum Azure SignalR Service-SDK wechsle?
Der Parameter HubConnectionContext context unterscheidet sich zwischen dem ASP.NET Core SignalR SDK und dem Azure SignalR Service SDK, wenn IUserIdProvider aufgerufen wird.
In ASP.NET Core SignalR ist HubConnectionContext context der Kontext aus der physischen Clientverbindung mit gültigen Werten für alle Eigenschaften.
Im Azure SignalR Service SDK ist HubConnectionContext context der Kontext aus der logischen Clientverbindung. Die physische Client ist mit der Azure SignalR Service-Instanz verbunden, weshalb also nur eine begrenzte Anzahl von Eigenschaften bereitgestellt wird.
Vorerst sind nur HubConnectionContext.GetHttpContext() und HubConnectionContext.User für den Zugriff verfügbar.
Sie können den Quellcode überprüfen.
Kann ich die in Azure SignalR Service verfügbaren Transporte auf der Serverseite mit ASP.NET Core SignalR konfigurieren? Kann ich beispielsweise den WebSocket-Transport deaktivieren?
Ja. Informationen zum Konfigurieren finden Sie unter Transportkonfiguration.
Sie können auch clientseitige Transporte konfigurieren, wie in ASP.NET Core SignalR-Konfiguration dokumentiert.
Welche Bedeutung haben im Azure-Portal angezeigte Metriken wie die Nachrichtenanzahl oder die Anzahl der Verbindungen? Welchen Aggregationstyp sollte ich auswählen?
Ausführliche Informationen zur Berechnung dieser Metriken finden Sie unter Nachrichten und Verbindungen in Azure SignalR Service.
Im Bereich „Übersicht“ von Azure SignalR Service-Ressourcen ist bereits der entsprechende Aggregationstyp für Sie ausgewählt. Sie können Unterstützte Metriken mit Azure Monitor als Referenz verwenden.
Was bedeuten die Dienstmodi „Standard“, „Serverlos“ und „Klassisch“? Wie kann ich eine Auswahl treffen?
Für neue Anwendungen sollten nur der Standard- und der serverlose Modus verwendet werden. Der Hauptunterschied besteht darin, ob Sie über Anwendungsserver verfügen, die Serververbindungen mit dem Dienst herstellen (z. B. AddAzureSignalR() verwenden, um Verbindungen mit dem Dienst herzustellen). Wenn dies der Fall ist, verwenden Sie den Standardmodus, sonst den serverlosen Modus.
Der klassische Modus ist für Abwärtskompatibilität mit vorhandenen Anwendungen ausgelegt und sollte für neue Anwendungen nicht verwendet werden.
Weitere Informationen zum Dienstmodus finden Sie unter Dienstmodi in Azure SignalR Service.
Kann ich im serverlosen Modus Nachrichten vom Client senden?
Sie können Nachrichten vom Client senden, wenn Sie in Ihrer SignalR-Instanz Upstream-Endpunkte konfigurieren. Upstream-Endpunkte sind ein Satz von Endpunkten, die Nachrichten und Verbindungsereignisse vom SignalR Service empfangen können. Wenn keine Upstream-Endpunkte konfiguriert sind, werden Nachrichten vom Client ignoriert.
Weitere Informationen finden Sie unter Upstream-Endpunkte.
Das Feature „Upstream-Endpunkte“ befindet sich derzeit in der öffentlichen Vorschau.
Gibt es bei der Verwendung von Azure SignalR Service für ASP.NET SignalR Funktionsunterschiede?
Bei Verwendung von Azure SignalR Service werden einige APIs und Features von ASP.NET SignalR nicht unterstützt:
- Die Möglichkeit, beliebige Zustände zwischen Clients und dem Hub zu übergeben (häufig als
HubStatebezeichnet), wird nicht unterstützt. - Die
PersistentConnection-Klasse wird nicht unterstützt. - Dauerhafter Frame-Transport wird nicht unterstützt.
- Azure SignalR Service gibt keine an den Client gesendeten Nachrichten mehr wieder, wenn der Client offline ist.
- Wenn Sie Azure SignalR Service verwenden, wird der Datenverkehr für eine Clientverbindung für die Dauer der Verbindung immer an eine App-Serverinstanz weitergeleitet (auch als sticky bezeichnet).
Bei der Unterstützung für ASP.NET SignalR liegt der Fokus auf der Kompatibilität. Daher werden nicht alle neuen Features von ASP.NET Core SignalR unterstützt. Beispielsweise sind MessagePack und Streaming nur für ASP.NET Core SignalR-Anwendungen verfügbar.
Sie können Azure SignalR Service für verschiedene Dienstmodi konfigurieren: Classic, Default und Serverless. Der Serverless-Modus wird für ASP.NET nicht unterstützt. Die REST-API auf Datenebene wird ebenfalls nicht unterstützt.
Wo befinden sich meine Daten?
Azure SignalR Service speichert keine Kundendaten. Wenn Sie Azure SignalR Service in Verbindung mit anderen Azure-Diensten (z. B. Azure Storage) zu Diagnosezwecken verwenden, finden Sie in dieser Azure Privacy Übersicht (Whitepaper) Informationen zum Aufrechterhalten von Data Residency in Azure-Regionen.
Nach welchen Kriterien wähle ich zwischen Azure SignalR Service und dem Azure Web PubSub-Dienst?
Sowohl Azure SignalR Service als auch der Azure Web PubSub-Dienst helfen Kunden beim einfachen Erstellen von Echtzeitwebanwendungen mit hoher Skalierbarkeit und Verfügbarkeit, und ermöglichen es Kunden, sich auf ihre Geschäftslogik zu konzentrieren, anstatt die Messaginginfrastruktur zu verwalten. Im Allgemeinen kannst Du Azure SignalR Service wählen, wenn Du bereits die SignalR-Bibliothek zum Erstellen von Echtzeitanwendungen verwendest. Wenn Sie stattdessen nach einer generischen Lösung suchen, um Echtzeitanwendungen basierend auf WebSocket und dem Veröffentlichen-Abonnieren-Muster zu erstellen, können Sie den Azure Web PubSub-Dienst wählen. Der Azure Web PubSub-Dienst ist kein Ersatz für Azure SignalR Service und umgekehrt; sie zielen auf unterschiedliche Szenarien ab. Der folgende Leitfaden hilft Dir bei der Entscheidung, welchen Dienst Du für Dein Szenario nutzen solltest.
Azure SignalR Service ist in folgenden Fällen besser geeignet:
- Sie verwenden bereits ASP.NET oder ASP.NET Core SignalR, nutzen hauptsächlich .NET oder müssen eine Integration mit dem .NET-Ökosystem (z. B. Blazor) vornehmen.
- Für Ihre Plattform ist ein SignalR-Client verfügbar.
- Sie benötigen ein etabliertes Protokoll, das eine Vielzahl unterschiedlicher folgender Aspekte unterstützt:
- Aufrufmuster (RPC und Streaming)
- Transporte (WebSocket, Server-Sent-Events und Long-Polling)
- Sie benötigen einen Client, der die Lebensdauer der Verbindung in Ihrem Auftrag verwaltet.
Der Azure Web PubSub-Dienst ist in folgenden Situationen besser geeignet:
- Sie müssen Echtzeitanwendungen basierend auf der WebSocket-Technologie erstellen oder über WebSocket veröffentlichen und abonnieren.
- Sie möchten Ihr eigenes Unterprotokoll erstellen oder vorhandene erweiterte Protokolle über WebSocket verwenden (z. B. MQTT, AMQP über WebSocket).
- Sie suchen einen einfachen Server, der z. B. Nachrichten an den Client sendet, ohne das konfigurierte Back-End zu durchlaufen.