Czy usługa Azure SignalR Service jest gotowa do użycia w środowisku produkcyjnym?
Tak, obsługa ASP.NET Core SignalR i ASP.NET SignalR jest ogólnie dostępna.
Czy w przypadku wielu serwerów aplikacji komunikaty klienckie są wysyłane do wszystkich serwerów czy tylko do jednego z nich?
Istnieje mapowanie jeden do jednego między klientem a serwerem aplikacji. Komunikaty od jednego klienta są zawsze wysyłane do tego samego serwera aplikacji.
Mapowanie jest zachowywane do momentu rozłączenia klienta lub serwera aplikacji.
Jeśli jeden z moich serwerów aplikacji nie działa, jak mogę się o tym dowiedzieć i uzyskać powiadomienie?
Usługa Azure SignalR Service monitoruje pulsy z serwerów aplikacji. Jeśli pulsy nie są odbierane przez określony okres, serwer aplikacji jest traktowany jako offline. Wszystkie połączenia klienta mapowane na ten serwer aplikacji zostaną rozłączone.
Dlaczego mój niestandardowy element "IUserIdProvider" zgłasza wyjątek podczas przełączania z zestawu SDK ASP.NET Core SignalR do zestawu SDK usługi Azure SignalR Service?
Parametr HubConnectionContext context różni się między zestawem SDK ASP.NET Core SignalR i zestawem SDK usługi Azure SignalR Service, gdy IUserIdProvider jest wywoływany.
W bibliotece SignalR platformy ASP.NET Core parametr HubConnectionContext context zawiera kontekst z prawidłowymi wartościami dla wszystkich właściwości połączenia fizycznego klienta.
W zestawie SDK HubConnectionContext context usługi Azure SignalR Service jest kontekstem z logicznego połączenia klienta. Klient fizyczny jest połączony z wystąpieniem usługi Azure SignalR Service, dlatego udostępniana jest tylko ograniczona liczba właściwości.
Obecnie tylko parametry HubConnectionContext.GetHttpContext() i HubConnectionContext.User są dostępne.
Możesz sprawdzić kod źródłowy.
Czy mogę skonfigurować transporty dostępne w usłudze Azure SignalR Service po stronie serwera za pomocą ASP.NET Core SignalR? Na przykład czy mogę wyłączyć transport protokołu WebSocket?
Tak. Zobacz Konfiguracja transportu, aby dowiedzieć się, jak skonfigurować.
Można również skonfigurować transporty po stronie klienta zgodnie z opisem w ASP.NET konfiguracji podstawowego signalr.
Jakie jest znaczenie metryk, takich jak liczba komunikatów lub liczba połączeń wyświetlana w witrynie Azure Portal? Jakiego rodzaju typ agregacji należy wybrać?
Szczegółowe informacje na temat tych metryk można znaleźć w artykule Komunikaty i połączenia w usłudze Azure SignalR Service.
W okienku przeglądu zasobów usługi Azure SignalR Service wybraliśmy już odpowiedni typ agregacji. Metryki obsługiwane w usłudze Azure Monitor można używać jako odwołania.
Jakie jest znaczenie trybów usługi "Default", "Serverless" i "Classic"? Jak mogę wybrać?
W przypadku nowych aplikacji należy używać tylko trybu domyślnego i bezserwerowego. Główną różnicą jest to, czy istnieją serwery aplikacji, które ustanawiają połączenia serwera z usługą (na przykład użyj polecenia AddAzureSignalR() w celu nawiązania połączenia z usługą). Jeśli tak, użyj trybu domyślnego, w przeciwnym razie użyj trybu bezserwerowego.
Tryb klasyczny został zaprojektowany pod kątem zgodności z poprzednimi wersjami dla istniejących aplikacji, dlatego nie powinien być używany w przypadku nowych aplikacji.
Aby uzyskać więcej informacji na temat trybu usługi, zobacz Tryb usługi w usłudze Azure SignalR Service.
Czy mogę wysłać komunikat z klienta w trybie bezserwerowym?
Jeśli skonfigurujesz nadrzędne punkty końcowe w wystąpieniu usługi SignalR, możesz wysłać komunikat z klienta. Nadrzędne punkty końcowe to zestaw punktów końcowych, które mogą odbierać komunikaty i zdarzenia połączenia z usługi SignalR. Jeśli nie skonfigurowano żadnych nadrzędnych punktów końcowych, komunikaty z klienta będą ignorowane.
Aby uzyskać więcej informacji.zobacz Upstream endpoints (Punkty końcowe nadrzędne).
Funkcja nadrzędnych punktów końcowych jest obecnie dostępna w publicznej wersji zapoznawczej.
Czy istnieją różnice w funkcji korzystania z usługi Azure SignalR Service z usługą ASP.NET SignalR?
W przypadku korzystania z usługi Azure SignalR Service niektóre interfejsy API i funkcje ASP.NET SignalR nie są obsługiwane:
- Możliwość przekazywania dowolnego stanu między klientami a koncentratorem (często nazywanym
HubState) nie jest obsługiwana. - Klasa nie jest obsługiwana
PersistentConnection. - Transport forever frame nie jest obsługiwany.
- Usługa Azure SignalR Service nie odtwarza już komunikatów wysyłanych do klienta, gdy klient jest w trybie offline.
- W przypadku korzystania z usługi Azure SignalR Service ruch dla jednego połączenia klienta jest zawsze kierowany (nazywany również sticky) do jednego wystąpienia serwera aplikacji przez czas trwania połączenia.
Obsługa ASP.NET SignalR koncentruje się na zgodności, więc nie wszystkie nowe funkcje z ASP.NET Core SignalR są obsługiwane. Na przykład pakiet MessagePack i przesyłanie strumieniowe są dostępne tylko dla aplikacji ASP.NET Core SignalR.
Usługę Azure SignalR Service można skonfigurować dla różnych trybów usług: Classic, Defaulti Serverless. Tryb Serverless nie jest obsługiwany w przypadku ASP.NET. Interfejs API REST płaszczyzny danych nie jest również obsługiwany.
Gdzie znajdują się moje dane?
Usługa Azure SignalR Service nie przechowuje żadnych danych klientów. Jeśli używasz usługi Azure SignalR Service razem z innymi usługami platformy Azure, takimi jak Usługa Azure Storage do diagnostyki, zobacz Omówienie prywatności platformy Azure (oficjalny dokument), aby uzyskać wskazówki dotyczące sposobu przechowywania danych w regionach świadczenia usługi Azure.
Jak mogę wybrać między usługą Azure SignalR i usługą Azure Web PubSub?
Zarówno usługa Azure SignalR Service , jak i usługa Azure Web PubSub pomagają klientom w łatwym tworzeniu aplikacji internetowych w czasie rzeczywistym z dużą skalą i wysoką dostępnością oraz umożliwiają klientom skupienie się na logice biznesowej zamiast zarządzania infrastrukturą obsługi komunikatów. Ogólnie rzecz biorąc, możesz wybrać usługę Azure SignalR Service, jeśli używasz już biblioteki SignalR do tworzenia aplikacji w czasie rzeczywistym. Zamiast tego, jeśli szukasz ogólnego rozwiązania do tworzenia aplikacji w czasie rzeczywistym na podstawie wzorca WebSocket i publikowania-subskrybowania, możesz wybrać usługę Azure Web PubSub. Usługa Azure Web PubSub nie zastępuje usługi Azure SignalR Service i odwrotnie; są przeznaczone dla różnych scenariuszy. Poniższe wskazówki pomogą Ci zdecydować, która usługa ma być używana w danym scenariuszu.
Usługa Azure SignalR Service jest bardziej odpowiednia, jeśli:
- Używasz już ASP.NET lub ASP.NET Core SignalR, głównie przy użyciu platformy .NET lub konieczności integracji z ekosystemem platformy .NET (na przykład Blazor).
- Dla twojej platformy jest dostępny klient SignalR.
- Potrzebny jest ustalony protokół, który obsługuje szeroką gamę:
- wzorce wywoływania (RPC i przesyłanie strumieniowe)
- transports (WebSocket, server sent events, and long polling)
- Potrzebujesz klienta, który zarządza okresem istnienia połączenia w Twoim imieniu.
Usługa Azure Web PubSub jest bardziej odpowiednia w sytuacjach, w których:
- Musisz tworzyć aplikacje w czasie rzeczywistym oparte na technologii WebSocket lub subskrybować za pośrednictwem protokołu WebSocket.
- Chcesz utworzyć własny podprotokol lub użyć istniejących zaawansowanych protokołów za pośrednictwem protokołu WebSocket (na przykład MQTT, AMQP za pośrednictwem protokołu WebSocket).
- Szukasz uproszczonego serwera, na przykład wysyłania komunikatów do klienta bez przechodzenia przez skonfigurowane zaplecze.