Dela via

Använda Azure SignalR Service

  • Artikel

Den här artikeln visar hur du använder SDK på appserversidan för att ansluta till SignalR Service när du använder SignalR på appservern.

Viktigt!

Råa anslutningssträng visas endast i den här artikeln i demonstrationssyfte.

En anslutningssträng innehåller den auktoriseringsinformation som krävs för att ditt program ska få åtkomst till Azure SignalR Service. Åtkomstnyckeln i anslutningssträng liknar ett rotlösenord för din tjänst. Skydda alltid dina åtkomstnycklar i produktionsmiljöer. Använd Azure Key Vault för att hantera och rotera dina nycklar på ett säkert sätt och skydda dina anslutningssträng med hjälp av Microsoft Entra-ID och auktorisera åtkomst med Microsoft Entra-ID.

Undvik att distribuera åtkomstnycklar till andra användare, hårdkoda dem eller spara dem var som helst i oformaterad text som är tillgänglig för andra. Rotera dina nycklar om du tror att de har komprometterats.

Skapa en Azure SignalR Service-instans

Följ snabbstart: Använd en ARM-mall för att distribuera Azure SignalR för att skapa en SignalR-tjänstinstans.

För ASP.NET Core SignalR

Installera SDK:n

Kör kommandot för att installera SignalR Service SDK i ditt ASP.NET Core-projekt.

dotnet add package Microsoft.Azure.SignalR

I klassen Startup använder du SignalR Service SDK som följande kodfragment.

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

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

Konfigurera anslutningssträng

Råa anslutningssträng visas endast i den här artikeln i demonstrationssyfte. Skydda alltid dina åtkomstnycklar i produktionsmiljöer. Använd Azure Key Vault för att hantera och rotera dina nycklar på ett säkert sätt och skydda dina anslutningssträng med hjälp av Microsoft Entra-ID och auktorisera åtkomst med Microsoft Entra-ID.

Det finns två metoder för att konfigurera SignalR-tjänstens anslutningssträng i ditt program.

  • Ange en miljövariabel med namn Azure:SignalR:ConnectionString eller Azure__SignalR__ConnectionString.

    • I Azure App Service placerar du den i programinställningar.

  • Skicka anslutningssträng som en parameter för AddAzureSignalR().

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

    eller

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

Konfigurera alternativ

Det finns några alternativ som du kan anpassa när du använder Azure SignalR Service SDK.

ConnectionString

  • Standardvärdet är Azure:SignalR:ConnectionString filen eller appSetting web.config .connectionString
  • Det kan konfigureras om, men kontrollera att värdet INTE är hårdkodat.

InitialHubServerConnectionCount

  • Standardvärdet är 5.
  • Det här alternativet styr det första antalet anslutningar per hubb mellan programservern och Azure SignalR Service. Behåll det vanligtvis eftersom standardvärdet räcker. Under körningen kan SDK starta nya serveranslutningar för prestandajustering eller belastningsutjämning. När du har ett stort antal klienter kan du ge det ett större antal för bättre dataflöde. Om du till exempel har totalt 100 000 klienter kan antalet anslutningar ökas till 10 eller 15.

MaxHubServerConnectionCount

  • Standardvärdet är null.
  • Det här alternativet styr det maximala antalet anslutningar som tillåts per hubb mellan programservern och Azure SignalR Service. Under körningen kan SDK starta nya serveranslutningar för prestandajustering eller belastningsutjämning. Som standard startar en ny serveranslutning när det behövs. När det maximala antalet tillåtna serveranslutningar har konfigurerats startar inte SDK:n nya anslutningar när antalet serveranslutningar når gränsen.

ApplicationName

  • Standardvärdet är null.
  • Det här alternativet kan vara användbart när du vill dela samma Azure SignalR-instans för olika appservrar som innehåller samma hubbnamn. Om de inte har angetts anses alla anslutna appservrar vara instanser av samma program.

ClaimsProvider

  • Standardvärdet är null.
  • Det här alternativet styr vilka anspråk du vill associera med klientanslutningen. Den används när Service SDK genererar åtkomsttoken för klienten i klientens förhandlingsbegäran. Som standard är alla anspråk från HttpContext.User den förhandlade begäran reserverade. De kan nås på Hub.Context.User.
  • Normalt bör du lämna det här alternativet som det är. Se till att du förstår vad som händer innan du anpassar det.

AccessTokenLifetime

  • Standardvärdet är 1 hour.
  • Det här alternativet styr den giltiga livslängden för åtkomsttoken som Service SDK genererar för varje klient. Åtkomsttoken returneras i svaret på klientens förhandlingsbegäran.
  • När ServerSentEvent eller LongPolling används som transport stängs klientanslutningen på grund av autentiseringsfel efter den förfallna tiden. Du kan öka det här värdet för att undvika att klienten kopplas från.

AccessTokenAlgorithm

  • Standardvärdet är HS256
  • Det här alternativet ger val av SecurityAlgorithms när du genererar åtkomsttoken. Nu stöds valfria värden och HS256 HS512. Observera att är HS512 säkrare men den genererade token är jämförelsevis längre än den som använder HS256.

ServerStickyMode

  • Standardvärdet är Disabled.
  • Det här alternativet anger läget för server sticky. När klienten dirigeras till den server som den först förhandlar med, kallar vi den server klibbig.
  • I distribuerade scenarier kan det finnas flera appservrar anslutna till en Azure SignalR-instans. Som interna klientanslutningar förklarar förhandlar klienten först med appservern och omdirigerar sedan till Azure SignalR för att upprätta den beständiga anslutningen. Azure SignalR hittar sedan en appserver som betjänar klienten, som transportdata mellan klient och server förklarar.
    • När Disableddirigerar klienten till en slumpmässig appserver. I allmänhet har appservrar balanserade klientanslutningar med det här läget. Om dina scenarier sänds eller grupp skickas använder du det här standardalternativet är tillräckligt.
    • När Preferredförsöker Azure SignalR hitta den appserver som klienten först förhandlar med på ett sätt som ingen annan kostnad eller global routning behövs. Den här kan vara användbar när ditt scenario skickas till anslutningen*. Skicka till anslutning kan ha bättre prestanda och kortare svarstid när avsändaren och mottagaren dirigeras till samma appserver.
    • När Requiredförsöker Azure SignalR alltid hitta den appserver som klienten först förhandlar med. Det här alternativet kan vara användbart när en del klientkontext hämtas från negotiate steg och lagras i minnet och sedan används i Hubs. Det här alternativet kan dock ha prestandarestitutioner eftersom det kräver att Azure SignalR vidtar andra åtgärder för att hitta den här appservern globalt och för att fortsätta dirigera trafik globalt mellan klient och server.

GracefulShutdown

GracefulShutdown.Mode
  • Standardvärdet är Off
  • Det här alternativet anger beteendet när appservern tar emot en SIGINT (CTRL + C).
  • När inställningen är inställd på , i stället för att WaitForClientsClosestoppa servern omedelbart, tar vi bort den från Azure SignalR Service för att förhindra att nya klientanslutningar tilldelas till den här servern.
  • När det är inställt MigrateClientspå försöker vi dessutom migrera klientanslutningar till en annan giltig server. Migreringen utlöses först när ett meddelande har levererats.
    • OnConnected och OnDisconnected utlöses när anslutningar migreras in/ut.
    • IConnectionMigrationFeature kan hjälpa dig att identifiera om anslutningen migreras in/ut.
    • Se våra exempelkoder för detaljerad användning.
GracefulShutdown.Timeout
  • Standardvärdet är 30 seconds
  • Det här alternativet anger den längsta tiden i väntan på att klienter ska stängas/migreras.

ServiceScaleTimeout

  • Standardvärdet är 5 minutes
  • Det här alternativet anger den längsta tiden i väntan på tjänstslutpunkter för dynamisk skalning, som ska påverka onlineklienter minst. Normalt kan den dynamiska skalningen mellan en enskild appserver och en tjänstslutpunkt avslutas på några sekunder, samtidigt som du överväger om du har flera appservrar och flera tjänstslutpunkter med nätverks jitter och vill säkerställa klientstabilitet, kan du konfigurera det här värdet i enlighet med detta.

MaxPollIntervalInSeconds

  • Standardvärdet är 5
  • Det här alternativet definierar det maximala avsökningsintervall som tillåts för LongPolling anslutningar i Azure SignalR Service. Om nästa avsökningsbegäran inte kommer in i MaxPollIntervalInSecondsrensar Azure SignalR Service klientanslutningen.
  • Värdet är begränsat till [1, 300].

TransportTypeDetector

  • Standardvärde: Alla transporter är aktiverade.
  • Det här alternativet definierar en funktion för att anpassa de transporter som klienter kan använda för att skicka HTTP-begäranden.
  • Använd de här alternativen i stället HttpConnectionDispatcherOptions.Transports för att konfigurera transporter.

AllowStatefulReconnects

  • Standardvärdet är null
  • Det här alternativet aktiverar eller inaktiverar tillståndskänsliga återanslutningar för alla hubbar.
  • Om nullläser SDK hubbinställningarna.
  • Om trueaktiverar Azure SignalR Service tillståndskänsliga återanslutningar i alla deklarerade hubbar. Och klienter behöver aktivera tillståndskänsliga återanslutningar på klientsidan.
  • Om falseinaktiverar Azure SignalR Service tillståndskänsliga återanslutningar i alla deklarerade hubbar.

Exempel

Du kan konfigurera ovanstående alternativ, till exempel följande exempelkod.

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;
            });

För den äldre ASP.NET SignalR

Kommentar

Om det är första gången du provar SignalR rekommenderar vi att du använder ASP.NET Core SignalR, det är enklare, mer tillförlitligt och enklare att använda.

Installera SDK:n

Installera SignalR Service SDK i ditt ASP.NET projekt med Package Manager Console:

Install-Package Microsoft.Azure.SignalR.AspNet

I klassen Startup använder du SignalR Service SDK som följande kodfragment och ersätter MapSignalR() till MapAzureSignalR({your_applicationName}). Ersätt {YourApplicationName} med namnet på ditt program, det här är det unika namnet för att särskilja det här programmet med dina andra program. Du kan använda this.GetType().FullName som värde.

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

Konfigurera anslutningssträng

Ange anslutningssträng i web.config filen till avsnittetconnectionStrings:

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

Konfigurera alternativ

Det finns några alternativ som du kan anpassa när du använder Azure SignalR Service SDK.

ConnectionString

  • Standardvärdet är Azure:SignalR:ConnectionString filen eller appSetting web.config .connectionString
  • Det kan konfigureras om, men kontrollera att värdet INTE är hårdkodat.

InitialHubServerConnectionCount

  • Standardvärdet är 5.
  • Det här alternativet styr det första antalet anslutningar per hubb mellan programservern och Azure SignalR Service. Behåll det vanligtvis eftersom standardvärdet räcker. Under körningen kan SDK starta nya serveranslutningar för prestandajustering eller belastningsutjämning. När du har ett stort antal klienter kan du ge det ett större antal för bättre dataflöde. Om du till exempel har totalt 100 000 klienter kan antalet anslutningar ökas till 10 eller 15.

MaxHubServerConnectionCount

  • Standardvärdet är null.
  • Det här alternativet styr det maximala antalet anslutningar som tillåts per hubb mellan programservern och Azure SignalR Service. Under körningen kan SDK starta nya serveranslutningar för prestandajustering eller belastningsutjämning. Som standard startar en ny serveranslutning när det behövs. När det maximala antalet tillåtna serveranslutningar har konfigurerats startar inte SDK:n nya anslutningar när antalet serveranslutningar når gränsen.

ApplicationName

  • Standardvärdet är null.
  • Det här alternativet kan vara användbart när du vill dela samma Azure SignalR-instans för olika appservrar som innehåller samma hubbnamn. Om de inte har angetts anses alla anslutna appservrar vara instanser av samma program.

ClaimProvider

  • Standardvärdet är null.
  • Det här alternativet styr vilka anspråk du vill associera med klientanslutningen. Den används när Service SDK genererar åtkomsttoken för klienten i klientens förhandlingsbegäran. Som standard är alla anspråk från IOwinContext.Authentication.User den förhandlade begäran reserverade.
  • Normalt bör du lämna det här alternativet som det är. Se till att du förstår vad som händer innan du anpassar det.

AccessTokenLifetime

  • Standardvärdet är 1 hour.
  • Det här alternativet styr den giltiga livslängden för åtkomsttoken, som Service SDK genererar för varje klient. Åtkomsttoken returneras i svaret på klientens förhandlingsbegäran.
  • När ServerSentEvent eller LongPolling används som transport stängs klientanslutningen på grund av autentiseringsfel efter den förfallna tiden. Du kan öka det här värdet för att undvika att klienten kopplas från.

AccessTokenAlgorithm

  • Standardvärdet är HS256
  • Det här alternativet ger val av SecurityAlgorithms när du genererar åtkomsttoken. Nu stöds valfria värden och HS256 HS512. Observera att är HS512 säkrare men den genererade token är jämförelsevis längre än den som använder HS256.

ServerStickyMode

  • Standardvärdet är Disabled.
  • Det här alternativet anger läget för server sticky. När klienten dirigeras till den server som den först förhandlar med, kallar vi den server klibbig.
  • I distribuerade scenarier kan det finnas flera appservrar anslutna till en Azure SignalR-instans. Som interna klientanslutningar förklarar förhandlar klienten först med appservern och omdirigerar sedan till Azure SignalR för att upprätta den beständiga anslutningen. Azure SignalR hittar sedan en appserver som betjänar klienten, som transportdata mellan klient och server förklarar.
    • När Disableddirigerar klienten till en slumpmässig appserver. I allmänhet har appservrar balanserade klientanslutningar med det här läget. Om dina scenarier sänds eller grupp skickas använder du det här standardalternativet är tillräckligt.
    • När Preferredförsöker Azure SignalR hitta den appserver som klienten först förhandlar med på ett sätt som ingen annan kostnad eller global routning behövs. Den här kan vara användbar när ditt scenario skickas till anslutningen*. Skicka till anslutning kan ha bättre prestanda och kortare svarstid när avsändaren och mottagaren dirigeras till samma appserver.
    • När Requiredförsöker Azure SignalR alltid hitta den appserver som klienten först förhandlar med. Det här alternativet kan vara användbart när en del klientkontext hämtas från negotiate steg och lagras i minnet och sedan används i Hubs. Det här alternativet kan dock ha prestandarestitutioner eftersom det kräver att Azure SignalR vidtar andra åtgärder för att hitta den här appservern globalt och för att fortsätta dirigera trafik globalt mellan klient och server.

MaxPollIntervalInSeconds

  • Standardvärdet är 5
  • Det här alternativet definierar den maximala inaktiva tid som tillåts för inaktiva anslutningar i Azure SignalR Service. I ASP.NET SignalR gäller det för lång avsökningstransporttyp eller återanslutning. Om nästa /reconnect begäran eller /poll begäran inte kommer in i MaxPollIntervalInSecondsrensar Azure SignalR Service klientanslutningen.
  • Värdet är begränsat till [1, 300].

Exempel

Du kan konfigurera ovanstående alternativ, till exempel följande exempelkod.

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;
}));

Skala ut programserver

Med Azure SignalR Service avlastas beständiga anslutningar från programservern så att du kan fokusera på att implementera din affärslogik i hubbklasser. Men du behöver fortfarande skala ut programservrar för bättre prestanda vid hantering av massiva klientanslutningar. Nedan följer några tips för att skala ut programservrar.

  • Flera programservrar kan ansluta till samma Azure SignalR Service-instans.
  • Om du vill dela samma Azure SignalR-instans för olika program som innehåller samma hubbnamn anger du dem med ett annat ApplicationName-alternativ . Om de inte har angetts anses alla anslutna appservrar vara instanser av samma program.
  • Så länge alternativet ApplicationName och namnet på hubbklassen är detsamma grupperas anslutningar från olika programservrar i samma hubb.
  • Varje klientanslutning skapas bara på en av programservrarna och meddelanden från den klienten skickas endast till samma programserver. Om du vill komma åt klientinformation globalt (från alla programservrar) måste du använda centraliserad lagring för att spara klientinformation från alla programservrar.

Nästa steg

I den här artikeln får du lära dig hur du använder SignalR Service i dina program. Läs följande artiklar om du vill veta mer om SignalR Service.

Azure SignalR Service – internt

Snabbstart: Skapa ett chattrum med hjälp av SignalR Service