Communication client et front-end

Conseil

Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.

Télécharger le PDF

Dans un système natif cloud, les clients front-end (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 front-end peut communiquer directement avec les microservices back-end, comme illustré dans la figure 4-2.

Figure 4-2. Communication directe de client à service

Avec cette approche, chaque microservice dispose d’un point de terminaison public accessible par les clients front-end. Dans un environnement de production, vous placez un équilibreur de charge devant les microservices, en acheminant le trafic de façon proportionnelle.

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 front-end aux principaux services back-end, ouvrant la porte à de nombreux problèmes, notamment :

• Sensibilité du client à la refactorisation des services back-end.
• Plus grande surface d’attaque puisque les principaux services back-end sont directement exposés.
• Duplication des préoccupations transversales sur chaque microservice.
• Code client trop complexe - Les clients doivent assurer le suivi de plusieurs points de terminaison et gérer les défaillances de façon résiliente.

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

Figure 4-3. Modèle de passerelle API

Dans la figure précédente, notez comment le service de passerelle API extrait les principaux microservices back-end. Implémenté en tant qu’API web, il fait office de 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 pouvez le prendre en charge dans la passerelle sans affecter le client. C’est aussi votre première ligne de défense pour les préoccupations transversales, telles que les identités, la mise en cache, la résilience, les mesures et les limitations. La plupart de ces préoccupations transversales peuvent être déchargées des principaux services back-end pour être mises sur la passerelle, ce qui simplifie les services back-end.

Veillez à ce que la passerelle API reste simple et rapide. En règle générale, la logique métier est laissée en dehors de la passerelle. Une passerelle complexe risque de devenir un goulot d’étranglement et de finir elle-même en monolithe. Les systèmes plus gros exposent souvent plusieurs passerelles API segmentées par type de client (mobile, web, bureau) ou fonctionnalité back-end. Le modèle BFF (Backend for Frontends) fournit des consignes pour implémenter 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 API spécifique, en fonction du type de client : application web, mobile ou de bureau. Cette approche est logique, car les fonctionnalités de chaque appareil diffèrent considérablement selon 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 des applications 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 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éée pour les microservices .NET, elle est légère, rapide et évolutive. Comme n’importe quelle passerelle API, sa fonctionnalité principale consiste à transférer les requêtes HTTP entrantes aux services en aval. De plus, elle prend en charge un grand choix de fonctionnalités configurables dans un pipeline de middleware .NET.

YARP (Yet Another Reverse Proxy) est un autre proxy inverse open source dirigé par un groupe d’équipes de produits Microsoft. Téléchargeable sous forme de package NuGet, YARP se connecte au framework ASP.NET en tant que middleware et est très personnalisable. Vous trouverez YARP bien documenté avec différents exemples d’utilisation.

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

Azure Application Gateway

Si vous avez besoin d’une passerelle simple, vous pouvez envisager Azure Application Gateway. Disponible en tant que service PaaS Azure, il comprend des fonctionnalités de passerelle de base comme le routage d’URL, l’arrêt SSL et un pare-feu d’applications web. Le service prend en charge les fonctionnalités d’équilibrage de charge Couche 7. Avec la couche 7, vous pouvez acheminer les demandes en fonction du contenu d’un message HTTP, pas seulement les paquets réseau TCP de bas niveau.

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

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

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

Kubernetes comprend une fonctionnalité intégrée qui prend en charge l’équilibrage de charge HTTP (niveau 7), appelée Ingress. Ingress définit un ensemble de règles pour l’exposition des instances de microservice dans AKS au monde extérieur. Dans l’image précédente, le contrôleur d’entrée interprète les règles Ingress 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 exécutés dans AKS. Le contrôleur d’entrée écoute les modifications apportées aux règles Ingress et apporte les modifications appropriées à Azure Application Gateway.

Gestion des API Azure

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

Figure 4-6. Gestion des API Azure

Pour commencer, la Gestion des API expose un serveur de passerelle qui autorise un accès contrôlé aux services back-end 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, la Gestion des API propose un portail des développeurs 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 des éditeurs expose un tableau de bord de gestion dans lequel les administrateurs exposent des API et gèrent leur comportement. L’accès au service peut être accordé, l’intégrité du service surveillée et la télémétrie du service collectée. 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 de manière séquentielle pour chaque appel de service. Les stratégies sont configurées pour un appel entrant, un appel sortant ou appelées en cas d’erreur. Les stratégies peuvent être appliquées à différentes étendues du service pour avoir un ordre déterministe lorsqu’elles sont combinées. Le produit est fourni avec un grand nombre de stratégies prédéfinies.

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

• Restreindre l’accès au service.
• Appliquer une authentification.
• Limiter les appels à partir d’une seule source, si nécessaire.
• Activation de la mise en cache.
• Bloquer les appels à partir d’adresses IP spécifiques.
• Contrôler le flux du service.
• Convertir les demandes de SOAP en REST ou entre différents formats de données, par exemple de XML en JSON.

La Gestion des API Azure peut exposer des services back-end 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, elle prend en charge les API REST et SOAP. Même d’autres services Azure peuvent être exposés via la Gestion des API. Vous pourriez placer une API managée sur un service annexe Azure comme Azure Service Bus ou Azure Logic Apps. La Gestion des API Azure ne comprend pas de 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 sur quatre niveaux différents :

• Développeur
• De base
• standard
• Premium

Le niveau Développeur est destiné aux charges de travail de non-production et à l’évaluation. Les autres niveaux offrent progressivement plus de puissance, plus de fonctionnalités et des contrats de niveau de service (SLA) supérieurs. 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 la Gestion des API Azure. Appelé niveau tarifaire Consommation, le service est une variante de la Gestion des API conçue autour du modèle informatique serverless. Contrairement aux niveaux tarifaires « pré-alloués » précédemment montrés, le niveau Consommation fournit des tarifs de provisionnement instantané et de paiement à l’action.

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

• Microservices implémentés avec des technologies serverless comme 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 présente des pics occasionnels, mais qui reste bas la plupart du temps.

Le niveau Consommation utilise les mêmes composants Gestion des API de service sous-jacents, mais fait appel à une architecture entièrement différente basée sur des ressources allouées de façon dynamique. Il est parfaitement adapté au modèle informatique serverless :

• Aucune infrastructure à gérer
• Aucune capacité inactive.
• Haute disponibilité.
• Mise à l’échelle automatique.
• Coût basé sur l’utilisation réelle.

Le nouveau niveau 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 front-end qui communiquent avec des systèmes natifs cloud back-end via HTTP. Les applications, telles que les cotes boursières, l’enseignement en ligne, les jeux et les mises à jour de progression du travail, nécessitent des réponses instantanées en temps réel du back-end. Avec une communication HTTP normale, il n’existe aucun moyen pour le client de savoir quand de nouvelles données sont disponibles. Le client doit continuellement interroger ou envoyer des demandes au serveur. Avec une communication en temps réel, le serveur peut pousser 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 haute fréquence et un grand nombre de connexions clientes simultanées. L’implémentation manuelle de la connectivité en temps réel peut rapidement devenir complexe, car elle nécessite une infrastructure plus élaborée pour garantir une scalabilité et des messages fiables 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 pour l’affinité de client.

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

Une fois activé, un service HTTP basé sur le cloud peut pousser des mises à jour de contenu directement aux clients connectés, notamment les applications de navigateur, mobiles et de bureau. Les clients sont mis à jour sans avoir besoin d’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 clients connectés ou à des groupes spécifiques.

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 complexe parce que votre code ne maintient pas les connexions longues aux clients. Le service Azure SignalR est en mesure de gérer cette situation, car il gère déjà les connexions à votre place.

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

PrécédentSuivant