Mode de service dans Azure SignalR Service
Le mode de service est un concept important dans Azure SignalR Service. SignalR Service prend actuellement en charge trois modes de service : Par défaut, Serverless et Classique. Votre ressource SignalR Service se comporte différemment dans chaque mode. Dans cet article, vous apprenez à choisir le mode de service approprié en fonction de votre scénario.
Définition du mode de service
Quand vous créez une ressource SignalR dans le portail Azure, vous êtes invité à spécifier un mode de service.
Vous pouvez également modifier le mode de service plus tard dans le menu des paramètres.
Utilisez az signalr create et az signalr update pour définir ou modifier le mode de service avec l’interface CLI d’Azure SignalR.
Mode par défaut :
Comme son nom l’indique, le mode Par défaut est le mode de service par défaut pour SignalR Service. En mode Par défaut, votre application fonctionne comme une application ASP.NET Core SignalR ou ASP.NET SignalR (déprécié) standard. Vous avez une application serveur web qui héberge un hub, ce que l’on appelle un serveur hub, et les clients communiquent en duplex intégral avec le serveur hub. La différence entre ASP.NET Core SignalR et Azure SignalR Service est qu’avec ASP.NET Core SignalR, le client se connecte directement au serveur hub. Avec Azure SignalR Service, le client et le serveur hub se connectent tous les deux à SignalR Service et utilisent le service comme proxy. Le diagramme suivant montre la structure d’application standard en mode Par défaut.
Le mode Par défaut est généralement le bon choix quand vous souhaitez utiliser une application SignalR avec SignalR Service.
Routage des connexions en mode Par défaut
En mode Par défaut, des connexions WebSocket (appelées connexions serveur) sont établies entre le serveur hub et SignalR Service. Ces connexions permettent de transférer les messages entre un serveur et le client. Lorsqu’un nouveau client est connecté, SignalR Service achemine le client vers un serveur hub (en supposant que vous ayez plusieurs serveurs) via des connexions serveur existantes. La connexion cliente reste sur le même serveur hub pendant toute sa durée de vie. C’est ce que l’on appelle l’adhérence de la connexion. Quand le client envoie des messages, ceux-ci sont toujours dirigés vers le même serveur hub. Grâce au comportement d’adhérence, vous pouvez gérer en toute sécurité certains états pour les connexions individuelles sur votre serveur hub. Par exemple, si vous souhaitez envoyer en streaming du contenu entre un serveur et un client, vous n’avez pas besoin de considérer le cas où les paquets de données sont dirigés vers des serveurs différents.
Important
En mode Par défaut, un client ne peut pas se connecter si un serveur hub n’est pas préalablement connecté au service. Si tous vos serveurs hubs sont déconnectés en raison d’une interruption du réseau ou du redémarrage du serveur, la connexion de votre client recevra un message d’erreur vous informant qu’aucun serveur n’est connecté. Il vous appartient de vérifier qu’il y a toujours au moins un serveur hub connecté au service SignalR. Par exemple, vous pouvez concevoir votre application avec plusieurs serveurs hubs, puis vérifier qu’ils ne seront pas tous hors connexion en même temps.
Le modèle de routage par défaut signifie également que, lors de la mise hors connexion d’un serveur hub, les connexions acheminées vers ce serveur sont abandonnées. Vous devez vous attendre à une perte de connexion lorsque votre serveur hub est hors connexion pour maintenance et gérer la reconnexion afin de minimiser les conséquences sur votre application.
Remarque
En mode Par défaut, vous pouvez également utiliser l’API REST, le SDK de gestion et la liaison de fonction pour envoyer directement des messages à un client si vous ne souhaitez pas passer par un serveur hub. En mode Par défaut, les connexions client sont toujours gérées par les serveurs hubs et les points de terminaison en amont ne fonctionnent pas dans ce mode.
Mode serverless
Contrairement au mode Par défaut, le mode Serverless ne nécessite pas l’exécution d’un serveur hub (d’où le nom « serverless »). SignalR Service est responsable de la gestion des connexions client. Il n’y a aucune garantie d’adhérence des connexions et les requêtes HTTP risquent d’être moins efficaces que les connexions WebSocket.
Le mode Serverless fonctionne avec Azure Functions pour fournir une fonctionnalité de messagerie en temps réel. Les clients utilisent des liaisons SignalR Service pour Azure Functions, appelées liaisons de fonction, pour envoyer des messages en tant que liaison de sortie.
En raison de l’absence de connexion serveur, vous obtenez une erreur si vous essayez d’utiliser un SDK serveur pour établir une connexion serveur. SignalR Service rejette les tentatives de connexion serveur en mode Serverless.
Le mode Serverless ne bénéficie pas de l’adhérence des connexions, mais vous pouvez toujours avoir une application côté serveur qui pousse (push) des messages aux clients. Il existe deux façons de pousser des messages aux clients en mode Serverless :
- En utilisant des API REST pour un événement d’envoi unique
- En utilisant une connexion WebSocket pour pouvoir envoyer plusieurs messages plus efficacement Cette connexion WebSocket est différente d’une connexion serveur.
Remarque
Ces deux méthodes, par API REST et WebSocket, sont prises en charge par le SDK de gestion du service SignalR. Si vous utilisez un langage autre que .NET, vous pouvez également appeler manuellement les API REST en suivant cette spécification.
Il est également possible pour votre application serveur de recevoir des messages et des événements de connexion des clients. SignalR Service remet les messages et les événements de connexion à des points de terminaison préconfigurés (appelés points de terminaison en amont) au moyen de webhooks. Les points de terminaison en amont ne peuvent être configurés qu’en mode Serverless. Pour plus d’informations, consultez Points de terminaison en amont.
Le diagramme suivant montre le fonctionnement du mode Serverless.
Mode classique
Remarque
Le mode Classique est principalement destiné à la compatibilité descendante des applications créées avant l’introduction des modes Par défaut et Serverless. N’utilisez le mode Classique qu’en dernier recours. Pour les nouvelles applications, utilisez Par défaut ou Serverless en fonction de votre scénario. Songez à reconcevoir vos applications existantes pour éliminer le recours au mode Classique.
Le mode Classique est un mixte des modes Par défaut et Serverless. En mode Classique, le type de connexion est déterminé par la présence ou non d’un serveur hub connecté quand la connexion client est établie. Si un serveur hub est présent, la connexion client est acheminée vers un serveur hub. Si aucun serveur hub n’est disponible, la connexion cliente est établie en mode serverless limité où les messages client-à-serveur ne peuvent pas être remis à un serveur hub. Les connexions serverless en mode Classique ne prennent pas en charge certaines fonctionnalités telles que les points de terminaison en amont.
Si tous vos serveurs hubs sont hors connexion pour une raison quelconque, les connexions sont établies en mode serverless. Il vous appartient de vérifier qu’au moins un serveur hub est toujours disponible.
Choisir le mode de service approprié
À présent, vous devriez comprendre les différences entre les modes de service et savoir comment choisir entre eux. Comme indiqué précédemment, le mode Classique n’est pas recommandé pour les nouvelles applications ou celles existantes. Voici d’autres conseils qui peuvent vous aider à bien choisir le mode de service et à mettre hors service le mode Classique pour les applications existantes.
Choisissez le mode Par défaut si vous savez déjà comment fonctionne la bibliothèque SignalR et que vous souhaitez passer d’un service SignalR auto-hébergé à Azure SignalR Service. Le mode Par défaut fonctionne exactement de la même façon qu’un service SignalR auto-hébergé et vous pouvez utiliser le même modèle de programmation dans la bibliothèque SignalR. SignalR Service agit comme un proxy entre les clients et les serveurs hubs.
Choisissez le mode Serverless si vous créez une application et que vous ne souhaitez pas gérer de serveurs hubs ni de connexions serveur. Le mode Serverless fonctionnant avec Azure Functions, vous n’avez pas besoin de gérer un serveur. Vous pouvez toujours avoir des communications duplex avec l’API REST, le SDK de gestion ou la liaison de fonction + le point de terminaison en amont, mais le modèle de programmation est différent de la bibliothèque SignalR.
Choisissez le mode Par défaut si vous avez à la fois des serveurs hubs pour servir les connexions client et une application back-end pour pousser directement les messages aux clients. La différence principale entre le mode Par défaut et le mode Serverless est le fait d’avoir ou non des serveurs hubs et la façon dont les connexions client sont acheminées. L’API REST, le SDK de gestion et la liaison de fonction peuvent être utilisés dans les deux modes.
Si vous avez vraiment un scénario mixte, envisagez de séparer les cas d’usage en plusieurs instances SignalR Service, le mode de service variant alors selon l’usage. Par exemple, dans un scénario mixte où deux hubs différents se trouvent sur la même ressource SignalR, vous devez utiliser le mode Classique. Un hub est utilisé comme hub SignalR traditionnel et l’autre hub est utilisé avec Azure Functions. Cet exemple doit être divisé en deux ressources, avec une instance en mode Par défaut et l’autre en mode Serverless.
Étapes suivantes
Pour en savoir plus sur l’utilisation des modes Par défaut et Serverless, lisez les articles suivants.