Dienstmodus in Azure SignalR Service
Dienstmodus ist ein wichtiges Konzept in Azure SignalR Service. SignalR Service unterstützt derzeit drei Dienstmodi: Standard, Serverlos und Klassisch. Ihre SignalR Service-Ressource verhält sich in jedem Modus anders. In diesem Artikel erfahren Sie, wie Sie den richtigen Dienstmodus basierend auf Ihrem Szenario auswählen.
Festlegen des Dienstmodus
Sie werden aufgefordert, einen Dienstmodus anzugeben, wenn Sie im Azure-Portal eine neue SignalR-Ressource erstellen.
Sie können den Dienstmodus auch später im Menü „Einstellungen“ ändern.
Verwenden Sie az signalr create und az signalr update, um den Dienstmodus mithilfe der Azure SignalR-CLI festzulegen oder zu ändern.
Standardmodus
Wie der Name schon besagt, ist der ModusStandard der Standarddienstmodus für SignalR Service. Im Standardmodus funktioniert Ihre Anwendung wie eine typische ASP.NET Core SignalR- oder ASP.NET SignalR-Anwendung (veraltet). Sie haben eine Webserveranwendung, die einen Hub (einen sogenannten Hubserver) hostet, und die Clients verfügen über eine Vollduplexkommunikation mit dem Hubserver. Der Unterschied zwischen ASP.NET Core SignalR und Azure SignalR Service ist Folgender: Mit ASP.NET Core SignalR stellt der Client eine direkte Verbindung mit dem Hubserver her. Bei Azure SignalR Service stellen sowohl der Client als auch der Hubserver eine Verbindung mit SignalR Service her und verwenden den Dienst als Proxy. Das folgende Diagramm zeigt die typische Anwendungsstruktur im Standardmodus.
Der Standardmodus ist in der Regel die richtige Wahl, wenn Sie über eine SignalR-Anwendung verfügen, die Sie mit SignalR Service verwenden möchten.
Verbindungsrouting im Standardmodus
Im Standardmodus gibt es WebSocket-Verbindungen zwischen dem Hubserver und SignalR Service (sogenannte Serververbindungen). Diese Verbindungen werden zum Übertragen von Nachrichten zwischen Server und Client verwendet. Wenn ein neuer Client verbunden wird, leitet SignalR Service den Client über vorhandene Serververbindungen an einen Hubserver weiter (sofern Sie über mehr als einen Server verfügen). Die Clientverbindung ist während ihrer gesamten Lebensdauer an denselben Hubserver gebunden. Diese Eigenschaft wird auch als Connection Stickiness (fest an ein bestimmtes Ziel gebundene Verbindung) bezeichnet. Wenn der Client Nachrichten sendet, sendet er diese immer an denselben Hubserver. Durch dieses Verhalten können Sie bestimmte Zustände einzelner Verbindungen auf Ihrem Hubserver sicher verwalten. Wenn Sie z. B. etwas zwischen Server und Client streamen möchten, müssen Sie nicht darüber nachdenken, dass Datenpakete an verschiedene Server gesendet werden könnten.
Wichtig
Im Standardmodus kann ein Client erst dann eine Verbindung herstellen, wenn zuerst ein Hubserver mit dem Dienst verbunden wurde. Wenn alle Ihre Hub-Server aufgrund einer Netzwerkunterbrechung oder eines Serverneustarts getrennt werden, erhalten Ihre Clientverbindungen eine Fehlermeldung, die Ihnen mitteilt, dass kein Server verbunden ist. Sie sind dafür verantwortlich, dass immer mindestens ein Hubserver mit SignalR Service verbunden ist. Beispielsweise können Sie Ihre Anwendung mit mehreren Hubservern entwerfen und dann sicherstellen, dass sie nicht gleichzeitig offline geschaltet werden.
Dieses Standardroutingmodell bedeutet auch, dass die zu einem Hubserver gerouteten Verbindungen getrennt werden, wenn dieser offline geht. Sie sollten davon ausgehen, dass Verbindungen unterbrochen werden, wenn Ihr Hubserver für die Wartung offline geschaltet wird, und dass Sie anschließend eine erneute Verbindung herstellen müssen, um die Auswirkungen auf Ihre Anwendung zu minimieren.
Hinweis
Im Standardmodus können Sie auch die REST-API, das Verwaltungs-SDK und Funktionsbindungen verwenden, um Nachrichten direkt an einen Client zu senden, wenn Sie den Hubserver nicht verwenden möchten. Im Standardmodus werden Clientverbindungen jedoch weiterhin von den Hubservern verarbeitet, und Upstream-Endpunkte funktionieren in diesem Modus nicht.
Serverloser Modus
Im Gegensatz zum Standardmodus erfordert der serverlose Modus keine Ausführung eines Hubservers, weshalb dieser Modus als „serverlos“ bezeichnet wird. SignalR Service ist für die Verwaltung der Clientverbindungen verantwortlich. Es gibt keine Garantie für eine feste Verbindung (Connection Stickiness), und HTTP-Anforderungen sind eventuell weniger effizient als WebSockets-Verbindungen.
Der serverlose Modus arbeitet mit Azure Functions zusammen, um Echtzeitnachrichtenfunktionen bereitzustellen. Clients arbeiten mit SignalR Service-Bindungen für Azure Functions (sogenannte Funktionsbindungen), um Nachrichten als Ausgabebindung zu senden.
Da keine Serververbindung besteht, wird beim Versuch, ein Server-SDK zum Herstellen einer Serververbindung zu verwenden, ein Fehler angezeigt. SignalR Service weist im serverlosen Modus Serververbindungsversuche ab.
Im serverlosen Modus gibt es keine feste Verbindung (Connection Stickiness), aber Sie können weiterhin über eine serverseitige Anwendung Pushnachrichten an Clients senden. Im serverlosen Modus gibt es zwei Möglichkeiten zum Senden von Pushnachrichten an Clients:
- Verwenden von REST-APIs für ein einmaliges Sendeereignis, oder
- Verwenden einer WebSocket-Verbindung, damit Sie mehrere Nachrichten effizienter senden können. Diese WebSocket-Verbindung unterscheidet sich von einer Serververbindung.
Hinweis
Sowohl REST-API als auch WebSockets werden im Verwaltungs-SDK von SignalR Service unterstützt. Wenn Sie eine andere Sprache als .NET verwenden, können Sie die REST-APIs auch manuell aufrufen. Nutzen Sie dazu diese Spezifikation.
Es ist auch möglich, dass Ihre Serveranwendung Nachrichten und Verbindungsereignisse von Clients empfängt. SignalR Service sendet Nachrichten und Verbindungsereignisse mithilfe von Webhooks an vorkonfigurierte Endpunkte (sogenannte Upstream-Endpunkte). Upstream-Endpunkte können nur im serverlosen Modus konfiguriert werden. Weitere Informationen finden Sie unter Upstream-Endpunkte.
Im folgenden Diagramm ist die Funktionsweise des serverlosen Modus dargestellt.
Klassischer Modus
Hinweis
Der klassische Modus dient hauptsächlich für die Abwärtskompatibilität von Anwendungen, die vor der Einführung des Standardmodus und des serverlosen Modus erstellt wurden. Verwenden Sie den klassischen Modus nur als allerletztes Mittel. Wählen Sie für neue Anwendungen anhand Ihres Szenarios den Standardmodus oder den serverlosen Modus aus. Sie sollten die Neugestaltung vorhandener Anwendungen in Betracht ziehen, um auf den klassischen Modus verzichten zu können.
Der klassische Modus ist ein Mix aus Standardmodus und serverlosem Modus. Im klassischen Modus wird der Verbindungsmodus danach bestimmt, ob beim Herstellen einer Clientverbindung ein Hubserver verbunden ist. Bei einem vorhandenen Hubserver wird die Clientverbindung an einen Hubserver geroutet. Wenn kein Hubserver verfügbar ist, wird die Clientverbindung in einem eingeschränkten serverlosen Modus hergestellt, in dem Client-zu-Server-Nachrichten nicht an einen Hubserver übermittelt werden können. Serverlose Verbindungen im klassischen Modus unterstützen einige Features wie Upstream-Endpunkte nicht.
Wenn alle Hubserver aus irgendeinem Grund offline sind, werden Verbindungen im serverlosen Modus hergestellt. Sie sind dafür verantwortlich sicherzustellen, dass immer mindestens ein Hubserver verfügbar ist.
Auswählen des richtigen Dienstmodus
Sie sollten nun die Unterschiede zwischen den Dienstmodi verstehen und wissen, wie Sie sich für einen Dienstmodus entscheiden. Wie bereits erwähnt, wird der klassische Modus für neue oder vorhandene Anwendungen nicht empfohlen. Im Folgenden finden Sie einige Tipps, die Ihnen bei der richtigen Auswahl des Dienstmodus und beim Umstieg vom klassischen Modus für vorhandene Anwendungen helfen.
Wählen Sie den Standardmodus aus, wenn Sie bereits mit der Funktionsweise der SignalR-Bibliothek vertraut sind und von selbstgehostetem SignalR zu Azure SignalR Service wechseln möchten. Der Standardmodus funktioniert in gleicher Weise wie selbstgehostetes SignalR, und Sie können dasselbe Programmiermodell in der SignalR-Bibliothek verwenden. SignalR Service fungiert als Proxy zwischen Clients und Hubservern.
Wählen Sie den serverlosen Modus aus, wenn Sie eine neue Anwendung erstellen und keine Hubserver und Serververbindungen verwalten möchten. Der serverlose Modus arbeitet mit Azure Functions zusammen, sodass Sie keine Server verwalten müssen. Sie können weiterhin die Vollduplexkommunikation mit der REST-API, dem Verwaltungs-SDK oder Funktionsbindung und Upstream-Endpunkt nutzen, aber das Programmiermodell ist anders als bei der SignalR-Bibliothek.
Wählen Sie den Standardmodus aus, wenn Sie sowohl Hubserver für Clientverbindungen als auch eine Back-End-Anwendung für direkte Pushnachrichten an Clients nutzen. Der Hauptunterschied zwischen Standardmodus und serverlosem Modus ist durch die Verfügbarkeit von Hubservern und der Art der Weiterleitung von Clientverbindungen gekennzeichnet. REST-API/Verwaltungs-SDK/Funktionsbindung können in beiden Modi verwendet werden.
Ziehen Sie in Erwägung, Anwendungsfälle in mehrere SignalR Service-Instanzen aufzuteilen, wobei der Dienstmodus je nach Verwendung eingestellt wird, wenn Sie wirklich über ein gemischtes Szenario verfügen. Wenn Sie z. B. zwei verschiedene Hubs auf derselben SignalR-Ressource haben, ist das ein Beispiel für ein gemischtes Szenario, das den klassischen Modus erfordert. Ein Hub wird als herkömmlicher SignalR-Hub verwendet, und der andere Hub wird mit Azure Functions verwendet. In diesem Beispiel sollte eine Aufteilung in zwei Ressourcen erfolgen: eine Instanz im Standardmodus und eine im serverlosen Modus.
Nächste Schritte
In den folgenden Artikeln finden Sie weitere Informationen zur Verwendung von Standardmodus und serverlosem Modus.