Modèle d’agrégation de passerelles

Utilisez une passerelle pour agréger plusieurs requêtes individuelles dans une requête unique. Ce modèle est utile lorsqu’un client doit effectuer plusieurs appels à différents systèmes principaux pour effectuer une opération.

Contexte et problème

Pour effectuer une tâche unique, un client peut avoir à effectuer plusieurs appels à différents services back-end. Une application qui a besoin de nombreux services pour effectuer une tâche doit étendre ses ressources pour chaque requête. Lorsque de nouvelles fonctionnalités ou services sont ajoutés à l’application, des demandes supplémentaires sont nécessaires, ce qui augmente davantage les besoins en ressources et les appels réseau. Cette conversation entre un client et un back-end peut affecter négativement les performances et l’échelle de l’application. Les architectures de microservices ont rendu ce problème plus courant, car les applications créées autour de nombreux services plus petits ont un plus grand nombre d’appels interservices.

Dans le diagramme suivant, le client envoie des demandes à chaque service (numéroté 1, 2 et 3). Chaque service traite la demande et retourne une réponse à l’application (numérotée 4, 5 et 6). L’envoi de requêtes individuelles de cette façon sur un réseau cellulaire présentant une latence élevée est inefficace et peut entraîner une perte de connectivité ou des réponses incomplètes. Chaque requête peut s’exécuter en parallèle. Toutefois, l’application doit toujours envoyer, attendre et traiter des données pour chaque requête sur des connexions distinctes, ce qui augmente le risque d’échec.

Solution

Utilisez une passerelle pour réduire les échanges excessifs entre le client et les services. La passerelle reçoit les demandes du client, distribue les demandes aux différents systèmes principaux et agrège les résultats avant de les renvoyer au client.

Ce modèle peut réduire le nombre de requêtes effectuées par l’application aux services principaux et améliorer les performances des applications sur les réseaux à latence élevée.

Dans le diagramme suivant, l’application envoie une requête à la passerelle (1). La requête contient un package de requêtes supplémentaires. La passerelle décompose ces demandes et traite chaque requête en l’envoyant au service approprié (2). Chaque service renvoie une réponse à la passerelle (3). La passerelle combine les réponses de chaque service et envoie la réponse finale à l’application (4). L’application envoie une seule requête et reçoit une seule réponse de la passerelle.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

La passerelle ne doit pas introduire de couplage de service entre les services principaux.
La passerelle doit se trouver près des services principaux pour réduire la latence autant que possible.
Le service de passerelle peut introduire un point de défaillance unique (SPoF). Vérifiez que la passerelle est correctement conçue pour répondre aux exigences de disponibilité de votre application.
La passerelle peut introduire un goulot d’étranglement. Assurez-vous que la passerelle dispose de performances adéquates pour gérer la charge actuelle et qu’elle peut être mise à l’échelle pour répondre à votre croissance prévue.
Effectuez des tests de charge sur la passerelle pour vous assurer que vous n’introduisez pas de défaillances en cascade pour les services.
Implémentez une conception résiliente à l’aide de techniques telles que les cloisons, les ruptures de circuit, les nouvelles tentatives et les délais d’expiration.
Si un ou plusieurs appels de service prennent trop de temps, il peut être acceptable d’interrompre l’attente après expiration du délai et de renvoyer un jeu partiel de données. Réfléchissez à la manière dont votre application va gérer ce scénario.
Utilisez l’entrée et la sortie asynchrones (E/S) pour vous assurer qu’un délai au niveau du serveur principal n’entraîne pas de problèmes de performances dans l’application.
Implémentez le suivi distribué à l’aide d’ID de corrélation pour suivre chaque appel individuel.
Contrôlez les métriques des requêtes et les tailles des réponses.
Envisagez d’appliquer une stratégie de basculement consistant à renvoyer les données en cache afin de gérer les échecs.
Au lieu d’intégrer l’agrégation à la passerelle, envisagez plutôt de placer un service d’agrégation derrière la passerelle. L’agrégation de requêtes est susceptible d’avoir des besoins en ressources différents de ceux d’autres services de la passerelle et peut affecter la fonctionnalité de routage et de déchargement de la passerelle.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

Un client doit communiquer avec plusieurs services principaux pour effectuer une opération.
Le client peut utiliser des réseaux qui ont une latence importante, comme les réseaux cellulaires.

Ce modèle peut ne pas convenir lorsque :

Vous souhaitez réduire le nombre d’appels entre un client et un service unique dans le cadre de plusieurs opérations. Dans ce scénario, l’ajout d’une opération de traitement par lots au service peut être plus approprié.
Le client ou l’application se trouve près des services principaux et la latence n’est pas un facteur significatif.

Conception de la charge de travail

Évaluez comment utiliser le modèle d'agrégation de passerelle dans la conception d'une charge de travail pour répondre aux objectifs et principes abordés dans les piliers Azure Well-Architected Framework. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.

Pilier	Comment ce modèle soutient les objectifs des piliers.
Les décisions de conception de fiabilité aident votre charge de travail à devenir résiliente au dysfonctionnement et à s’assurer qu’elle se rétablit dans un état entièrement opérationnel après une défaillance.	Avec cette topologie, vous pouvez déplacer la gestion des erreurs temporaires d’une implémentation distribuée entre les clients et une implémentation centralisée. - Recommandations relatives à la gestion des erreurs temporaires
Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail.	Cette topologie réduit souvent le nombre de points tactiles qu’un client a avec un système, ce qui réduit la surface d’exposition publique et les points d’authentification. Les back-ends agrégés peuvent rester entièrement isolés du réseau des clients. - SE:04 Segmentation - SE:08 Sécuriser les ressources
L’excellence opérationnelle permet de fournir une qualité de charge de travail grâce à des processus standardisés et à la cohésion de l’équipe.	Ce modèle permet à la logique back-end d’évoluer indépendamment des clients. Ce découplage vous offre la possibilité de modifier les implémentations de service chaînées, ou même les sources de données, sans avoir à modifier les points de contact client. - OE :04 Outils et processus
L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes par le biais d’optimisations de la mise à l’échelle, des données et du code.	Cette conception peut entraîner une latence moins importante qu’une conception dans laquelle le client établit plusieurs connexions. La mise en cache dans les implémentations d’agrégation réduit les appels aux systèmes principaux. - PE :03 Sélectionner des services - PE :08 Performance des données

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Example

Envisagez une application basée sur des microservices qui fournit une expérience récapitulative de commande pour un client. Lorsqu’un utilisateur ouvre une page de commande, l’application doit récupérer des données à partir de plusieurs services principaux, tels qu’un service de commande, un service d’expédition et un service de profil client.

Dans une architecture de microservices, ces services sont implémentés et déployés indépendamment. Sans agrégation, le client doit appeler directement chaque service, ce qui augmente la latence et la complexité.

Pour résoudre ce problème, l’application utilise Gestion des API Azure comme couche d’agrégation de passerelle. Le client envoie une requête unique à une opération Gestion des API qui agit en tant que collecteur pour les informations de commande. Gestion des API appelle ensuite les API principales de prise en charge et retourne une réponse unifiée au client.

Vous pouvez implémenter cette composition légère à l’aide de la stratégie de demande d’envoi de gestion des API pour récupérer des données à partir de plusieurs services et construire une réponse combinée. Dans cet exemple, les services principaux s’exécutent dans un environnement Azure Container Apps et vous déployez chaque service principal en tant qu’application conteneur qui reste masquée de l’accès direct au client.

Téléchargez un fichier Visio de cette architecture.

Le flux de requête suit les étapes suivantes :

Le client envoie une requête à un point de terminaison du résumé de commande exposé par l’intermédiaire d’API Management.
Gestion des API applique une stratégie qui collecte les données de commande, d’expédition et de profil client à partir des services principaux.
API Management regroupe les réponses du back-end dans un payload unique de récapitulatif de commande.
Gestion des API retourne la réponse agrégée au client.

En introduisant cette couche d’agrégation, la solution réduit les allers-retours client-à-service et simplifie les interactions des clients. Cette couche est chargée de gérer de façon robuste les services back-end qui ne répondent pas et d’empêcher les défaillances de se propager à l’ensemble de la réponse agrégée. Renforcer vos stratégies gestion des API à l’aide de délais d’expiration par requête, de gestion des erreurs conditionnelles et de disjoncteurs.

Si l’un des appels au back-end dépasse le délai d’attente ou renvoie une erreur, API Management peut appliquer le comportement le plus adapté à l’opération. Par exemple, il peut retourner une réponse partielle lorsque des données manquantes sont acceptables, ou il peut échouer l’intégralité de la requête lorsque des données de commande complètes et cohérentes sont requises. Prenez cette décision explicitement dans la conception de stratégie afin que les clients subissent un comportement prévisible.

Cette approche fonctionne bien lorsque la passerelle effectue une composition légère, une mise en forme et un assembly de réponse. Si l’agrégation nécessite une logique de domaine personnalisée, des transformations complexes ou une orchestration plus longue, placez cette fonctionnalité dans un service personnalisé dédié derrière la passerelle.

Pour la surveillance, collectez les données de télémétrie sur le chemin de requête complet afin de pouvoir mettre en corrélation le comportement de gestion des API avec la latence principale. Cette visibilité est importante dans un modèle d’agrégation de passerelle, car une seule opération cliente dépend de plusieurs appels principaux, et des échecs ou des réponses lentes dans n’importe quelle dépendance peuvent affecter le résultat agrégé final. Utilisez Azure Monitor comme plateforme d’observabilité centrale. Collectez les journaux et les métriques d’API Management pour la passerelle et le chemin d’exécution des stratégies, et activez la supervision de Container Apps afin de collecter les journaux et les métriques des applications conteneurisées back-end. Acheminer la gestion des API et les données de télémétrie back-end vers un espace de travail Log Analytics pour les requêtes unifiées, les alertes et la résolution des problèmes. Avec cette télémétrie, vous pouvez détecter des schémas d’expiration, identifier la dépendance du back-end à l’origine d’une réponse partielle ou d’un échec de réponse, et créer des alertes en cas de latence élevée ou de taux d’erreur élevés.

Étapes suivantes

Backends for Frontends pattern (Modèle de backends pour frontends)
Schéma de déchargement de passerelle
Modèle de routage de passerelle

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-06-03