Communication client et front-end

Conseil / Astuce

Ce contenu est un extrait de l’eBook, Architecting Cloud Native .NET Applications pour Azure, disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.

Télécharger le PDF

Dans un système natif cloud, les clients frontaux (applications mobiles, web et de bureau) nécessitent un canal de communication pour interagir avec des microservices back-end indépendants.

Quelles sont les options ?

Pour simplifier les choses, un client frontal peut communiquer directement avec les microservices principaux, illustré dans la figure 4-2.

Figure 4-2. Communication directe entre le client et le service

Avec cette approche, chaque microservice a un point de terminaison public accessible par les clients frontaux. Dans un environnement de production, vous placez un équilibreur de charge devant les microservices, en acheminant le trafic proportionnellement.

Bien que simple à implémenter, la communication directe du client serait acceptable uniquement pour les applications de microservice simples. Ce modèle couple étroitement les clients de l'interface utilisateur aux services principaux du système serveur, ce qui peut entraîner de nombreux problèmes, notamment :

• Sensibilité du client à la refactorisation du service back-end.
• Une surface d’attaque plus large car les services principaux du back-end sont directement exposés.
• Duplication des préoccupations transversales dans chaque microservice.
• Code client trop complexe : les clients doivent suivre plusieurs points de terminaison et gérer les défaillances de manière résiliente.

Au lieu de cela, un modèle de conception cloud largement accepté consiste à implémenter un service de passerelle d’API entre les applications frontales et les services principaux. Le modèle est illustré dans la figure 4-3.

Figure 4-3. Modèle de passerelle d’API

Dans la figure précédente, notez comment le service passerelle d’API extrait les microservices principaux principaux. Implémenté en tant qu’API web, il agit en tant que proxy inverse, en acheminant le trafic entrant vers les microservices internes.

La passerelle isole le client du partitionnement et de la refactorisation du service interne. Si vous modifiez un service back-end, vous l'adaptez dans la passerelle sans perturber le client. C’est également votre première ligne de défense pour les préoccupations transversales, telles que l’identité, la mise en cache, la résilience, le mesurage et la limitation. Nombre de ces préoccupations transversales peuvent être déléguées des services centraux du back-end à la passerelle, simplifiant ainsi les services de base.

Vous devez veiller à ce que la passerelle API soit simple et rapide. En règle générale, la logique métier est conservée hors de la passerelle. Une passerelle complexe risque de devenir un goulot d’étranglement et finalement un monolithe lui-même. Les systèmes plus volumineux exposent souvent plusieurs passerelles d’API segmentées par type de client (mobile, web, bureau) ou fonctionnalité back-end. Le modèle Back-end pour les serveurs frontaux fournit une direction pour l’implémentation de plusieurs passerelles. Le modèle est illustré dans la figure 4-4.

Figure 4-4. Modèle BFF (Backend for Frontends)

Notez dans la figure précédente comment le trafic entrant est envoyé à une passerelle d’API spécifique, en fonction du type de client : web, mobile ou application de bureau. Cette approche est logique, car les fonctionnalités de chaque appareil diffèrent considérablement entre le facteur de forme, les performances et les limitations d’affichage. En règle générale, les applications mobiles exposent moins de fonctionnalités qu’un navigateur ou une application de bureau. Chaque passerelle peut être optimisée pour correspondre aux capacités et aux fonctionnalités de l’appareil correspondant.

Passerelles simples

Pour commencer, vous pouvez créer votre propre service de passerelle d’API. Une recherche rapide de GitHub fournit de nombreux exemples.

Pour les applications natives cloud .NET simples, vous pouvez envisager la passerelle Ocelot. Open source et créé pour les microservices .NET, il est léger, rapide et évolutif. Comme n’importe quelle passerelle d’API, sa fonctionnalité principale consiste à transférer des requêtes HTTP entrantes vers des services en aval. En outre, il prend en charge un large éventail de fonctionnalités configurables dans un pipeline d’intergiciel .NET.

YARP (Encore un autre proxy inverse) est un autre proxy inverse open source dirigé par un groupe d’équipes de produits Microsoft. Téléchargeable en tant que package NuGet, YARP se connecte à l’infrastructure ASP.NET en tant que middleware et est hautement personnalisable. Vous trouverez yaRP bien documenté avec différents exemples d’utilisation.

Pour les applications cloud natives d’entreprise, plusieurs services Azure gérés peuvent vous aider à démarrer vos efforts.

Azure Application Gateway

Pour les exigences de passerelle simples, vous pouvez envisager Azure Application Gateway. Disponible en tant que service PaaS Azure, il inclut des fonctionnalités de passerelle de base telles que le routage d’URL, l’arrêt SSL et un pare-feu d’applications web. Le service prend en charge les capacités d’équilibrage de charge de la couche 7. Avec la couche 7, vous pouvez router les requêtes en fonction du contenu réel d’un message HTTP, pas seulement des paquets réseau TCP de bas niveau.

Tout au long de ce livre, nous évangélisons l’hébergement de systèmes natifs cloud dans Kubernetes. Un orchestrateur de conteneurs, Kubernetes automatise le déploiement, la mise à l’échelle et les problèmes opérationnels des charges de travail conteneurisées. Azure Application Gateway peut être configuré en tant que passerelle d’API pour un cluster Azure Kubernetes Service .

Le contrôleur d’entrée Application Gateway permet à Azure Application Gateway de fonctionner directement avec Azure Kubernetes Service. La figure 4.5 montre l’architecture.

Figure 4-5. Contrôleur d’entrée Application Gateway

Kubernetes inclut une fonctionnalité intégrée qui prend en charge l’équilibrage de charge HTTP (niveau 7), appelée Entrée. Ingress définit un ensemble de règles pour comment les instances de microservices à l’intérieur d’AKS peuvent être exposées au monde extérieur. Dans l’image précédente, le contrôleur d’entrée interprète les règles d’entrée configurées pour le cluster et configure automatiquement Azure Application Gateway. En fonction de ces règles, Application Gateway achemine le trafic vers les microservices s’exécutant à l’intérieur d’AKS. Le contrôleur d’entrée écoute les modifications apportées aux règles d’entrée et apporte les modifications appropriées à Azure Application Gateway.

Gestion des API Azure

Pour les systèmes natifs cloud modérés à grande échelle, vous pouvez envisager la gestion des API Azure. Il s’agit d’un service cloud qui résout non seulement vos besoins de passerelle d’API, mais qui offre une expérience de développement et d’administration complète. Gestion des API est illustrée dans la figure 4-6.

Figure 4-6. Gestion des API Azure

Pour démarrer, Gestion des API expose un serveur de passerelle qui autorise l’accès contrôlé aux services principaux en fonction des règles et stratégies configurables. Ces services peuvent se trouver dans le cloud Azure, votre centre de données local ou d’autres clouds publics. Les clés API et les jetons JWT déterminent qui peut faire quoi. Tout le trafic est journalisé à des fins analytiques.

Pour les développeurs, Gestion des API propose un portail de développement qui fournit l’accès aux services, à la documentation et à l’exemple de code pour les appeler. Les développeurs peuvent utiliser Swagger/Open API pour inspecter les points de terminaison de service et analyser leur utilisation. Le service fonctionne sur les principales plateformes de développement : .NET, Java, Golang, etc.

Le portail d’éditeur expose un tableau de bord de gestion où les administrateurs exposent les API et gèrent leur comportement. L'accès au service peut être autorisé, la santé du service surveillée et les données de télémétrie du service collectées. Les administrateurs appliquent des stratégies à chaque point de terminaison pour affecter le comportement. Les stratégies sont des instructions prédéfinies qui s’exécutent séquentiellement pour chaque appel de service. Les stratégies sont configurées pour un appel entrant, un appel sortant ou activées lors d'une erreur. Les stratégies peuvent être appliquées à différentes étendues de service pour activer l’ordre déterministe lors de la combinaison de stratégies. Le produit est fourni avec un grand nombre de politiques prédéfinies.

Voici des exemples de la façon dont les stratégies peuvent affecter le comportement de vos services cloud natifs :

• Restreindre l’accès au service.
• Appliquer l’authentification.
• Limitez les appels à partir d’une seule source, si nécessaire.
• Activer la mise en cache
• Bloquer les appels à partir d’adresses IP spécifiques.
• Contrôlez le flux du service.
• Convertissez les demandes de SOAP en REST ou entre différents formats de données, tels que xml en JSON.

Gestion des API Azure peut exposer des services principaux hébergés n’importe où , dans le cloud ou dans votre centre de données. Pour les services hérités que vous pouvez exposer dans vos systèmes natifs cloud, il prend en charge les API REST et SOAP. Même d’autres services Azure peuvent être exposés via Gestion des API. Vous pouvez placer une API managée au-dessus d’un service de stockage Azure comme Azure Service Bus ou Azure Logic Apps. La gestion des API Azure n’inclut pas la prise en charge intégrée de l’équilibrage de charge et doit être utilisée conjointement avec un service d’équilibrage de charge.

La gestion des API Azure est disponible dans quatre niveaux différents :

• Développeur
• Élémentaire
• Norme
• Haute qualité

Le niveau Développeur est destiné aux charges de travail et à l’évaluation hors production. Les autres niveaux offrent progressivement plus de puissance, de fonctionnalités et de contrats de niveau de service (SLA). Le niveau Premium fournit un réseau virtuel Azure et une prise en charge multirégion. Tous les niveaux ont un prix fixe par heure.

Le cloud Azure offre également un niveau serverless pour Gestion des API Azure. Appelé niveau tarifaire consommation, le service est une variante de Gestion d'API conçu autour du modèle de calcul sans serveur. Contrairement aux niveaux tarifaires « pré-alloués » précédemment indiqués, le niveau de consommation fournit des tarifs instantanés d’approvisionnement et de paiement par action.

Il active les fonctionnalités de passerelle d’API pour les cas d’usage suivants :

• Microservices implémentés à l’aide de technologies serverless telles qu’Azure Functions et Azure Logic Apps.
• Ressources de service annexe Azure telles que les files d’attente et rubriques Service Bus, le stockage Azure et autres.
• Microservices où le trafic connaît des pics occasionnels importants, mais reste faible la plupart du temps.

Le niveau de consommation utilise les mêmes composants de gestion des API de service sous-jacents, mais utilise une architecture entièrement différente basée sur des ressources allouées dynamiquement. Il s’aligne parfaitement avec le modèle informatique serverless :

• Aucune infrastructure à gérer.
• Aucune capacité inutilisée.
• Haute disponibilité.
• Mise à l’échelle automatique.
• Le coût est basé sur l’utilisation réelle.

Le nouveau niveau de consommation est un excellent choix pour les systèmes natifs cloud qui exposent des ressources serverless en tant qu’API.

Communication en temps réel

La communication en temps réel ou push est une autre option pour les applications frontales qui communiquent avec des systèmes natifs cloud back-end via HTTP. Les applications, telles que les indicateurs financiers, l'éducation en ligne, les jeux et les mises à jour de la progression de carrière, nécessitent des réponses en temps réel du serveur principal. Avec la communication HTTP normale, il n’existe aucun moyen pour le client de savoir quand de nouvelles données sont disponibles. Le client doit interroger ou envoyer continuellement des demandes au serveur. Avec la communication en temps réel , le serveur peut envoyer de nouvelles données au client à tout moment.

Les systèmes en temps réel sont souvent caractérisés par des flux de données à fréquence élevée et un grand nombre de connexions clientes simultanées. L’implémentation manuelle de la connectivité en temps réel peut rapidement devenir complexe, nécessitant une infrastructure non triviale pour garantir l’extensibilité et la messagerie fiable aux clients connectés. Vous pourriez vous retrouver à gérer une instance du Cache Redis Azure et un ensemble d'équilibreurs de charge configurés avec des sessions persistantes afin d'assurer l'affinité avec le client.

Azure SignalR Service est un service Azure entièrement managé qui simplifie la communication en temps réel pour vos applications natives cloud. Les détails de l’implémentation technique, tels que l’approvisionnement de capacité, la mise à l’échelle et les connexions persistantes, sont extraits. Ils sont gérés pour vous avec un contrat de niveau de service de 99,9 %. Vous vous concentrez sur les fonctionnalités d’application, et non sur la plomberie de l’infrastructure.

Une fois activé, un service HTTP basé sur le cloud peut envoyer des mises à jour de contenu directement aux clients connectés, y compris les applications de navigateur, mobiles et de bureau. Les clients sont mis à jour sans avoir à interroger le serveur. Azure SignalR extrait les technologies de transport qui créent la connectivité en temps réel, notamment WebSockets, Server-Side Events et Long Polling. Les développeurs se concentrent sur l’envoi de messages à tous les sous-ensembles ou spécifiques de clients connectés.

La figure 4-7 montre un ensemble de clients HTTP qui se connectent à une application native cloud avec Azure SignalR activé.

Figure 4-7. Azure SignalR

Un autre avantage d’Azure SignalR Service est l’implémentation de services natifs cloud serverless. Votre code est peut-être exécuté à la demande avec des déclencheurs Azure Functions. Ce scénario peut être difficile, car votre code ne conserve pas de longues connexions avec les clients. Azure SignalR Service peut gérer cette situation, car le service gère déjà les connexions pour vous.

Azure SignalR Service s’intègre étroitement à d’autres services Azure, tels qu’Azure SQL Database, Service Bus ou Redis Cache, ouvrant de nombreuses possibilités pour vos applications natives cloud.

PrécédentSuivant