Ce scénario explique comment concevoir l’architecture d’une solution qui traite les modifications apportées aux données sous-jacentes dans une vue web sans avoir à actualiser les pages à l’aide de services en temps réel. Des exemples qui utilisent ce scénario incluent le suivi en temps réel des produits et des marchandises, ainsi que des solutions de réseaux sociaux.
Architecture
Téléchargez un fichier Visio de cette architecture.
Composants
- Azure Service Bus est un service de messagerie cloud haute fiabilité entre des applications et des services, même quand un ou plusieurs applications/services sont hors connexion.
- Azure SignalR Service facilite l’ajout de communications en temps réel à votre application web.
- Azure Functions est une plateforme de calcul serverless basée sur les événements qui peut également résoudre les problèmes d’orchestration complexes.
Autres solutions
Il existe des alternatives pour traiter ce scénario, notamment Pusher. Il s’agit du leader de sa catégorie en matière d’API robustes pour les développeurs d’applications qui créent des fonctionnalités de communication scalables et en temps réel.
Il y a aussi PubNub. PubNub vous permet d’ajouter facilement des fonctionnalités en temps réel à vos applications sans vous soucier de l’infrastructure. Créez des applications qui permettent à vos utilisateurs de s’impliquer en temps réel sur les appareils mobiles, les navigateurs, les ordinateurs de bureau et les serveurs.
Ably est une autre alternative. Il fournit une messagerie de publication/abonnement serverless (pub/sub), qui est mise à l’échelle de manière fiable avec vos besoins. La messagerie est remise en périphérie à l’aide de WebSockets. La plateforme Ably fournit une infrastructure en temps réel hautement disponible, élastiquement évolutive et globalement distribuée en temps réel, à l’appel d’une API.
Bien que Pusher et PubNub et Ably soient les plateformes les plus largement adoptées de messagerie en temps réel, pour ce scénario, toutes les opérations sont effectuées dans Azure. Nous vous recommandons SignalR en tant que plateforme d’accès, car il permet une communication bidirectionnelle entre le serveur et le client. Il s’agit également d’un outil open source avec 7 900 étoiles et 2 200 fourches dans GitHub.
Pour plus d’informations, consultez le référentiel open source SignalR sur GitHub.
Détails du scénario
Dans ce scénario, vous allez vous pencher sur la configuration d’un service de messagerie en temps réel pour partager l’emplacement dynamique d’une transaction de service de livraison de nourriture. Cet exemple peut également être utile pour ceux qui essaieraient de créer une plateforme de partage d’emplacement en temps réel pour leurs applications web ou mobiles.
Vous utiliserez un service SignalR configuré en mode serverless pour son intégration à une application Azure Functions déclenchée par Service Bus, le tout avec .NET Core.
Cas d’usage potentiels
Ces autres cas d’usage ont des modèles de conception similaires :
- Partage de l’emplacement en temps réel avec des appareils clients
- Envoi de notifications aux utilisateurs
- Mise à jour des chronologies
- Création de salles de conversation
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.
Voici quelques éléments à prendre en compte pour développer ce scénario, notamment comment configurer les paramètres dans la chaîne de connexion Azure Service Bus dans ServiceBusTrigger :
- Hubs : les hubs peuvent être comparés à un service de streaming vidéo. Vous pouvez vous abonner à un hub pour envoyer et recevoir des messages depuis et vers celui-ci.
- Cibles : les cibles sont similaires aux canaux radio. Elles incluent tous ceux qui écoutent le canal cible, et ceux-ci sont avertis de la présence d’un nouveau message.
Si vous vous souvenez des deux fonctionnalités précédentes de la plateforme SignalR, vous pouvez être opérationnel rapidement.
Disponibilité, scalabilité et sécurité
En suivant les deux sections ci-dessous, cette solution vous permet d’obtenir une haute disponibilité.
Association régionale
Chaque région Azure est associée à une autre région de la même zone géographique. En général, choisissez des régions de la même paire régionale (par exemple, USA Est 2 et USA Centre). Cette approche offre les avantages suivants :
- En cas d’interruption de service générale, la récupération d’au moins une région de chaque paire est prioritaire.
- Les mises à jour planifiées du système Azure sont déployées dans les régions associées de manière séquentielle afin de minimiser les temps d’arrêt possibles.
- Dans la plupart des cas, les paires régionales appartiennent à la même zone géographique afin de répondre aux exigences en matière de résidence des données.
- Toutefois, assurez-vous que les deux régions prennent en charge tous les services Azure requis pour votre application. Consultez Services par région. Pour plus d’informations sur les régions jumelées, consultez l’article Continuité des activités et récupération d’urgence (BCDR) : régions jumelées d’Azure.
Azure Front Door
Téléchargez un fichier Visio de cette architecture.
Azure Front Door est un point d’entrée scalable et sécurisé pour une livraison rapide de vos applications globales. Lorsque vous utilisez le routage en fonction de la priorité, il procède à un basculement automatique si la région primaire n’est plus disponible. Une architecture multirégion peut offrir une meilleure disponibilité qu’un déploiement dans une seule région. Si une interruption de service régionale affecte la région principale, vous pouvez utiliser Front Door pour basculer vers la région secondaire.
Cette architecture peut également se révéler utile en cas d’échec d’un sous-système spécifique de la solution. Bloquez les attaques de couche réseau et d’application à la périphérie avec les fonctionnalités Pare-feu d’applications web et Protection DDoS. Renforcez votre service à l’aide d’ensembles de règles managés par Microsoft et créez vos propres règles pour une protection personnalisée de votre application.
Front Door est un point de défaillance possible dans le système. Si le service échoue, les clients ne peuvent pas accéder à votre application pendant le temps d’arrêt. Passez en revue le Contrat de niveau de service (SLA) pour Front Door et déterminez si Front Door peut à lui seul répondre à vos besoins métier en haute disponibilité. Si tel n’est pas le cas, pensez à ajouter une autre solution de gestion du trafic en guise de procédure de secours. Si le service Front Door échoue, changez vos enregistrements de nom canonique (CNAME) dans DNS pour pointer vers l’autre service de gestion du trafic. Vous devez effectuer cette étape manuellement, et votre application reste inaccessible tant que ces modifications DNS n’ont pas été propagées.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Supposons que votre entreprise a 1 000 commandes par jour et doit partager les données de localisation simultanément. L’estimation de votre utilisation Azure pour déployer ce scénario est proche de 192 USD par mois, selon le prix à la date de la rédaction de cette publication.
| Type de service | Estimation du coût mensuel |
|---|---|
| Azure Functions | 119,40 USD |
| Service Azure SignalR | 48,97 USD |
| Azure Service Bus | 23,71 USD |
| Total | 192,08 USD |
Déployer ce scénario
Développement Azure Functions
Une application serverless en temps réel intégrée à Azure Functions et Azure SignalR Service requiert généralement deux fonctions Azure :
- Une fonction
negotiateque le client appelle pour obtenir un jeton d’accès SignalR Service valide et une URL de point de terminaison du service. - Une ou plusieurs fonctions qui envoient des messages ou gèrent l’appartenance au groupe.
SignalRFunctionApp
SignalRFunctionApp est une application de fonction qui crée une instance Azure Functions avec un déclencheur Service Bus et SignalR.
Negotiate.cs
Cette fonction est déclenchée par une requête HTTP. Elle est utilisée par les applications clientes pour obtenir un jeton du service SignalR que les clients peuvent utiliser pour s’abonner à un hub. Cette fonction doit être nommée negotiate. Pour plus d’informations, consultez Développement et configuration Azure Functions avec Azure SignalR Service.
Message.cs
Cette fonction est déclenchée par un déclencheur Service Bus. Elle a une liaison avec le service SignalR. Elle extrait le message de la file d’attente et le transmet à un hub SignalR.
Instructions
Avant de commencer :
- Assurez-vous de disposer d’une file d’attente Service Bus approvisionnée sur Azure.
- Assurez-vous de disposer d’un service SignalR approvisionné en mode serverless sur Azure.
- Entrez vos chaînes de connexion (Service Bus et SignalR) dans le fichier local.settings.json.
- Entrez l'URL de l'application cliente (client SignalR) dans CORS (Cross-Origin Resource Sharing). Pour la syntaxe la plus récente, consultez Développement et configuration Azure Functions avec Azure SignalR Service.
- Entrez votre nom de file d’attente Service Bus dans le déclencheur Service Bus du fichier Message.cs.
À présent, nous allons configurer l’application cliente pour la tester. Tout d’abord, récupérez les exemples de sources à partir de la page GitHub des architectures de solution.
Client SignalR
Il s’agit d’une application web .NET Core simple pour s’abonner au hub créé par SignalRFunctionApp. Elle affiche les messages reçus dans la file d’attente Service Bus, en temps réel. Bien que vous puissiez utiliser SignalRFunctionApp avec un client mobile, tenons-nous en au client web pour ce dépôt.
Instructions
Vérifiez que SignalRFunctionApp est en cours d’exécution.
Copiez l’URL générée par la fonction negotiate. Elle se présente comme suit :
http://localhost:7071/api/.Collez l’URL dans le fichier chat.js, à l’intérieur de
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.Exécutez l'application.
L’état est connecté lorsque le client web parvient à s’abonner au hub SignalR.
SendToQueue.js
Ce script node.js pousse un message vers le Service Bus pour pouvoir tester le déploiement que vous venez de terminer.
Instructions
Installez le module Azure Service Bus du nœud (@azure/service-bus).
Entrez vos chaînes de connexion et le nom de la file d’attente dans le script.
Exécutez le script.
Étapes suivantes
Vous pouvez utiliser ce scénario dans votre environnement de production. Toutefois, assurez-vous que vos services Azure sont configurés pour être mis à l’échelle. Par exemple, votre instance Azure Service Bus doit être définie sur un plan Standard ou Premium.
Vous pouvez déployer le code dans Azure Functions directement à partir de Visual Studio. Pour savoir comment publier votre code sur Azure Functions depuis Visual Studio, suivez le guide de création de logiciels.
Découvrez comment utiliser des liaisons Azure Service Bus dans Azure Functions. Azure Functions prend en charge les liaisons de déclencheur et de sortie pour les files d’attente et les rubriques Service Bus.
Découvrez comment authentifier et envoyer des messages en temps réel aux clients connectés au service Azure SignalR à l’aide des liaisons du service SignalR dans Azure Functions. Azure Functions prend en charge des liaisons d’entrée et de sortie pour le service SignalR.