Režim služby ve službě Azure SignalR
Režim služby je důležitým konceptem ve službě Azure SignalR. Služba SignalR v současné době podporuje tři režimy služby: Výchozí, Bezserverová služba a Classic. Prostředek služby SignalR se v každém režimu chová odlišně. V tomto článku se dozvíte, jak zvolit správný režim služby na základě vašeho scénáře.
Nastavení režimu služby
Při vytváření nového prostředku SignalR na webu Azure Portal se zobrazí výzva k zadání režimu služby.
Režim služby můžete změnit také později v nabídce nastavení.
az signalr update Pomocí az signalr create Azure SignalR CLI můžete nastavit nebo změnit režim služby.
Výchozí režim
Jak název napovídá, výchozí režim je výchozím režimem služby pro službu SignalR. Ve výchozím režimu funguje vaše aplikace jako typická aplikace ASP.NET Core SignalR nebo ASP.NET SignalR (zastaralé). Máte aplikaci webového serveru, která hostuje centrum označované jako centrální server, a klienti mají úplnou duplexní komunikaci se serverem rozbočovače. Rozdíl mezi ASP.NET Core SignalR a službou Azure SignalR je: Klient se s ASP.NET Core SignalR připojuje přímo k centrálnímu serveru. Ve službě Azure SignalR se klient i centrální server připojují ke službě SignalR a používají tuto službu jako proxy server. Následující diagram znázorňuje typickou strukturu aplikace v režimu Výchozí.
Výchozí režim je obvykle správnou volbou, pokud máte aplikaci SignalR, kterou chcete použít se službou SignalR.
Směrování připojení ve výchozím režimu
Ve výchozím režimu existují připojení Protokolu WebSocket mezi centrálním serverem a službou SignalR, která se nazývá připojení k serveru. Tato připojení slouží k přenosu zpráv mezi serverem a klientem. Když je připojen nový klient, služba SignalR směruje klienta na jeden centrální server (předpokládejme, že máte více než jeden server) prostřednictvím existujících připojení k serveru. Během své životnosti se připojení klienta přichytí ke stejnému centrálnímu serveru. Tato vlastnost se označuje jako lepivost připojení. Když klient odesílá zprávy, vždy přejde na stejný server centra. S chováním stickiness můžete bezpečně udržovat některé stavy pro jednotlivá připojení na vašem centrálním serveru. Pokud například chcete streamovat něco mezi serverem a klientem, nemusíte brát v úvahu případ, kdy datové pakety přecházejí na různé servery.
Důležité
Ve výchozím režimu se klient nemůže připojit bez připojení centrálního serveru k této službě. Pokud jsou všechny vaše centrální servery odpojené kvůli přerušení sítě nebo restartování serveru, dojde k chybě s oznámením, že není připojený žádný server. Je vaší zodpovědností zajistit, aby byl vždy alespoň jeden centrální server připojený ke službě SignalR. Můžete například navrhnout aplikaci s více centrálními servery a pak se ujistit, že nebudou všechny ve stejnou dobu offline.
Výchozí model směrování také znamená, že když centrální server přejde do režimu offline, připojení směrovaná na tento server se zahodí. Měli byste očekávat, že se připojení zahodí, když je server rozbočovače offline kvůli údržbě, a zpracujte opětovné připojení, aby se minimalizovaly účinky na vaši aplikaci.
Poznámka:
Ve výchozím režimu můžete také použít rozhraní REST API, sadu SDK pro správu a vazbu funkcí k přímému odesílání zpráv klientovi, pokud nechcete procházet centrálním serverem. Ve výchozím režimu klientská připojení stále zpracovávají centrální servery a upstreamové koncové body v daném režimu nebudou fungovat.
Bezserverový režim
Na rozdíl od výchozího režimu bezserverový režim nevyžaduje, aby byl spuštěn centrální server, a proto se tento režim nazývá bezserverový. Služba SignalR je zodpovědná za údržbu připojení klientů. Neexistuje žádná záruka odolnosti připojení a požadavky HTTP můžou být méně efektivní než připojení WebSockets.
Bezserverový režim funguje se službou Azure Functions a poskytuje možnosti zasílání zpráv v reálném čase. Klienti pracují s vazbami služby SignalR pro Azure Functions, označovanými jako vazby funkcí, k odesílání zpráv jako výstupní vazby.
Vzhledem k tomu, že neexistuje žádné připojení k serveru, při pokusu o navázání připojení k serveru pomocí sady SDK serveru dojde k chybě. Služba SignalR odmítne pokusy o připojení k serveru v bezserverovém režimu.
Bezserverový režim nemá lepivost připojení, ale stále můžete mít serverovou aplikaci nabízenou zprávy klientům. V bezserverovém režimu můžete odesílat zprávy klientům dvěma způsoby:
- Použití rozhraní REST API pro jednorázovou událost odeslání nebo
- Použijte připojení WebSocket, abyste mohli efektivněji odesílat více zpráv. Toto připojení WebSocket se liší od připojení k serveru.
Poznámka:
Rozhraní REST API i webSocket se podporují v sadě SDK pro správu služby SignalR. Pokud používáte jiný jazyk než .NET, můžete také ručně vyvolat rozhraní REST API podle této specifikace.
Serverová aplikace může také přijímat zprávy a události připojení od klientů. Služba SignalR service doručuje zprávy a události připojení do předkonfigurovaných koncových bodů (označovaných jako upstreamové koncové body) pomocí webových hooků. Upstreamové koncové body je možné konfigurovat pouze v bezserverovém režimu. Další informace najdete v tématu Koncové body upstreamu.
Následující diagram ukazuje, jak funguje bezserverový režim.
Klasický režim
Poznámka:
Klasický režim je určený hlavně pro zpětnou kompatibilitu aplikací vytvořených před zavedením výchozích a bezserverových režimů. Nepoužívejte klasický režim s výjimkou poslední možnosti. V závislosti na vašem scénáři používejte výchozí nebo bezserverové aplikace. Měli byste zvážit přepracování stávajících aplikací, abyste eliminovali potřebu klasického režimu.
Classic je smíšený režim výchozích a bezserverových režimů. V klasickém režimu se typ připojení rozhodne, jestli je při navázání připojení klienta připojený centrální server. Pokud existuje centrální server, připojení klienta se směruje na centrální server. Pokud není server rozbočovače dostupný, je připojení klienta provedeno v omezeném režimu bez serveru, kde se zprávy typu klient-server nedají doručovat na server centra. Klasická bezserverová připojení nepodporují některé funkce, jako jsou upstreamové koncové body.
Pokud jsou všechny vaše centrální servery z nějakého důvodu offline, připojení se provádí v bezserverovém režimu. Je vaší zodpovědností zajistit, aby byl vždy dostupný aspoň jeden centrální server.
Volba správného režimu služby
Teď byste měli porozumět rozdílům mezi režimy služby a vědět, jak si mezi nimi vybrat. Jak jsme už probírali, klasický režim se nedoporučuje pro nové nebo existující aplikace. Tady je několik dalších tipů, které vám můžou pomoct vybrat správnou volbu pro režim služby a pomoct vyřadit klasický režim pro stávající aplikace.
Pokud už víte, jak knihovna SignalR funguje, a chcete přejít ze služby SignalR v místním prostředí, abyste mohli používat službu Azure SignalR, zvolte výchozí režim. Výchozí režim funguje přesně stejně jako místní signalR a v knihovně SignalR můžete použít stejný programovací model. Služba SignalR funguje jako proxy server mezi klienty a centrálními servery.
Pokud vytváříte novou aplikaci a nechcete udržovat centrální server a připojení k serveru, zvolte bezserverový režim. Bezserverový režim spolupracuje se službou Azure Functions, takže nemusíte udržovat vůbec žádný server. Stále můžete mít úplnou duplexní komunikaci s rozhraním REST API, sadou SDK pro správu nebo vazbou funkcí + upstreamový koncový bod, ale programovací model se liší od knihovny SignalR.
Pokud máte oba centrální servery pro obsluhu připojení klientů a back-endové aplikace pro přímé nabízení zpráv klientům, zvolte výchozí režim. Klíčovým rozdílem mezi výchozím a bezserverový režim je to, jestli máte centrální servery a jak se směrují připojení klientů. V obou režimech je možné použít sadu REST API/management SDK/vazbu funkcí.
Pokud skutečně máte smíšený scénář, zvažte oddělení případů použití do několika instancí služby SignalR Service s nastaveným režimem služby podle použití. Příkladem smíšeného scénáře, který vyžaduje klasický režim, je situace, kdy máte dvě různá centra ve stejném prostředku SignalR. Jedno centrum se používá jako tradiční centrum SignalR a druhé centrum se používá se službou Azure Functions. Tento příklad by měl být rozdělený do dvou prostředků, přičemž jedna instance je ve výchozím režimu a jedna v bezserverovém režimu.
Další kroky
Další informace o používání výchozích a bezserverových režimů najdete v následujících článcích.