Servicemodus in Azure SignalR Service
Servicemodus is een belangrijk concept in Azure SignalR Service. SignalR Service ondersteunt momenteel drie servicemodi: Standaard, Serverloos en Klassiek. Uw SignalR Service-resource gedraagt zich anders in elke modus. In dit artikel leert u hoe u de juiste servicemodus kiest op basis van uw scenario.
De servicemodus instellen
U wordt gevraagd om een servicemodus op te geven wanneer u een nieuwe SignalR-resource maakt in Azure Portal.
U kunt ook de servicemodus later wijzigen in het instellingenmenu.
Gebruik az signalr create en az signalr update om de servicemodus in te stellen of te wijzigen met behulp van de Azure SignalR CLI.
Standaardmodus
Zoals de naam al aangeeft, is de standaardservicemodus voor SignalR Service de standaardmodus. In de standaardmodus werkt uw toepassing als een typische ASP.NET Core SignalR- of ASP.NET SignalR-toepassing (afgeschaft). U hebt een webservertoepassing die als host fungeert voor een hub, een hubserver genoemd, en clients hebben volledige dubbelzijdige communicatie met de hubserver. Het verschil tussen ASP.NET Core SignalR en Azure SignalR Service is: Met ASP.NET Core SignalR maakt de client rechtstreeks verbinding met de hubserver. Met Azure SignalR Service maken zowel de client als de hubserver verbinding met SignalR Service en gebruikt u de service als proxy. In het volgende diagram ziet u de typische toepassingsstructuur in de standaardmodus.
De standaardmodus is meestal de juiste keuze wanneer u een SignalR-toepassing hebt die u wilt gebruiken met SignalR Service.
Verbindingsroutering in de standaardmodus
In de standaardmodus zijn er WebSocket-verbindingen tussen de hubserver en SignalR-service, serververbindingen genoemd. Deze verbindingen worden gebruikt om berichten over te dragen tussen een server en client. Wanneer een nieuwe client is verbonden, stuurt SignalR Service de client naar één hubserver (stel dat u meer dan één server hebt) via bestaande serververbindingen. De clientverbinding blijft gedurende de levensduur op dezelfde hubserver. Deze eigenschap wordt aangeduid als verbindingsstickerigheid. Wanneer de client berichten verzendt, gaan ze altijd naar dezelfde hubserver. Met plakgedrag kunt u veilig bepaalde statussen voor afzonderlijke verbindingen op uw hubserver onderhouden. Als u bijvoorbeeld iets wilt streamen tussen server en client, hoeft u niet na te denken over het geval waarin gegevenspakketten naar verschillende servers gaan.
Belangrijk
In de standaardmodus kan een client geen verbinding maken zonder dat er eerst een hubserver is verbonden met de service. Als alle hubservers zijn verbroken vanwege netwerkonderbreking of het opnieuw opstarten van de server, krijgen uw clientverbindingen een foutmelding dat er geen server is verbonden. Het is uw verantwoordelijkheid om ervoor te zorgen dat er altijd ten minste één hubserver is verbonden met SignalR-service. U kunt uw toepassing bijvoorbeeld ontwerpen met meerdere hubservers en ervoor zorgen dat ze niet allemaal tegelijkertijd offline gaan.
Het standaardrouteringsmodel betekent ook dat wanneer een hubserver offline gaat, de verbindingen die naar die server worden gerouteerd, worden verwijderd. U zou moeten verwachten dat verbindingen afnemen wanneer uw hubserver offline is voor onderhoud en opnieuw verbinding maken om de gevolgen voor uw toepassing te minimaliseren.
Notitie
In de standaardmodus kunt u ook REST API, beheer-SDK en functiebinding gebruiken om berichten rechtstreeks naar een client te verzenden als u geen hubserver wilt doorlopen. Clientverbindingen in de standaardmodus worden nog steeds verwerkt door hubservers en upstream-eindpunten werken niet in die modus.
Serverloze modus
In tegenstelling tot de standaardmodus is voor de serverloze modus niet vereist dat een hubserver wordt uitgevoerd. Daarom heet deze modus serverloos. SignalR Service is verantwoordelijk voor het onderhouden van clientverbindingen. Er is geen garantie voor verbindingsstickerigheid en HTTP-aanvragen zijn mogelijk minder efficiënt dan WebSockets-verbindingen.
De serverloze modus werkt met Azure Functions om realtime berichten mogelijk te maken. Clients werken met SignalR Service-bindingen voor Azure Functions, functiebinding genoemd, om berichten als uitvoerbinding te verzenden.
Omdat er geen serververbinding is, krijgt u een fout als u een server-SDK probeert te gebruiken om een serververbinding tot stand te brengen. SignalR Service weigert serververbindingspogingen in de serverloze modus.
De serverloze modus heeft geen verbindingsstickerigheid, maar u kunt nog steeds pushberichten aan de serverzijde naar clients hebben. Er zijn twee manieren om berichten naar clients te pushen in de serverloze modus:
- REST API's gebruiken voor een eenmalige verzendgebeurtenis of
- Gebruik een WebSocket-verbinding zodat u efficiënter meerdere berichten kunt verzenden. Deze WebSocket-verbinding verschilt van een serververbinding.
Notitie
Zowel REST API als WebSockets worden ondersteund in de SignalR Service Management SDK. Als u een andere taal dan .NET gebruikt, kunt u de REST API's ook handmatig aanroepen volgens deze specificatie.
Het is ook mogelijk dat uw servertoepassing berichten en verbindingsevenementen van clients ontvangt. SignalR Service levert berichten en verbindingsgebeurtenissen aan vooraf geconfigureerde eindpunten (upstream-eindpunten genoemd) met behulp van webhook. Upstream-eindpunten kunnen alleen worden geconfigureerd in de serverloze modus. Zie Upstream-eindpunten voor meer informatie.
In het volgende diagram ziet u hoe de serverloze modus werkt.
Klassieke modus
Notitie
De klassieke modus is voornamelijk bedoeld voor achterwaartse compatibiliteit voor toepassingen die zijn gemaakt voordat de standaard- en serverloze modi werden geïntroduceerd. Gebruik de klassieke modus niet, behalve als laatste redmiddel. Gebruik standaard of serverloos voor nieuwe toepassingen, op basis van uw scenario. Overweeg bestaande toepassingen opnieuw te ontwerpen om de noodzaak van de klassieke modus te elimineren.
Klassiek is een gemengde modus van standaard- en serverloze modi. In de klassieke modus wordt het verbindingstype bepaald door of er een hubserver is verbonden wanneer de clientverbinding tot stand is gebracht. Als er een hubserver is, wordt de clientverbinding doorgestuurd naar een hubserver. Als er geen hubserver beschikbaar is, wordt de clientverbinding gemaakt in een beperkte serverloze modus waarbij client-naar-server-berichten niet kunnen worden geleverd aan een hubserver. Serverloze verbindingen in de klassieke modus bieden geen ondersteuning voor sommige functies, zoals upstream-eindpunten.
Als al uw hubservers om welke reden dan ook offline zijn, worden verbindingen gemaakt in de serverloze modus. Het is uw verantwoordelijkheid om ervoor te zorgen dat ten minste één hubserver altijd beschikbaar is.
De juiste servicemodus kiezen
Nu moet u de verschillen tussen servicemodi begrijpen en weten hoe u ertussen kunt kiezen. Zoals eerder besproken, wordt de klassieke modus niet aanbevolen voor nieuwe of bestaande toepassingen. Hier volgen nog enkele tips waarmee u de juiste keuze kunt maken voor de servicemodus en de klassieke modus voor bestaande toepassingen buiten gebruik kunt stellen.
Kies de standaardmodus als u al bekend bent met de werking van de SignalR-bibliotheek en wilt overstappen van een zelf-hostende SignalR voor het gebruik van Azure SignalR Service. De standaardmodus werkt precies op dezelfde manier als zelf-hostende SignalR en u kunt hetzelfde programmeermodel gebruiken in de SignalR-bibliotheek. SignalR Service fungeert als proxy tussen clients en hubservers.
Kies de serverloze modus als u een nieuwe toepassing maakt en geen hubserver- en serververbindingen wilt onderhouden. Serverloze modus werkt samen met Azure Functions, zodat u helemaal geen server hoeft te onderhouden. U kunt nog steeds full duplex-communicatie hebben met REST API, beheer-SDK of functiebinding + upstream-eindpunt, maar het programmeermodel verschilt van SignalR-bibliotheek.
Kies de standaardmodus als u beide hubservers hebt voor clientverbindingen en een back-endtoepassing om berichten rechtstreeks naar clients te pushen. Het belangrijkste verschil tussen de standaardmodus en de serverloze modus is of u hubservers hebt en hoe clientverbindingen worden gerouteerd. REST API/management SDK/functiebinding kan in beide modi worden gebruikt.
Overweeg gebruiksvoorbeelden te scheiden in meerdere SignalR Service-exemplaren met de servicemodus die is ingesteld op basis van gebruik, als u echt een gemengd scenario hebt. Een voorbeeld van een gemengd scenario waarvoor de klassieke modus is vereist, is waar u twee verschillende hubs op dezelfde SignalR-resource hebt. De ene hub wordt gebruikt als een traditionele SignalR-hub en de andere hub wordt gebruikt met Azure Functions. Dit voorbeeld moet worden gesplitst in twee resources, met één exemplaar in de standaardmodus en één in de serverloze modus.
Volgende stappen
Zie de volgende artikelen voor meer informatie over het gebruik van standaard- en serverloze modi.