Modèle de passerelle d’API par rapport à la communication directe entre le client et le microservice

2025-06-19

Conseil / Astuce

Ce contenu est un extrait du livre électronique 'Architecture des microservices .NET pour les applications .NET conteneurisées', disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement, lisible hors ligne.

Télécharger le PDF

Dans une architecture de microservices, chaque microservice expose un ensemble de points de terminaison affinés (généralement). Ce fait peut avoir un impact sur la communication client-à-microservice, comme expliqué dans cette section.

Communication directe entre le client et le microservice

Une approche possible consiste à utiliser une architecture directe de communication client-à-microservice. Dans cette approche, une application cliente peut effectuer des requêtes directement à certaines des microservices, comme illustré dans la figure 4-12.

Diagramme montrant l’architecture de communication client à microservice.

Figure 4-12. Utilisation d’une architecture directe de communication client-à-microservice

Dans cette approche, chaque microservice a un point de terminaison public, parfois avec un port TCP différent pour chaque microservice. Un exemple d’URL pour un service particulier peut être l’URL suivante dans Azure :

http://eshoponcontainers.westus.cloudapp.azure.com:88/

Dans un environnement de production basé sur un cluster, cette URL mappe à l’équilibreur de charge utilisé dans le cluster, qui distribue à son tour les requêtes entre les microservices. Dans les environnements de production, vous pouvez avoir un contrôleur de remise d’applications (ADC) comme Azure Application Gateway entre vos microservices et Internet. Cette couche agit comme un niveau transparent qui effectue non seulement l’équilibrage de charge, mais sécurise vos services en offrant une terminaison SSL. Cette approche améliore la charge de vos hôtes en déchargeant les tâches intensives en UC, comme la terminaison SSL et d’autres tâches de routage, vers la passerelle d'application Azure. Dans tous les cas, un équilibreur de charge et ADC sont transparents à partir d’un point de vue d’architecture d’application logique.

Une architecture de communication directe client à microservice peut être suffisante pour une petite application basée sur un microservice, en particulier si l’application cliente est une application web côté serveur comme une application MVC ASP.NET. Toutefois, lorsque vous créez des applications basées sur des microservices volumineuses et complexes (par exemple, lors de la gestion de dizaines de types de microservice), et surtout lorsque les applications clientes sont des applications mobiles distantes ou des applications web SPA, cette approche rencontre quelques problèmes.

Tenez compte des questions suivantes lors du développement d’une application volumineuse basée sur des microservices :

Comment les applications clientes peuvent-elles réduire le nombre de demandes adressées au serveur principal et réduire la communication chatteuse vers plusieurs microservices ?

L’interaction avec plusieurs microservices pour créer un seul écran d’interface utilisateur augmente le nombre d’allers-retours sur Internet. Cette approche augmente la latence et la complexité côté interface utilisateur. Dans l’idéal, les réponses doivent être agrégées efficacement côté serveur. Cette approche réduit la latence, car plusieurs éléments de données reviennent en parallèle et certaines interfaces utilisateur peuvent afficher les données dès qu’elles sont prêtes.

Comment pouvez-vous gérer des préoccupations croisées telles que l’autorisation, les transformations de données et la répartition des demandes dynamiques ?

L'implémentation de préoccupations transversales comme la sécurité et l'autorisation sur chaque microservice peut nécessiter des efforts de développement considérables. Une approche possible consiste à faire en sorte que ces services au sein de l’hôte Docker ou du cluster interne restreignent l’accès direct à ces services de l’extérieur et implémentent ces préoccupations croisées dans un emplacement centralisé, comme une passerelle API.

Comment les applications clientes peuvent-elles communiquer avec des services qui utilisent des protocoles non compatibles avec Internet ?

Les protocoles utilisés côté serveur (comme AMQP ou protocoles binaires) ne sont pas pris en charge dans les applications clientes. Par conséquent, les requêtes doivent être effectuées par le biais de protocoles tels que HTTP/HTTPS et traduites vers les autres protocoles par la suite. Une approche man-in-the-middle peut aider dans cette situation.

Comment pouvez-vous mettre en forme une façade spécialement faite pour les applications mobiles ?

L’API de plusieurs microservices peut ne pas être bien conçue pour les besoins de différentes applications clientes. Par exemple, les besoins d’une application mobile peuvent être différents des besoins d’une application web. Pour les applications mobiles, vous devrez peut-être optimiser encore davantage afin que les réponses aux données puissent être plus efficaces. Vous pouvez effectuer cette fonctionnalité en agrégeant les données de plusieurs microservices et en retournant un seul ensemble de données, et en éliminant parfois les données dans la réponse qui n’est pas nécessaire par l’application mobile. Et bien sûr, vous pouvez compresser ces données. Là encore, une façade ou une API entre l’application mobile et les microservices peuvent être pratiques pour ce scénario.

Pourquoi envisager des passerelles d’API au lieu de la communication directe entre le client et le microservice

Dans une architecture de microservices, les applications clientes doivent généralement consommer des fonctionnalités de plusieurs microservices. Si cette consommation est effectuée directement, le client doit gérer plusieurs appels aux points de terminaison de microservice. Que se passe-t-il lorsque l’application évolue et que de nouveaux microservices sont introduits ou que des microservices existants sont mis à jour ? Si votre application a de nombreux microservices, la gestion de tant de points de terminaison à partir des applications clientes peut être un cauchemar. Étant donné que l’application cliente serait couplée à ces points de terminaison internes, l’évolution des microservices à l’avenir peut entraîner un impact élevé pour les applications clientes.

Par conséquent, avoir un niveau ou une couche intermédiaire de redirection (passerelle) peut être utile pour les applications basées sur des microservices. Si vous n’avez pas de passerelles d’API, les applications clientes doivent envoyer des requêtes directement aux microservices et qui soulèvent des problèmes, tels que les problèmes suivants :

Couplage : sans le modèle de passerelle d’API, les applications clientes sont couplées aux microservices internes. Les applications clientes doivent savoir comment les plusieurs zones de l’application sont décomposées dans les microservices. Lors du développement ou de la refactorisation des microservices internes, ces actions ont un impact sur la maintenance car elles entraînent des modifications avec rupture dans les applications clientes en raison de la référence directe aux microservices internes à partir des applications clientes. Les applications clientes doivent être mises à jour fréquemment, ce qui rend la solution plus difficile à évoluer.
Trop d’allers-retours : une seule page/écran dans l’application cliente peut nécessiter plusieurs appels à plusieurs services. Cette approche peut entraîner plusieurs allers-retours réseau entre le client et le serveur, ce qui ajoute une latence significative. L’agrégation gérée dans un niveau intermédiaire peut améliorer les performances et l’expérience utilisateur de l’application cliente.
Problèmes de sécurité : sans passerelle, tous les microservices doivent être exposés au « monde externe », ce qui rend la surface d’attaque plus grande que si vous masquez les microservices internes qui ne sont pas directement utilisés par les applications clientes. Plus la surface d’attaque est petite, plus votre application peut être sécurisée.
Préoccupations croisées : chaque microservice publié publiquement doit gérer des problèmes tels que l’autorisation et SSL. Dans de nombreuses situations, ces préoccupations peuvent être gérées dans un seul niveau afin que les microservices internes soient simplifiés.

Qu’est-ce que le modèle de passerelle d’API ?

Lorsque vous concevez et créez des applications de microservice volumineuses ou complexes avec plusieurs applications clientes, une bonne approche à prendre en compte peut être une passerelle API. Ce modèle est un service qui fournit un point d’entrée unique pour certains groupes de microservices. Il est similaire au modèle façade à partir de la conception orientée objet, mais dans ce cas, il fait partie d’un système distribué. Le modèle de passerelle d’API est également parfois appelé « back-end pour le serveur frontal » (BFF), car vous le générez tout en réfléchissant aux besoins de l’application cliente.

Par conséquent, la passerelle d’API se trouve entre les applications clientes et les microservices. Elle agit comme un proxy inverse, en acheminant les requêtes des clients vers les services. Il peut également fournir d’autres fonctionnalités croisées telles que l’authentification, l’arrêt SSL et le cache.

La figure 4-13 montre comment une passerelle d’API personnalisée peut s’adapter à une architecture simplifiée basée sur des microservices avec seulement quelques microservices.

Diagramme montrant une passerelle d’API implémentée en tant que service personnalisé.

Figure 4-13. Utilisation d’une passerelle d’API implémentée en tant que service personnalisé

Les applications se connectent à un point de terminaison unique, la passerelle API, configurée pour transférer des requêtes à des microservices individuels. Dans cet exemple, la passerelle d’API serait implémentée en tant que service WebHost principal ASP.NET personnalisé s’exécutant en tant que conteneur.

Il est important de mettre en évidence que dans ce diagramme, vous utilisez un seul service de passerelle d’API personnalisé face à plusieurs applications clientes et différentes. Cela peut constituer un risque important, car votre service de passerelle d’API augmente et évolue en fonction de nombreuses exigences différentes des applications clientes. Finalement, elle sera gonflée en raison de ces besoins différents et peut être similaire à une application monolithique ou un service monolithique. C’est pourquoi il est très recommandé de fractionner la passerelle API dans plusieurs services ou plusieurs passerelles API plus petites, une par type de facteur de forme d’application cliente, par exemple.

Vous devez être prudent lors de l’implémentation du modèle de passerelle d’API. En règle générale, il n’est pas judicieux d’avoir une passerelle API unique agrégeant tous les microservices internes de votre application. Si c’est le cas, il agit en tant qu’agrégateur ou orchestrateur monolithique et enfreint l’autonomie des microservices en couplant tous les microservices.

Par conséquent, les passerelles d’API doivent être séparées en fonction des limites métier et des applications clientes et ne pas agir comme un agrégateur unique pour tous les microservices internes.

Quand vous divisez le niveau de la passerelle API en plusieurs passerelles API, si votre application a plusieurs applications clientes, cela peut être un pivot essentiel pour identifier les différents types de passerelles API, et pouvoir ainsi utiliser une façade différente selon les besoins de chaque application cliente. Ce cas est un modèle nommé « Backend for Frontend » (BFF), où chaque passerelle API peut fournir une API différente adaptée à chaque type d’application cliente, peut-être même en fonction du facteur de forme client en implémentant du code d’adaptateur spécifique qui sous appelle plusieurs microservices internes, comme illustré dans l’image suivante :

Diagramme montrant plusieurs passerelles d’API personnalisées.

Figure 4-13.1. Utilisation de plusieurs passerelles d’API personnalisées

La figure 4-13.1 montre les passerelles d’API séparées par type de client ; un pour les clients mobiles et un pour les clients web. Une application web traditionnelle se connecte à un microservice MVC qui utilise la passerelle d’API web. L’exemple illustre une architecture simplifiée avec plusieurs passerelles d’API affinées. Dans ce cas, les limites identifiées pour chaque passerelle API sont basées uniquement sur le modèle « Backend for Frontend » (BFF), donc en fonction de l’API nécessaire par application cliente. Toutefois, dans les applications plus volumineuses, vous devez également aller plus loin et créer d’autres passerelles d’API basées sur les limites de l’entreprise en tant que deuxième pivot de conception.

Principales fonctionnalités du modèle de passerelle d’API

Une passerelle d’API peut offrir plusieurs fonctionnalités. Selon le produit, il peut offrir des fonctionnalités plus riches ou plus simples, cependant, les fonctionnalités les plus importantes et fondamentales pour n’importe quelle passerelle API sont les modèles de conception suivants :

Routage inverse du proxy ou de la passerelle. La passerelle d’API offre un proxy inverse pour rediriger ou router des requêtes (routage de couche 7, généralement des requêtes HTTP) vers les points de terminaison des microservices internes. La passerelle fournit un point de terminaison unique ou une URL pour les applications clientes, puis mappe en interne les requêtes à un groupe de microservices internes. Cette fonctionnalité de routage permet de dissocier les applications clientes des microservices, mais il est également pratique de moderniser une API monolithique en plaçant la passerelle API entre l’API monolithique et les applications clientes, puis vous pouvez ajouter de nouvelles API en tant que nouvelles microservices tout en utilisant l’API monolithique héritée jusqu’à ce qu’elle soit divisée en plusieurs microservices à l’avenir. En raison de la passerelle d’API, les applications clientes ne remarqueront pas si les API utilisées sont implémentées en tant que microservices internes ou une API monolithique et, plus important encore, lors de l’évolution et de la refactorisation de l’API monolithique en microservices, grâce au routage de passerelle d’API, les applications clientes ne seront pas affectées par aucune modification d’URI.

Pour plus d’informations, consultez le modèle de routage de la passerelle.

Agrégation de requêtes. Dans le cadre du modèle de passerelle, vous pouvez agréger plusieurs requêtes clientes (généralement des requêtes HTTP) ciblant plusieurs microservices internes en une seule requête cliente. Ce modèle est particulièrement pratique lorsqu’une page cliente/écran a besoin d’informations à partir de plusieurs microservices. Avec cette approche, l’application cliente envoie une seule requête à la passerelle API qui distribue plusieurs requêtes aux microservices internes, puis agrège les résultats et renvoie tout ce qui est renvoyé à l’application cliente. Le principal avantage et l’objectif de ce modèle de conception est de réduire les conversations entre les applications clientes et l’API back-end, ce qui est particulièrement important pour les applications distantes hors du centre de données où les microservices sont en direct, comme les applications mobiles ou les demandes provenant d’applications SPA provenant d’applications JavaScript dans les navigateurs distants clients. Pour les applications web standard effectuant les requêtes dans l’environnement serveur (comme une application web ASP.NET Core MVC), ce modèle n’est pas si important que la latence est beaucoup plus petite que pour les applications clientes distantes.

Selon le produit de passerelle d’API que vous utilisez, il peut être en mesure d’effectuer cette agrégation. Toutefois, dans de nombreux cas, il est plus flexible de créer des microservices d’agrégation sous l’étendue de la passerelle API, de sorte que vous définissez l’agrégation dans le code (c’est-à-dire le code C#) :

Pour plus d’informations, consultez le modèle d'agrégation de passerelles.

Problèmes transversaux ou déchargement de passerelle. Selon les fonctionnalités offertes par chaque produit de passerelle d’API, vous pouvez décharger les fonctionnalités de microservices individuels vers la passerelle, ce qui simplifie l’implémentation de chaque microservice en regroupant les préoccupations croisées en un seul niveau. Cette approche est particulièrement pratique pour les fonctionnalités spécialisées qui peuvent être complexes à implémenter correctement dans chaque microservice interne, comme les fonctionnalités suivantes :

Authentification et autorisation
Intégration de la découverte de service
Mise en cache des réponses
Stratégies de nouvelle tentative, disjoncteur et QoS
Limitation du débit
Équilibrage de la charge
Journalisation, suivi, corrélation
Transformation des en-têtes, chaînes de requête et revendications
Liste d'adresses IP autorisées

Pour plus d’informations, consultez Modèle de déchargement de passerelle.

Utilisation de produits avec des fonctionnalités de passerelle d’API

Il peut y avoir de nombreuses autres préoccupations de coupe croisée offertes par les produits API Gateways en fonction de chaque implémentation. Nous allons explorer ici :

Gestion des API Azure

Gestion des API Azure (comme illustré dans la figure 4-14) non seulement résout vos besoins de passerelle d’API, mais fournit des fonctionnalités telles que la collecte d’insights à partir de vos API. Si vous utilisez une solution de gestion des API, une passerelle API n’est qu’un composant dans cette solution complète de gestion des API.

Diagramme montrant comment utiliser Gestion des API Azure comme passerelle d’API.

Figure 4-14. Utilisation de Gestion des API Azure pour votre passerelle API

Gestion des API Azure résout à la fois vos besoins de passerelle d’API et de gestion, comme la journalisation, la sécurité, le contrôle, etc. Dans ce cas, lorsque vous utilisez un produit comme Gestion des API Azure, le fait que vous avez peut-être une passerelle API unique n’est pas si risqué, car ces types de passerelles d’API sont « plus minces », ce qui signifie que vous n’implémentez pas de code C# personnalisé qui pourrait évoluer vers un composant monolithique.

Les produits API Gateway agissent généralement comme un proxy inverse pour la communication d’entrée, où vous pouvez également filtrer les API des microservices internes et appliquer l’autorisation aux API publiées à ce niveau unique.

Les insights disponibles à partir d’un système de gestion des API vous aident à comprendre comment vos API sont utilisées et comment elles fonctionnent. Ils effectuent cette activité en vous permettant d’afficher des rapports d’analyse en temps quasi réel et d’identifier les tendances susceptibles d’avoir un impact sur votre entreprise. De plus, vous pouvez avoir des journaux sur l’activité de demande et de réponse pour une analyse en ligne et hors connexion.

Avec Gestion des API Azure, vous pouvez sécuriser vos API à l’aide d’une clé, d’un jeton et d’un filtrage IP. Ces fonctionnalités vous permettent d’appliquer des quotas flexibles et affinés et des limites de débit, de modifier la forme et le comportement de vos API à l’aide de stratégies et d’améliorer les performances avec la mise en cache des réponses.

Dans ce guide et l’exemple d’application de référence (eShopOnContainers), l’architecture est limitée à une architecture conteneurisée plus simple et personnalisée afin de se concentrer sur des conteneurs simples sans utiliser de produits PaaS comme Gestion des API Azure. Toutefois, pour les applications volumineuses basées sur des microservice déployées dans Microsoft Azure, nous vous encourageons à évaluer Gestion des API Azure comme base pour vos passerelles API en production.

Ocelot

Ocelot est une passerelle API légère, recommandée pour des approches plus simples. Ocelot est une passerelle d’API open source .NET Core spécialement faite pour les architectures de microservices qui nécessitent des points d’entrée unifiés dans leurs systèmes. Il est léger, rapide et évolutif et fournit un routage et une authentification parmi de nombreuses autres fonctionnalités.

La principale raison de choisir Ocelot pour l’application de référence eShopOnContainers 2.0 est que Ocelot est une passerelle d’API légère .NET Core que vous pouvez déployer dans le même environnement de déploiement d’application où vous déployez vos microservices/conteneurs, comme un hôte Docker, Kubernetes, etc. Et comme il est basé sur .NET Core, il est multiplateforme vous permettant de déployer sur Linux ou Windows.

Les diagrammes précédents montrant des passerelles d’API personnalisées s’exécutant dans des conteneurs sont précisément la façon dont vous pouvez également exécuter Ocelot dans une application basée sur un conteneur et un microservice.

En outre, il existe de nombreux autres produits dans le marché offrant des fonctionnalités API Gateways, telles que Apigee, Kong, MuleSoft, WSO2 et d’autres produits tels que Linkerd et Istio pour les fonctionnalités du contrôleur d’entrée de maillage de service.

Après les sections d’explication de l’architecture et des modèles initiaux, les sections suivantes expliquent comment implémenter des passerelles API avec Ocelot.

Inconvénients du modèle de passerelle d’API

L’inconvénient le plus important est que lorsque vous implémentez une passerelle API, vous associez cette couche aux microservices internes. Le couplage comme celui-ci peut entraîner de graves difficultés pour votre application. Clemens Vaster, architecte de l’équipe Azure Service Bus, fait référence à cette difficulté potentielle comme « la nouvelle ESB » dans la session « Messagerie et microservices » à GOTO 2016.
L’utilisation d’une passerelle d’API de microservices crée un point de défaillance unique supplémentaire.
Une passerelle API peut introduire un temps de réponse accru en raison de l’appel réseau supplémentaire. Toutefois, cet appel supplémentaire a généralement moins d’impact que d’avoir une interface cliente trop bavardante appelant directement les microservices internes.
Si elle n’est pas étendue correctement, la passerelle API peut devenir un goulot d’étranglement.
Une passerelle d’API nécessite des coûts de développement supplémentaires et une maintenance future si elle inclut une logique personnalisée et une agrégation de données. Les développeurs doivent mettre à jour la passerelle API pour exposer les points de terminaison de chaque microservice. En outre, les modifications d’implémentation dans les microservices internes peuvent entraîner des modifications de code au niveau de la passerelle API. Toutefois, si la passerelle API applique simplement la sécurité, la journalisation et le contrôle de version (comme lors de l’utilisation de Gestion des API Azure), ce coût de développement supplémentaire peut ne pas s’appliquer.
Si la passerelle d’API est développée par une seule équipe, il peut y avoir un goulot d’étranglement de développement. Cet aspect est une autre raison pour laquelle une meilleure approche consiste à avoir plusieurs passerelles API affinées qui répondent aux différents besoins du client. Vous pouvez également séparer la passerelle API en interne en plusieurs zones ou couches détenues par les différentes équipes travaillant sur les microservices internes.