Freigeben über

Verwenden von Azure SignalR Service

  • Artikel

In diesem Artikel wird gezeigt, wie Sie das SDK auf der App-Serverseite verwenden, um eine Verbindung mit SignalR Service herzustellen, wenn Sie SignalR auf Ihrem App-Server verwenden.

Erstellen einer Instanz des Azure SignalR-Diensts

Informationen zum Erstellen einer SignalR Service-Instanz finden Sie unter Schnellstart: Verwenden einer ARM-Vorlage zum Bereitstellen von Azure SignalR Service.

ASP.NET Core SignalR

Installieren des SDKs

Führen Sie den Befehl aus, um das SignalR Service-SDK in Ihrem ASP.NET Core-Projekt zu installieren.

dotnet add package Microsoft.Azure.SignalR

Verwenden Sie in Ihrer Startup-Klasse das SignalR Service-SDK als folgenden Codeschnipsel.

public void ConfigureServices(IServiceCollection services)
{
    services.AddSignalR()
            .AddAzureSignalR();
}

public void Configure(IApplicationBuilder app)
{
    app.UseEndpoints(routes =>
    {
        routes.MapHub<YourHubClass>("/path_for_your_hub");
    });
}

Konfigurieren der Verbindungszeichenfolge

Es gibt zwei Ansätze zum Konfigurieren der Verbindungszeichenfolge von SignalR Service in Ihrer Anwendung.

  • Legen Sie eine Umgebungsvariable mit dem Namen Azure:SignalR:ConnectionString oder Azure__SignalR__ConnectionString fest.

    • Fügen Sie sie in Azure App Service in den Anwendungseinstellungen ein.

  • Übergeben Sie die Verbindungszeichenfolge als Parameter von AddAzureSignalR().

    services.AddSignalR()
        .AddAzureSignalR("<replace with your connection string>");

    oder

    services.AddSignalR()
        .AddAzureSignalR(options => options.ConnectionString = "<replace with your connection string>");

Konfigurieren von Optionen

Es gibt einige Optionen, die Sie bei der Verwendung des Azure SignalR Service-SDK anpassen können.

ConnectionString

  • Der Standardwert ist Azure:SignalR:ConnectionStringconnectionString oder appSetting in der Datei web.config.
  • Er kann neu konfiguriert werden, stellen Sie jedoch sicher, dass der Wert NICHT hartcodiert ist.

InitialHubServerConnectionCount

  • Der Standardwert ist 5.
  • Diese Option steuert die anfängliche Anzahl der Verbindungen pro Hub zwischen Anwendungsserver und Azure SignalR Service. In der Regel ist der Standardwert ausreichend, und Sie können ihn übernehmen. Während der Laufzeit startet das SDK möglicherweise neue Serververbindungen zur Leistungsoptimierung oder zum Lastenausgleich. Wenn Sie über eine große Anzahl von Clients verfügen, können Sie eine größere Zahl für einen besseren Durchsatz zuweisen. Wenn Sie beispielsweise insgesamt über 100.000 Clients verfügen, kann die Verbindungsanzahl auf 10 oder 15 erhöht werden.

MaxHubServerConnectionCount

  • Der Standardwert ist null.
  • Diese Option steuert die maximale Anzahl der Verbindungen pro Hub zwischen Anwendungsserver und Azure SignalR Service. Während der Laufzeit startet das SDK möglicherweise neue Serververbindungen zur Leistungsoptimierung oder zum Lastenausgleich. Standardmäßig wird bei Bedarf eine neue Serververbindung gestartet. Wenn die maximal zulässige Anzahl von Serververbindungen konfiguriert ist, startet das SDK keine neuen Verbindungen, wenn die Serververbindungsanzahl den Grenzwert erreicht.

ApplicationName

  • Der Standardwert ist null.
  • Diese Option kann nützlich sein, wenn Sie dieselbe Azure SignalR-Instanz für verschiedene App-Server mit denselben Hubnamen verwenden möchten. Wenn dies nicht festgelegt ist, werden alle verbundenen App-Server als Instanzen derselben Anwendung betrachtet.

ClaimsProvider

  • Der Standardwert ist null.
  • Diese Option steuert, welche Ansprüche Sie der Clientverbindung zuordnen möchten. Sie wird verwendet, wenn das Service-SDK Zugriffstoken für den Client in der Aushandlungsanforderung des Clients generiert. Standardmäßig sind alle Ansprüche von HttpContext.User der ausgehandelten Anforderung reserviert. Auf sie kann über Hub.Context.User zugegriffen werden.
  • Normalerweise sollten Sie diese Option ohne Änderung übernehmen. Stellen Sie sicher, dass Sie sich der Auswirkungen bewusst sind, bevor Sie sie anpassen.

AccessTokenLifetime

  • Der Standardwert ist 1 hour.
  • Diese Option steuert die gültige Lebensdauer des Zugriffstokens, das das Service-SDK für jeden Client generiert. Das Zugriffstoken wird in der Antwort auf die Aushandlungsanforderung des Clients zurückgegeben.
  • Wenn ServerSentEvent oder LongPolling als Transport verwendet wird, wird die Clientverbindung aufgrund eines Authentifizierungsfehlers nach der abgelaufenen Zeit geschlossen. Sie können diesen Wert erhöhen, um das Trennen der Clientverbindung zu vermeiden.

AccessTokenAlgorithm

  • Standardwert: HS256
  • Diese Option bietet die Wahl zwischen verschiedenen SecurityAlgorithms beim Generieren von Zugriffstoken. Jetzt sind unterstützte optionale Werte HS256 und HS512. Beachten Sie, dass HS512 sicherer ist, aber das generierte Token ist vergleichsweise länger als bei der Verwendung von HS256.

ServerStickyMode

  • Der Standardwert ist Disabled.
  • Diese Option gibt den Modus für die Serverbindung an. Wenn der Client an den Server weitergeleitet wird, mit dem er zuerst verhandelt, wird er als servergebunden bezeichnet.
  • In verteilten Szenarien können mehrere App-Server mit einer Azure SignalR-Instanz verbunden sein. Wie in den Informationen zu Clientverbindungen erläutert, verhandelt der Client zuerst mit dem App-Server und wird dann an Azure SignalR umgeleitet, um die dauerhafte Verbindung herzustellen. Azure SignalR findet dann einen App-Server für den Client, wie im Abschnitt zum Transport von Daten zwischen Client und Server erläutert.
    • Bei Disabled leitet der Client an einen zufälligen App-Server weiter. Im Allgemeinen verfügen App-Server mit diesem Modus über ausgewogene Clientverbindungen. Wenn Ihre Szenarien Übertragen oder an eine Gruppe senden umfassen, ist diese Standardoption ausreichend.
    • Bei Preferred versucht Azure SignalR, den App-Server zu finden, mit dem der Client zuerst verhandelt, sodass keine anderen Kosten oder ein globales Routing erforderlich sind. Dies kann nützlich sein, wenn Ihr Szenario „An Verbindung senden“ ist. An Verbindung senden kann eine bessere Leistung und geringere Latenz bieten, wenn der Absender und der Empfänger an denselben App-Server weitergeleitet werden.
    • Bei Required versucht Azure SignalR immer, den App-Server zu finden, mit dem der Client zuerst verhandelt. Diese Option kann nützlich sein, wenn Clientkontext aus dem Schritt negotiate abgerufen und im Arbeitsspeicher gespeichert wird, um ihn in Hubs zu verwenden. Diese Option kann jedoch Leistungseinbußen zur Folge haben, da Azure SignalR andere Maßnahmen ergreifen muss, um diesen bestimmten App-Server global zu finden und den Datenverkehr zwischen Client und Server global weiterzuleiten.

GracefulShutdown

GracefulShutdown.Mode
  • Standardwert: Off
  • Diese Option gibt das Verhalten an, nachdem der App-Server eine SIGINT (STRG+C) empfängt.
  • Wenn diese Einstellung auf WaitForClientsClose festgelegt ist, wird der Server nicht sofort beendet, sondern aus Azure SignalR Service entfernt, um zu verhindern, dass diesem Server neue Clientverbindungen zugewiesen werden.
  • Wenn dieser Wert auf MigrateClients festgelegt ist, versuchen wir außerdem, Clientverbindungen zu einem anderen gültigen Server zu migrieren. Die Migration wird erst ausgelöst, nachdem eine Nachricht zugestellt wurde.
    • OnConnected und OnDisconnected werden ausgelöst, wenn Verbindungen eingehend oder ausgehend migriert werden.
    • Mit IConnectionMigrationFeature können Sie ermitteln, ob die Verbindung eingehend oder ausgehend migriert wird.
    • Detaillierte Informationen zur Verwendung finden Sie in unseren Beispielcodes.
GracefulShutdown.Timeout
  • Standardwert: 30 seconds
  • Diese Option gibt die längste Wartezeit an, bis Clients geschlossen/migriert werden.

ServiceScaleTimeout

  • Standardwert: 5 minutes
  • Diese Option gibt die längste Wartezeit für die dynamische Skalierung von Dienstendpunkten an, um die Auswirkungen auf Onlineclients zu minimieren. Normalerweise kann die dynamische Skalierung zwischen einem einzelnen App-Server und einem Dienstendpunkt in Sekunden abgeschlossen werden. Wenn Sie allerdings über mehrere App-Server und mehrere Dienstendpunkte mit Netzwerk-Jitter verfügen und die Clientstabilität sicherstellen möchten, können Sie diesen Wert entsprechend konfigurieren.

MaxPollIntervalInSeconds

  • Standardwert: 5
  • Diese Option definiert das maximal zulässige Abfrageintervall für LongPolling-Verbindungen in Azure SignalR Service. Wenn die nächste Abfrageanforderung nicht innerhalb von MaxPollIntervalInSeconds erfolgt, bereinigt Azure SignalR Service die Clientverbindung.
  • Der Wert ist auf [1, 300] beschränkt.

TransportTypeDetector

  • Standardwert: Alle Transporte sind aktiviert.
  • Diese Option definiert eine Funktion zum Anpassen der Transporte, die Clients zum Senden von HTTP-Anforderungen verwenden können.
  • Verwenden Sie diese Optionen anstelle von HttpConnectionDispatcherOptions.Transports, um Transporte zu konfigurieren.

Beispiel

Sie können die oben aufgeführten Optionen wie den folgenden Beispielcode konfigurieren.

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                options.InitialHubServerConnectionCount = 10;
                options.AccessTokenLifetime = TimeSpan.FromDays(1);
                options.ClaimsProvider = context => context.User.Claims;

                options.GracefulShutdown.Mode = GracefulShutdownMode.WaitForClientsClose;
                options.GracefulShutdown.Timeout = TimeSpan.FromSeconds(10);
                options.TransportTypeDetector = httpContext => AspNetCore.Http.Connections.HttpTransportType.WebSockets | AspNetCore.Http.Connections.HttpTransportType.LongPolling;
            });

Legacy-ASP.NET SignalR

Hinweis

Wenn Sie zum ersten Mal SignalR ausprobieren, empfehlen wir Ihnen, ASP.NET Core SignalRzu verwenden, da dies einfacher, zuverlässiger und benutzerfreundlicher ist.

Installieren des SDKs

Installieren Sie das SignalR Service-SDK in Ihrem ASP.NET-Projekt mit der Paket-Manager-Konsole:

Install-Package Microsoft.Azure.SignalR.AspNet

Verwenden Sie in Ihrer Startup-Klasse das SignalR Service-SDK als folgenden Codeschnipsel, und ersetzen Sie MapSignalR() durch MapAzureSignalR({your_applicationName}). Ersetzen Sie {YourApplicationName} durch den Namen Ihrer Anwendung. Dies ist der eindeutige Name, um diese Anwendung von Ihren anderen Anwendungen zu unterscheiden. Sie können this.GetType().FullName als Wert verwenden.

public void Configuration(IAppBuilder app)
{
    app.MapAzureSignalR(this.GetType().FullName);
}

Konfigurieren der Verbindungszeichenfolge

Legen Sie die Verbindungszeichenfolge in der web.config-Datei fest (Abschnitt connectionStrings):

<configuration>
    <connectionStrings>
        <add name="Azure:SignalR:ConnectionString" connectionString="Endpoint=...;AccessKey=..."/>
    </connectionStrings>
    ...
</configuration>

Konfigurieren von Optionen

Es gibt einige Optionen, die Sie bei der Verwendung des Azure SignalR Service-SDK anpassen können.

ConnectionString

  • Der Standardwert ist Azure:SignalR:ConnectionStringconnectionString oder appSetting in der Datei web.config.
  • Er kann neu konfiguriert werden, stellen Sie jedoch sicher, dass der Wert NICHT hartcodiert ist.

InitialHubServerConnectionCount

  • Der Standardwert ist 5.
  • Diese Option steuert die anfängliche Anzahl der Verbindungen pro Hub zwischen Anwendungsserver und Azure SignalR Service. In der Regel ist der Standardwert ausreichend, und Sie können ihn übernehmen. Während der Laufzeit startet das SDK möglicherweise neue Serververbindungen zur Leistungsoptimierung oder zum Lastenausgleich. Wenn Sie über eine große Anzahl von Clients verfügen, können Sie eine größere Zahl für einen besseren Durchsatz zuweisen. Wenn Sie beispielsweise insgesamt über 100.000 Clients verfügen, kann die Verbindungsanzahl auf 10 oder 15 erhöht werden.

MaxHubServerConnectionCount

  • Der Standardwert ist null.
  • Diese Option steuert die maximale Anzahl der Verbindungen pro Hub zwischen Anwendungsserver und Azure SignalR Service. Während der Laufzeit startet das SDK möglicherweise neue Serververbindungen zur Leistungsoptimierung oder zum Lastenausgleich. Standardmäßig wird bei Bedarf eine neue Serververbindung gestartet. Wenn die maximal zulässige Anzahl von Serververbindungen konfiguriert ist, startet das SDK keine neuen Verbindungen, wenn die Serververbindungsanzahl den Grenzwert erreicht.

ApplicationName

  • Der Standardwert ist null.
  • Diese Option kann nützlich sein, wenn Sie dieselbe Azure SignalR-Instanz für verschiedene App-Server mit denselben Hubnamen verwenden möchten. Wenn dies nicht festgelegt ist, werden alle verbundenen App-Server als Instanzen derselben Anwendung betrachtet.

ClaimProvider

  • Der Standardwert ist null.
  • Diese Option steuert, welche Ansprüche Sie der Clientverbindung zuordnen möchten. Sie wird verwendet, wenn das Service-SDK Zugriffstoken für den Client in der Aushandlungsanforderung des Clients generiert. Standardmäßig sind alle Ansprüche von IOwinContext.Authentication.User der ausgehandelten Anforderung reserviert.
  • Normalerweise sollten Sie diese Option ohne Änderung übernehmen. Stellen Sie sicher, dass Sie sich der Auswirkungen bewusst sind, bevor Sie sie anpassen.

AccessTokenLifetime

  • Der Standardwert ist 1 hour.
  • Diese Option steuert die gültige Lebensdauer des Zugriffstokens, das das Service-SDK für jeden Client generiert. Das Zugriffstoken wird in der Antwort auf die Aushandlungsanforderung des Clients zurückgegeben.
  • Wenn ServerSentEvent oder LongPolling als Transport verwendet wird, wird die Clientverbindung aufgrund eines Authentifizierungsfehlers nach der abgelaufenen Zeit geschlossen. Sie können diesen Wert erhöhen, um das Trennen der Clientverbindung zu vermeiden.

AccessTokenAlgorithm

  • Standardwert: HS256
  • Diese Option bietet die Wahl zwischen verschiedenen SecurityAlgorithms beim Generieren von Zugriffstoken. Jetzt sind unterstützte optionale Werte HS256 und HS512. Beachten Sie, dass HS512 sicherer ist, aber das generierte Token ist vergleichsweise länger als bei der Verwendung von HS256.

ServerStickyMode

  • Der Standardwert ist Disabled.
  • Diese Option gibt den Modus für die Serverbindung an. Wenn der Client an den Server weitergeleitet wird, mit dem er zuerst verhandelt, wird er als servergebunden bezeichnet.
  • In verteilten Szenarien können mehrere App-Server mit einer Azure SignalR-Instanz verbunden sein. Wie in den Informationen zu Clientverbindungen erläutert, verhandelt der Client zuerst mit dem App-Server und wird dann an Azure SignalR umgeleitet, um die dauerhafte Verbindung herzustellen. Azure SignalR findet dann einen App-Server für den Client, wie im Abschnitt zum Transport von Daten zwischen Client und Server erläutert.
    • Bei Disabled leitet der Client an einen zufälligen App-Server weiter. Im Allgemeinen verfügen App-Server mit diesem Modus über ausgewogene Clientverbindungen. Wenn Ihre Szenarien Übertragen oder an eine Gruppe senden umfassen, ist diese Standardoption ausreichend.
    • Bei Preferred versucht Azure SignalR, den App-Server zu finden, mit dem der Client zuerst verhandelt, sodass keine anderen Kosten oder ein globales Routing erforderlich sind. Dies kann nützlich sein, wenn Ihr Szenario „An Verbindung senden“ ist. An Verbindung senden kann eine bessere Leistung und geringere Latenz bieten, wenn der Absender und der Empfänger an denselben App-Server weitergeleitet werden.
    • Bei Required versucht Azure SignalR immer, den App-Server zu finden, mit dem der Client zuerst verhandelt. Diese Option kann nützlich sein, wenn Clientkontext aus dem Schritt negotiate abgerufen und im Arbeitsspeicher gespeichert wird, um ihn in Hubs zu verwenden. Diese Option kann jedoch Leistungseinbußen zur Folge haben, da Azure SignalR andere Maßnahmen ergreifen muss, um diesen bestimmten App-Server global zu finden und den Datenverkehr zwischen Client und Server global weiterzuleiten.

MaxPollIntervalInSeconds

  • Standardwert: 5
  • Diese definiert die maximal zulässige Leerlaufzeit für inaktive Verbindungen in Azure SignalR Service. In ASP.NET SignalR gilt dies für den „Long Polling“-Transporttyp oder die erneute Verbindung. Wenn die nächste /reconnect- oder /poll-Anforderung nicht innerhalb von MaxPollIntervalInSeconds erfolgt, bereinigt Azure SignalR Service die Clientverbindung.
  • Der Wert ist auf [1, 300] beschränkt.

Beispiel

Sie können die oben aufgeführten Optionen wie den folgenden Beispielcode konfigurieren.

app.Map("/signalr",subApp => subApp.RunAzureSignalR(this.GetType().FullName, new HubConfiguration(), options =>
{
    options.InitialHubServerConnectionCount = 1;
    options.AccessTokenLifetime = TimeSpan.FromDays(1);
    options.ClaimProvider = context => context.Authentication?.User.Claims;
}));

Aufskalieren des Anwendungsservers

Bei Azure SignalR Service werden persistente Verbindungen vom Anwendungsserver ausgelagert, sodass Sie sich auf die Implementierung Ihrer Geschäftslogik in Hubklassen konzentrieren können. Sie müssen jedoch weiterhin Anwendungsserver aufskalieren, um eine bessere Leistung bei der Verarbeitung massiver Clientverbindungen zu erzielen. Im Folgenden finden Sie einige Tipps zum Aufskalieren von Anwendungsservern.

  • Mehrere Anwendungsserver können eine Verbindung mit derselben Azure SignalR Service-Instanz herstellen.
  • Wenn Sie dieselbe Azure SignalR-Instanz für verschiedene Anwendungen mit denselben Hubnamen verwenden möchten, legen Sie sie mit unterschiedlichen Werten für die ApplicationName-Option fest. Wenn dies nicht festgelegt ist, werden alle verbundenen App-Server als Instanzen derselben Anwendung betrachtet.
  • Solange die Option ApplicationName und der Name der Hubklasse identisch sind, werden Verbindungen von verschiedenen Anwendungsservern im selben Hub gruppiert.
  • Jede Clientverbindung wird nur auf einem der Anwendungsserver erstellt, und Nachrichten von diesem Client werden nur an diesen Anwendungsserver gesendet. Wenn Sie global auf Clientinformationen zugreifen möchten, (von allen Anwendungsservern), müssen Sie einen zentralen Speicher verwenden, um Clientinformationen von allen Anwendungsservern zu speichern.

Nächste Schritte

In diesem Artikel erfahren Sie, wie Sie SignalR Service in Ihren Anwendungen verwenden. Weitere Informationen zu SignalR Service finden Sie in den folgenden Artikeln.

Ausführliche Informationen zu Azure SignalR Service

Schnellstart: Erstellen eines Chatrooms mit SignalR Service