Udostępnij za pośrednictwem

Korzystanie z usługi Azure SignalR Service

  • Artykuł

W tym artykule pokazano, jak używać zestawu SDK po stronie serwera aplikacji w celu nawiązania połączenia z usługą SignalR Service, gdy używasz usługi SignalR na serwerze aplikacji.

Tworzenie wystąpienia usługi Azure SignalR Service

Postępuj zgodnie z przewodnikiem Szybki start: użyj szablonu usługi ARM, aby wdrożyć usługę Azure SignalR w celu utworzenia wystąpienia usługi SignalR.

Dla ASP.NET Core SignalR

Instalacja zestawu SDK

Uruchom polecenie , aby zainstalować zestaw SDK usługi SignalR Service w projekcie ASP.NET Core.

dotnet add package Microsoft.Azure.SignalR

Startup W klasie użyj zestawu SDK usługi SignalR Service jako poniższego fragmentu kodu.

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

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

Konfigurowanie parametry połączenia

Istnieją dwa podejścia do konfigurowania parametry połączenia usługi SignalR Service w aplikacji.

  • Ustaw zmienną środowiskową o nazwie Azure:SignalR:ConnectionString lub Azure__SignalR__ConnectionString.

    • W usłudze aplikacja systemu Azure umieść ją w ustawieniach aplikacji.

  • Przekaż parametry połączenia jako parametr .AddAzureSignalR()

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

    lub

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

Konfigurowanie opcji

Istnieje kilka opcji , które można dostosować podczas korzystania z zestawu Sdk usługi Azure SignalR Service.

ConnectionString

  • Wartość domyślna Azure:SignalR:ConnectionString connectionString to lub appSetting w web.config pliku .
  • Można ją ponownie skonfigurować, ale upewnij się, że wartość nie jest zakodowana w kodzie twardym.

InitialHubServerConnectionCount

  • Wartość domyślna to 5.
  • Ta opcja steruje początkową liczbą połączeń na koncentrator między serwerem aplikacji i usługą Azure SignalR Service. Zazwyczaj zachowaj ją jako wartość domyślną jest wystarczająca. W czasie wykonywania zestaw SDK może uruchamiać nowe połączenia serwera na potrzeby dostrajania wydajności lub równoważenia obciążenia. Jeśli masz dużą liczbę klientów, możesz nadać jej większą liczbę w celu uzyskania lepszej przepływności. Jeśli na przykład masz łącznie 100 000 klientów, liczbę połączeń można zwiększyć do 10 lub 15.

MaxHubServerConnectionCount

  • Wartość domyślna to null.
  • Ta opcja steruje maksymalną liczbą dozwolonych połączeń na koncentrator między serwerem aplikacji a usługą Azure SignalR Service. W czasie wykonywania zestaw SDK może uruchamiać nowe połączenia serwera na potrzeby dostrajania wydajności lub równoważenia obciążenia. Domyślnie nowe połączenie z serwerem jest uruchamiane zawsze wtedy, gdy jest to konieczne. Po skonfigurowaniu maksymalnej dozwolonej liczby połączeń serwera zestaw SDK nie uruchamia nowych połączeń, gdy liczba połączeń serwera osiągnie limit.

ApplicationName

  • Wartość domyślna to null.
  • Ta opcja może być przydatna, jeśli chcesz udostępnić to samo wystąpienie usługi Azure SignalR dla różnych serwerów aplikacji zawierających te same nazwy centrum. Jeśli nie zostanie ustawiona, wszystkie połączone serwery aplikacji będą traktowane jako wystąpienia tej samej aplikacji.

ClaimsProvider

  • Wartość domyślna to null.
  • Ta opcja steruje oświadczeniami, które chcesz skojarzyć z połączeniem klienta. Jest on używany, gdy zestaw SDK usługi generuje token dostępu dla klienta w żądaniu negocjowania klienta. Domyślnie wszystkie roszczenia z HttpContext.User wynegocjowanego żądania są zastrzeżone. Dostęp do nich można uzyskać pod adresem Hub.Context.User.
  • Zwykle należy pozostawić tę opcję tak, jak to jest. Przed dostosowaniem upewnij się, że rozumiesz, co się stanie.

AccessTokenLifetime

  • Wartość domyślna to 1 hour.
  • Ta opcja steruje prawidłowym okresem istnienia tokenu dostępu generowanym przez zestaw SDK usługi dla każdego klienta. Token dostępu jest zwracany w odpowiedzi na żądanie negocjowania klienta.
  • Jeśli ServerSentEvent połączenie klienta jest używane jako transport lub LongPolling jest używane jako transport, zostanie zamknięte z powodu niepowodzenia uwierzytelniania po wygaśnięciu czasu. Możesz zwiększyć tę wartość, aby uniknąć rozłączenia klienta.

AccessTokenAlgorithm

  • Wartość domyślna to HS256
  • Ta opcja zapewnia wybór podczas generowania tokenu SecurityAlgorithms dostępu. Teraz obsługiwane są opcjonalne wartości HS256 i HS512. Należy pamiętać, że jest to bezpieczniejsze, HS512 ale wygenerowany token jest stosunkowo dłuższy niż w przypadku używania metody HS256.

ServerStickyMode

  • Wartość domyślna to Disabled.
  • Ta opcja określa tryb sticky serwera. Gdy klient jest kierowany do serwera, z którego najpierw negocjuje, nazywamy go lepkim serwerem.
  • W scenariuszach rozproszonych może istnieć wiele serwerów aplikacji połączonych z jednym wystąpieniem usługi Azure SignalR. Jak wyjaśniono wewnętrznych połączeń klienckich, klient najpierw negocjuje z serwerem aplikacji, a następnie przekierowuje do usługi Azure SignalR, aby nawiązać trwałe połączenie. Usługa Azure SignalR następnie znajduje jeden serwer aplikacji do obsługi klienta, jak wyjaśniono w artykule Transport Data between client and server (Transport Data between client and server ).
    • Gdy Disabledklient kieruje się do losowego serwera aplikacji. Ogólnie rzecz biorąc, serwery aplikacji mają zrównoważone połączenia klienta z tym trybem. Jeśli twoje scenariusze są rozgłaszane lub wysyłane przez grupę, użyj tej opcji domyślnej jest wystarczająca.
    • Gdy Preferredusługa Azure SignalR próbuje znaleźć serwer aplikacji, z którego klient najpierw negocjuje w taki sposób, że nie jest potrzebny żaden inny koszt ani routing globalny. Może to być przydatne, gdy scenariusz jest wysyłany do połączenia*. Wysyłanie do połączenia może mieć lepszą wydajność i mniejsze opóźnienie, gdy nadawca i odbiorca są kierowane do tego samego serwera aplikacji.
    • Gdy Requiredusługa Azure SignalR zawsze próbuje znaleźć serwer aplikacji, z którego klient najpierw negocjuje. Ta opcja może być przydatna, gdy jakiś kontekst klienta jest pobierany z negotiate kroku i przechowywany w pamięci, a następnie do użycia wewnątrz Hubs. Jednak ta opcja może mieć wady wydajności, ponieważ wymaga usługi Azure SignalR podjęcia innych wysiłków w celu znalezienia tego konkretnego serwera aplikacji globalnie i utrzymania globalnego routingu ruchu między klientem a serwerem.

GracefulShutdown

GracefulShutdown.Mode
  • Wartość domyślna to Off
  • Ta opcja określa zachowanie po otrzymaniu przez serwer aplikacji SIGINT (CTRL + C).
  • W przypadku ustawienia wartości WaitForClientsClose, zamiast natychmiast zatrzymywać serwer, usuwamy go z usługi Azure SignalR Service, aby zapobiec przypisywaniu nowych połączeń klienckich do tego serwera.
  • Ponadto w przypadku ustawienia opcji MigrateClientsna , spróbujemy przeprowadzić migrację połączeń klienckich do innego prawidłowego serwera. Migracja zostanie wyzwolona dopiero po dostarczeniu komunikatu.
    • OnConnected i OnDisconnected są wyzwalane podczas migrowania połączeń w/wy.
    • IConnectionMigrationFeature może pomóc w ustaleniu, czy połączenie jest migrowane do/wył.
    • Zobacz nasze przykładowe kody , aby uzyskać szczegółowe informacje o użyciu.
GracefulShutdown.Timeout
  • Wartość domyślna to 30 seconds
  • Ta opcja określa najdłuższy czas oczekiwania na zamknięcie/migrację klientów.

ServiceScaleTimeout

  • Wartość domyślna to 5 minutes
  • Ta opcja określa najdłuższy czas oczekiwania na dynamiczne punkty końcowe usługi skalowania, które mają wpływ na klientów online co najmniej. Zwykle dynamiczna skala między pojedynczym serwerem aplikacji a punktem końcowym usługi może zostać zakończona w sekundach, biorąc pod uwagę, czy masz wiele serwerów aplikacji i wiele punktów końcowych usługi z zakłóceniami sieci i chcesz zapewnić stabilność klienta, możesz odpowiednio skonfigurować tę wartość.

MaxPollIntervalInSeconds

  • Wartość domyślna to 5
  • Ta opcja definiuje maksymalny interwał sondowania dozwolony dla LongPolling połączeń w usłudze Azure SignalR Service. Jeśli następne żądanie sondowania nie znajduje się w usłudze MaxPollIntervalInSeconds, usługa Azure SignalR Service czyści połączenie klienta.
  • Wartość jest ograniczona do [1, 300].

TransportTypeDetector

  • Wartość domyślna: wszystkie transporty są włączone.
  • Ta opcja definiuje funkcję, aby dostosować transporty, których klienci mogą używać do wysyłania żądań HTTP.
  • Użyj tych opcji zamiast HttpConnectionDispatcherOptions.Transports skonfigurować transporty.

Przykład

Powyższe opcje można skonfigurować, takie jak poniższy przykładowy kod.

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

W przypadku starszej wersji ASP.NET SignalR

Uwaga

Jeśli po raz pierwszy próbujesz signalR, zalecamy użycie ASP.NET Core SignalR, jest prostsze, bardziej niezawodne i łatwiejsze w użyciu.

Instalacja zestawu SDK

Zainstaluj zestaw SDK usługi SignalR Service w projekcie ASP.NET za pomocą konsoli Menedżer pakietów:

Install-Package Microsoft.Azure.SignalR.AspNet

Startup W klasie użyj zestawu SDK usługi SignalR Service jako poniższego fragmentu kodu, zastąp element MapSignalR() na MapAzureSignalR({your_applicationName}). Zastąp {YourApplicationName} ciąg nazwą aplikacji. Jest to unikatowa nazwa, aby odróżnić tę aplikację od innych aplikacji. Możesz użyć this.GetType().FullName jako wartości.

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

Konfigurowanie parametry połączenia

Ustaw parametry połączenia w web.config pliku na sekcjęconnectionStrings:

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

Konfigurowanie opcji

Istnieje kilka opcji , które można dostosować podczas korzystania z zestawu Sdk usługi Azure SignalR Service.

ConnectionString

  • Wartość domyślna Azure:SignalR:ConnectionString connectionString to lub appSetting w web.config pliku .
  • Można ją ponownie skonfigurować, ale upewnij się, że wartość nie jest zakodowana w kodzie twardym.

InitialHubServerConnectionCount

  • Wartość domyślna to 5.
  • Ta opcja steruje początkową liczbą połączeń na koncentrator między serwerem aplikacji i usługą Azure SignalR Service. Zazwyczaj zachowaj ją jako wartość domyślną jest wystarczająca. W czasie wykonywania zestaw SDK może uruchamiać nowe połączenia serwera na potrzeby dostrajania wydajności lub równoważenia obciążenia. Jeśli masz dużą liczbę klientów, możesz nadać jej większą liczbę w celu uzyskania lepszej przepływności. Jeśli na przykład masz łącznie 100 000 klientów, liczbę połączeń można zwiększyć do 10 lub 15.

MaxHubServerConnectionCount

  • Wartość domyślna to null.
  • Ta opcja steruje maksymalną liczbą dozwolonych połączeń na koncentrator między serwerem aplikacji a usługą Azure SignalR Service. W czasie wykonywania zestaw SDK może uruchamiać nowe połączenia serwera na potrzeby dostrajania wydajności lub równoważenia obciążenia. Domyślnie nowe połączenie z serwerem jest uruchamiane zawsze wtedy, gdy jest to konieczne. Po skonfigurowaniu maksymalnej dozwolonej liczby połączeń serwera zestaw SDK nie uruchamia nowych połączeń, gdy liczba połączeń serwera osiągnie limit.

ApplicationName

  • Wartość domyślna to null.
  • Ta opcja może być przydatna, jeśli chcesz udostępnić to samo wystąpienie usługi Azure SignalR dla różnych serwerów aplikacji zawierających te same nazwy centrum. Jeśli nie zostanie ustawiona, wszystkie połączone serwery aplikacji będą traktowane jako wystąpienia tej samej aplikacji.

ClaimProvider

  • Wartość domyślna to null.
  • Ta opcja steruje oświadczeniami, które chcesz skojarzyć z połączeniem klienta. Jest on używany, gdy zestaw SDK usługi generuje token dostępu dla klienta w żądaniu negocjowania klienta. Domyślnie wszystkie roszczenia z IOwinContext.Authentication.User wynegocjowanego żądania są zastrzeżone.
  • Zwykle należy pozostawić tę opcję tak, jak to jest. Przed dostosowaniem upewnij się, że rozumiesz, co się stanie.

AccessTokenLifetime

  • Wartość domyślna to 1 hour.
  • Ta opcja steruje prawidłowym okresem istnienia tokenu dostępu, który jest generowany przez zestaw SDK usługi dla każdego klienta. Token dostępu jest zwracany w odpowiedzi na żądanie negocjowania klienta.
  • Jeśli ServerSentEvent połączenie klienta jest używane jako transport lub LongPolling jest używane jako transport, zostanie zamknięte z powodu niepowodzenia uwierzytelniania po wygaśnięciu czasu. Możesz zwiększyć tę wartość, aby uniknąć rozłączenia klienta.

AccessTokenAlgorithm

  • Wartość domyślna to HS256
  • Ta opcja zapewnia wybór podczas generowania tokenu SecurityAlgorithms dostępu. Teraz obsługiwane są opcjonalne wartości HS256 i HS512. Należy pamiętać, że jest to bezpieczniejsze, HS512 ale wygenerowany token jest stosunkowo dłuższy niż w przypadku używania metody HS256.

ServerStickyMode

  • Wartość domyślna to Disabled.
  • Ta opcja określa tryb sticky serwera. Gdy klient jest kierowany do serwera, z którego najpierw negocjuje, nazywamy go lepkim serwerem.
  • W scenariuszach rozproszonych może istnieć wiele serwerów aplikacji połączonych z jednym wystąpieniem usługi Azure SignalR. Jak wyjaśniono wewnętrznych połączeń klienckich, klient najpierw negocjuje z serwerem aplikacji, a następnie przekierowuje do usługi Azure SignalR, aby nawiązać trwałe połączenie. Usługa Azure SignalR następnie znajduje jeden serwer aplikacji do obsługi klienta, jak wyjaśniono w artykule Transport Data between client and server (Transport Data between client and server ).
    • Gdy Disabledklient kieruje się do losowego serwera aplikacji. Ogólnie rzecz biorąc, serwery aplikacji mają zrównoważone połączenia klienta z tym trybem. Jeśli twoje scenariusze są rozgłaszane lub wysyłane przez grupę, użyj tej opcji domyślnej jest wystarczająca.
    • Gdy Preferredusługa Azure SignalR próbuje znaleźć serwer aplikacji, z którego klient najpierw negocjuje w taki sposób, że nie jest potrzebny żaden inny koszt ani routing globalny. Może to być przydatne, gdy scenariusz jest wysyłany do połączenia*. Wysyłanie do połączenia może mieć lepszą wydajność i mniejsze opóźnienie, gdy nadawca i odbiorca są kierowane do tego samego serwera aplikacji.
    • Gdy Requiredusługa Azure SignalR zawsze próbuje znaleźć serwer aplikacji, z którego klient najpierw negocjuje. Ta opcja może być przydatna, gdy jakiś kontekst klienta jest pobierany z negotiate kroku i przechowywany w pamięci, a następnie do użycia wewnątrz Hubs. Jednak ta opcja może mieć wady wydajności, ponieważ wymaga usługi Azure SignalR podjęcia innych wysiłków w celu znalezienia tego konkretnego serwera aplikacji globalnie i utrzymania globalnego routingu ruchu między klientem a serwerem.

MaxPollIntervalInSeconds

  • Wartość domyślna to 5
  • Ta opcja definiuje maksymalny czas bezczynności dozwolony dla nieaktywnych połączeń w usłudze Azure SignalR Service. W ASP.NET SignalR ma zastosowanie do długiego typu transportu sondowania lub ponownego połączenia. Jeśli następne /reconnect lub /poll żądanie nie znajduje się w usłudze MaxPollIntervalInSeconds, usługa Azure SignalR Service czyści połączenie klienta.
  • Wartość jest ograniczona do [1, 300].

Przykład

Powyższe opcje można skonfigurować, takie jak poniższy przykładowy kod.

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

Skalowanie serwera aplikacji w poziomie

Dzięki usłudze Azure SignalR Service trwałe połączenia są odciążane z serwera aplikacji, dzięki czemu można skoncentrować się na implementowaniu logiki biznesowej w klasach koncentratora. Jednak nadal trzeba skalować serwery aplikacji w poziomie, aby uzyskać lepszą wydajność podczas obsługi ogromnych połączeń klienckich. Poniżej przedstawiono kilka wskazówek dotyczących skalowania serwerów aplikacji w poziomie.

  • Wiele serwerów aplikacji może łączyć się z tym samym wystąpieniem usługi Azure SignalR Service.
  • Jeśli chcesz udostępnić to samo wystąpienie usługi Azure SignalR dla różnych aplikacji zawierających te same nazwy centrum, ustaw je za pomocą innej opcji ApplicationName . Jeśli nie zostanie ustawiona, wszystkie połączone serwery aplikacji będą traktowane jako wystąpienia tej samej aplikacji.
  • Jeśli opcja ApplicationName i nazwa klasy centrum są takie same, połączenia z różnych serwerów aplikacji są grupowane w tym samym centrum.
  • Każde połączenie klienta jest tworzone tylko na jednym z serwerów aplikacji, a komunikaty z tego klienta są wysyłane tylko do tego samego serwera aplikacji. Jeśli chcesz uzyskać dostęp do informacji o kliencie globalnie (ze wszystkich serwerów aplikacji), musisz użyć scentralizowanego magazynu, aby zapisać informacje o kliencie ze wszystkich serwerów aplikacji.

Następne kroki

Z tego artykułu dowiesz się, jak używać usługi SignalR Service w aplikacjach. Zapoznaj się z następującymi artykułami, aby dowiedzieć się więcej o usłudze SignalR Service.

Wewnętrzne elementy usługi Azure SignalR Service

Szybki start: tworzenie pokoju rozmów przy użyciu usługi SignalR Service