Tryb usługi w usłudze Azure SignalR Service
Tryb usługi jest ważnym pojęciem w usłudze Azure SignalR Service. Usługa SignalR Service obsługuje obecnie trzy tryby usługi: Domyślne, Bezserwerowe i Klasyczne. Zasób usługi SignalR Service zachowuje się inaczej w każdym trybie. W tym artykule dowiesz się, jak wybrać odpowiedni tryb usługi na podstawie danego scenariusza.
Ustawianie trybu usługi
Podczas tworzenia nowego zasobu usługi SignalR w witrynie Azure Portal zostanie wyświetlony monit o określenie trybu usługi.
Tryb usługi można również zmienić w dalszej części menu ustawień.
Użyj az signalr create poleceń i az signalr update , aby ustawić lub zmienić tryb usługi przy użyciu interfejsu wiersza polecenia usługi Azure SignalR.
Tryb domyślny
Jak wskazuje nazwa, tryb domyślny jest domyślnym trybem usługi dla usługi SignalR Service. W trybie domyślnym aplikacja działa jako typowa aplikacja ASP.NET Core SignalR lub ASP.NET SignalR (przestarzała). Masz aplikację serwera internetowego, która hostuje centrum, nazywane serwerem centrum, a klienci mają pełną dwukierunkową komunikację z serwerem centrum. Różnica między ASP.NET Core SignalR i Azure SignalR Service polega na bezpośrednim połączeniu klienta i serwera koncentratora, klienta i serwera zarówno z usługą SignalR Service, jak i korzystania z usługi jako serwera proxy. Na poniższym diagramie przedstawiono typową strukturę aplikacji w trybie domyślnym.
Tryb domyślny jest zazwyczaj właściwym wyborem, gdy masz aplikację SignalR, której chcesz używać z usługą SignalR Service.
Routing Połączenie ion w trybie domyślnym
W trybie domyślnym istnieją połączenia Protokołu WebSocket między serwerem koncentratora i usługą SignalR Service nazywanymi połączeniami serwera. Te połączenia są używane do transferu komunikatów między serwerem a klientem. Po nawiązaniu połączenia nowego klienta usługa SignalR Service będzie kierować klienta do jednego serwera koncentratora (załóżmy, że masz więcej niż jeden serwer) za pośrednictwem istniejących połączeń serwera. Połączenie klienta będzie trzymać się tego samego serwera koncentratora w okresie jego istnienia. Ta właściwość jest określana jako stickiness połączenia. Gdy klient wysyła komunikaty, zawsze przechodzi do tego samego serwera koncentratora. Dzięki zachowaniu stickiness można bezpiecznie obsługiwać niektóre stany dla poszczególnych połączeń na serwerze koncentratora. Jeśli na przykład chcesz przesłać strumieniowo coś między serwerem a klientem, nie musisz brać pod uwagę przypadku, w którym pakiety danych przechodzą do różnych serwerów.
Ważne
W trybie domyślnym klient nie może nawiązać połączenia bez uprzedniego połączenia z usługą serwera koncentratora. Jeśli wszystkie serwery koncentratora zostaną rozłączone z powodu przerwy w działaniu sieci lub ponownego uruchomienia serwera, połączenia klienckie otrzymają błąd informujący o braku połączenia z serwerem. Twoim zadaniem jest upewnienie się, że zawsze istnieje co najmniej jeden serwer piasty połączony z usługą SignalR. Możesz na przykład zaprojektować aplikację z wieloma serwerami koncentratora, a następnie upewnić się, że nie będą one w trybie offline w tym samym czasie.
Domyślny model routingu oznacza również, że gdy serwer koncentratora przejdzie w tryb offline, połączenia kierowane do tego serwera zostaną porzucone. Należy oczekiwać, że połączenia spadną, gdy serwer centrum jest w trybie offline na potrzeby konserwacji, i obsługiwać ponowne nawiązywanie połączenia, aby zminimalizować wpływ na aplikację.
Uwaga
W trybie domyślnym możesz również użyć interfejsu API REST, zestawu SDK zarządzania i powiązania funkcji, aby bezpośrednio wysyłać komunikaty do klienta, jeśli nie chcesz przechodzić przez serwer koncentratora. W trybie domyślnym połączenia klienta są nadal obsługiwane przez serwery koncentratora, a nadrzędne punkty końcowe nie będą działać w tym trybie.
Tryb bezserwerowy
W przeciwieństwie do trybu domyślnego tryb bezserwerowy nie wymaga uruchomienia serwera koncentratora, dlatego ten tryb ma nazwę "bezserwerowy". Usługa SignalR Service jest odpowiedzialna za utrzymywanie połączeń klientów. Nie ma gwarancji, że wydajność połączeń i żądania HTTP mogą być mniej wydajne niż połączenia Protokołu WebSocket.
Tryb bezserwerowy współdziała z usługą Azure Functions, aby zapewnić możliwość obsługi komunikatów w czasie rzeczywistym. Klienci pracują z powiązaniami usługi SignalR Service dla usługi Azure Functions nazywanymi powiązaniem funkcji w celu wysyłania komunikatów jako powiązania wyjściowego.
Ponieważ nie ma połączenia z serwerem, jeśli spróbujesz użyć zestawu SDK serwera do nawiązania połączenia z serwerem, wystąpi błąd. Usługa SignalR Service odrzuci próby połączenia serwera w trybie bezserwerowym.
Tryb bezserwerowy nie ma gotowości połączenia, ale nadal można mieć komunikaty wypychane aplikacji po stronie serwera do klientów. Istnieją dwa sposoby wypychania komunikatów do klientów w trybie bezserwerowym:
- Używanie interfejsów API REST dla jednorazowego zdarzenia wysyłania lub
- Użyj połączenia protokołu WebSocket, aby umożliwić wydajniejsze wysyłanie wielu komunikatów. To połączenie protokołu WebSocket różni się od połączenia serwera.
Uwaga
Zarówno interfejs API REST, jak i zestawy WebSocket są obsługiwane w zestawie SDK zarządzania usługą SignalR. Jeśli używasz języka innego niż .NET, możesz również ręcznie wywołać interfejsy API REST zgodnie z tą specyfikacją.
Aplikacja serwera może również odbierać komunikaty i zdarzenia połączenia od klientów. Usługa SignalR Service dostarczy komunikaty i zdarzenia połączenia do wstępnie skonfigurowanych punktów końcowych (nazywanych nadrzędnymi punktami końcowymi) przy użyciu punktów zaczepienia sieci Web. Nadrzędne punkty końcowe można skonfigurować tylko w trybie bezserwerowym. Aby uzyskać więcej informacji, zobacz Upstream endpoints (Nadrzędne punkty końcowe).
Na poniższym diagramie przedstawiono sposób działania trybu bezserwerowego.
Tryb klasyczny
Uwaga
Tryb klasyczny dotyczy głównie zgodności z poprzednimi wersjami aplikacji utworzonych przed wprowadzeniem trybów domyślnych i bezserwerowych. Nie używaj trybu klasycznego z wyjątkiem ostateczności. Użyj opcji Domyślnej lub Bezserwerowej dla nowych aplikacji w zależności od scenariusza. Należy rozważyć przeprojektowanie istniejących aplikacji, aby wyeliminować konieczność korzystania z trybu klasycznego.
Model klasyczny jest trybem mieszanym trybów domyślnych i bezserwerowych. W trybie klasycznym typ połączenia jest ustalany przez to, czy istnieje serwer koncentratora połączony po nawiązaniu połączenia klienta. Jeśli istnieje serwer koncentratora, połączenie klienta zostanie przekierowane do serwera koncentratora. Jeśli serwer koncentratora nie jest dostępny, połączenie klienta zostanie nawiązane w ograniczonym trybie bezserwerowym, w którym nie można dostarczyć komunikatów klient-serwer do serwera koncentratora. Połączenia bezserwerowe trybu klasycznego nie obsługują niektórych funkcji, takich jak nadrzędne punkty końcowe.
Jeśli wszystkie serwery koncentratora są w trybie offline z jakiegokolwiek powodu, połączenia będą wykonywane w trybie bezserwerowym. Twoim zadaniem jest zapewnienie, że co najmniej jeden serwer koncentratorowy jest zawsze dostępny.
Wybieranie odpowiedniego trybu usługi
Teraz należy zrozumieć różnice między trybami usługi i wiedzieć, jak wybrać między nimi. Jak wspomniano wcześniej, tryb klasyczny nie jest zalecany dla nowych ani istniejących aplikacji. Oto kilka dodatkowych wskazówek, które mogą pomóc w wyborze odpowiedniego trybu usługi i pomóc w wycofaniu trybu klasycznego dla istniejących aplikacji.
Wybierz tryb domyślny, jeśli znasz już sposób działania biblioteki SignalR i chcesz przejść z własnego modułu SignalR w celu korzystania z usługi Azure SignalR Service. Tryb domyślny działa dokładnie w taki sam sposób, jak self-hosted SignalR i można użyć tego samego modelu programowania w bibliotece SignalR. Usługa SignalR Service działa jako serwer proxy między klientami i serwerami koncentratorów.
Wybierz tryb bezserwerowy, jeśli tworzysz nową aplikację i nie chcesz obsługiwać połączeń serwera koncentratora i serwera. Tryb bezserwerowy współdziała z usługą Azure Functions, dzięki czemu nie trzeba w ogóle obsługiwać żadnego serwera. Nadal możesz mieć pełną dwukierunkową komunikację z interfejsem API REST, zestawem SDK zarządzania lub powiązaniem funkcji i nadrzędnym punktem końcowym, ale model programowania będzie inny niż biblioteka SignalR.
Wybierz tryb domyślny, jeśli oba serwery centrum mają obsługiwać połączenia klienta i aplikację zaplecza w celu bezpośredniego wypychania komunikatów do klientów. Kluczową różnicą między trybem domyślnym i bezserwerowym jest to, czy masz serwery koncentratora i sposób kierowania połączeń klienta. W obu trybach można używać powiązania interfejsu API REST/zestawu SDK zarządzania/funkcji.
Jeśli naprawdę masz scenariusz mieszany, rozważ rozdzielenie przypadków użycia na wiele wystąpień usługi SignalR Service z ustawionym trybem usługi zgodnie z użyciem. Przykładem mieszanego scenariusza wymagającego trybu klasycznego jest sytuacja, w której masz dwa różne koncentratory w tym samym zasobie usługi SignalR. Jedno centrum jest używane jako tradycyjne centrum SignalR, a drugi koncentrator jest używany z usługą Azure Functions. Ten przykład powinien być podzielony na dwa zasoby, z jednym wystąpieniem w trybie domyślnym i jednym w trybie bezserwerowym.
Następne kroki
Zobacz następujące artykuły, aby dowiedzieć się więcej na temat używania trybów domyślnych i bezserwerowych.