Tjänstläge i Azure SignalR Service
Tjänstläge är ett viktigt begrepp i Azure SignalR Service. SignalR Service stöder för närvarande tre tjänstlägen: Standard, Serverlös och Klassisk. SignalR Service-resursen fungerar olika i varje läge. I den här artikeln får du lära dig hur du väljer rätt tjänstläge baserat på ditt scenario.
Ange tjänstläge
Du uppmanas att ange ett tjänstläge när du skapar en ny SignalR-resurs i Azure Portal.
Du kan också ändra tjänstläget senare på inställningsmenyn.
Använd az signalr create och az signalr update för att ange eller ändra tjänstläget med hjälp av Azure SignalR CLI.
Standardläge
Som namnet antyder är standardläget standardtjänstläget för SignalR Service. I standardläge fungerar programmet som ett typiskt ASP.NET Core SignalR - eller ASP.NET SignalR-program (inaktuellt). Du har ett webbserverprogram som är värd för en hubb, som kallas hubbserver, och klienter har fullständig duplex-kommunikation med hubbservern. Skillnaden mellan ASP.NET Core SignalR och Azure SignalR Service är: Med ASP.NET Core SignalR ansluter klienten direkt till hubbservern. Med Azure SignalR Service ansluter både klienten och hubbservern till SignalR Service och använder tjänsten som proxy. Följande diagram visar den typiska programstrukturen i standardläge.
Standardläget är vanligtvis rätt val när du har ett SignalR-program som du vill använda med SignalR Service.
Anslutningsroutning i standardläge
I standardläge finns det WebSocket-anslutningar mellan hubbservern och SignalR Service som kallas serveranslutningar. Dessa anslutningar används för att överföra meddelanden mellan en server och en klient. När en ny klient är ansluten dirigerar SignalR Service klienten till en hubbserver (anta att du har fler än en server) via befintliga serveranslutningar. Klientanslutningen fastnar på samma hubbserver under dess livslängd. Den här egenskapen kallas för fast anslutning. När klienten skickar meddelanden går de alltid till samma hubbserver. Med fasthetsbeteende kan du på ett säkert sätt underhålla vissa tillstånd för enskilda anslutningar på hubbservern. Om du till exempel vill strömma något mellan server och klient behöver du inte överväga det fall där datapaket går till olika servrar.
Viktigt!
I standardläge kan en klient inte ansluta utan att en hubbserver ansluts till tjänsten först. Om alla dina hubbservrar är frånkopplade på grund av nätverksavbrott eller serveromstart får klientanslutningarna ett felmeddelande om att ingen server är ansluten. Det är ditt ansvar att se till att det alltid finns minst en hubbserver ansluten till SignalR-tjänsten. Du kan till exempel utforma ditt program med flera hubbservrar och sedan se till att alla inte kopplas från samtidigt.
Standardroutningsmodellen innebär också att när en hubbserver kopplas från tas anslutningarna som dirigeras till servern bort. Du bör förvänta dig att anslutningarna släpps när hubbservern är offline för underhåll och hanterar återanslutning för att minimera effekterna på ditt program.
Kommentar
I standardläge kan du också använda REST API, hanterings-SDK och funktionsbindning för att skicka meddelanden direkt till en klient om du inte vill gå via en hubbserver. Klientanslutningar i standardläge hanteras fortfarande av hubbservrar och överordnade slutpunkter fungerar inte i det läget.
Serverlöst läge
Till skillnad från standardläget kräver inte serverlöst läge att en hubbserver körs, vilket är anledningen till att det här läget heter "serverlöst". SignalR Service ansvarar för att underhålla klientanslutningar. Det finns ingen garanti för att anslutningen är fast och HTTP-begäranden kan vara mindre effektiva än WebSockets-anslutningar.
Serverlöst läge fungerar med Azure Functions för att tillhandahålla meddelandefunktioner i realtid. Klienter arbetar med SignalR Service-bindningar för Azure Functions, som kallas funktionsbindning, för att skicka meddelanden som en utdatabindning.
Eftersom det inte finns någon serveranslutning får du ett fel om du försöker använda en server-SDK för att upprätta en serveranslutning. SignalR Service avvisar serveranslutningsförsök i serverlöst läge.
Serverlöst läge har inte anslutningsproblem, men du kan fortfarande ha push-meddelanden på serversidan till klienter. Det finns två sätt att skicka meddelanden till klienter i serverlöst läge:
- Använd REST-API:er för en engångshändelse för att skicka, eller
- Använd en WebSocket-anslutning så att du kan skicka flera meddelanden mer effektivt. Den här WebSocket-anslutningen skiljer sig från en serveranslutning.
Kommentar
Både REST API och WebSockets stöds i SignalR Service Management SDK. Om du använder ett annat språk än .NET kan du också manuellt anropa REST-API:erna enligt den här specifikationen.
Det är också möjligt för serverprogrammet att ta emot meddelanden och anslutningshändelser från klienter. SignalR Service levererar meddelanden och anslutningshändelser till förkonfigurerade slutpunkter (kallas överordnade slutpunkter) med hjälp av webbkrokar. Överordnade slutpunkter kan bara konfigureras i serverlöst läge. Mer information finns i Överordnade slutpunkter.
Följande diagram visar hur serverlöst läge fungerar.
Klassiskt läge
Kommentar
Klassiskt läge är främst för bakåtkompatibilitet för program som skapades innan standard- och serverlösa lägen introducerades. Använd inte klassiskt läge förutom som en sista utväg. Använd Standard eller Serverlös för nya program, baserat på ditt scenario. Du bör överväga att designa om befintliga program för att eliminera behovet av klassiskt läge.
Klassisk är ett blandat läge med standardlägen och serverlösa lägen. I klassiskt läge bestäms anslutningstypen av om det finns en hubbserver som är ansluten när klientanslutningen upprättas. Om det finns en hubbserver dirigeras klientanslutningen till en hubbserver. Om en hubbserver inte är tillgänglig görs klientanslutningen i ett begränsat serverlöst läge där klient-till-server-meddelanden inte kan levereras till en hubbserver. Serverlösa anslutningar i klassiskt läge stöder inte vissa funktioner, till exempel överordnade slutpunkter.
Om alla dina hubbservrar av någon anledning är offline görs anslutningar i serverlöst läge. Det är ditt ansvar att se till att minst en hubbserver alltid är tillgänglig.
Välj rätt tjänstläge
Nu bör du förstå skillnaderna mellan tjänstlägen och veta hur du väljer mellan dem. Som tidigare nämnts rekommenderas inte klassiskt läge för nya eller befintliga program. Här följer några fler tips som kan hjälpa dig att göra rätt val för tjänstläge och hjälpa dig att dra tillbaka klassiskt läge för befintliga program.
Välj Standardläge om du redan är bekant med hur SignalR-biblioteket fungerar och vill gå från en lokal SignalR för att använda Azure SignalR Service. Standardläget fungerar exakt på samma sätt som lokalt installerad SignalR, och du kan använda samma programmeringsmodell i SignalR-biblioteket. SignalR Service fungerar som en proxy mellan klienter och hubbservrar.
Välj Serverlöst läge om du skapar ett nytt program och inte vill underhålla hubbserver- och serveranslutningar. Serverlöst läge fungerar tillsammans med Azure Functions så att du inte behöver underhålla någon server alls. Du kan fortfarande ha fullständig duplex-kommunikation med REST API, hanterings-SDK eller funktionsbindning + uppströmsslutpunkt, men programmeringsmodellen skiljer sig från SignalR-biblioteket.
Välj Standardläge om du har båda hubbservrarna för att hantera klientanslutningar och ett serverdelsprogram för att skicka meddelanden direkt till klienter. Den viktigaste skillnaden mellan standard- och serverlöst läge är om du har hubbservrar och hur klientanslutningar dirigeras. REST API/management SDK/function binding kan användas i båda lägena.
Överväg att separera användningsfall i flera SignalR Service-instanser med tjänstläge inställt enligt användning, om du verkligen har ett blandat scenario. Ett exempel på ett blandat scenario som kräver klassiskt läge är där du har två olika hubbar på samma SignalR-resurs. En hubb används som en traditionell SignalR-hubb och den andra hubben används med Azure Functions. Det här exemplet bör delas upp i två resurser, med en instans i standardläge och en i serverlöst läge.
Nästa steg
Läs följande artiklar om du vill veta mer om hur du använder standardlägen och serverlösa lägen.