Dans une architecture microservices, un client peut interagir avec plusieurs services frontaux. Dans ce cas, comment un client sait-il quels points de terminaison appeler ? Que se passe-t-il lors de l’introduction de nouveaux services ou lorsque des services existants sont refactorisés ? Comment les services gèrent-ils l’arrêt SSL, l’authentification et les autres problèmes ? Une passerelle d’API permet de relever ces défis.
Téléchargez un fichier Visio de cette architecture.
Qu'est-ce qu'une passerelle d'API ?
Une passerelle d’API se situe entre les clients et les services. Elle agit comme un proxy inverse, en acheminant les requêtes des clients vers les services. Elle peut également effectuer diverses tâches transversales telles que l’authentification, l’arrêt SSL et la limitation du débit. Si vous ne pouvez pas déployer de passerelle, les clients doivent envoyer des requêtes directement aux services frontaux. Toutefois, il existe certains problèmes potentiels relatifs à l’exposition directe des services aux clients :
- Elle peut entraîner un code client complexe. Le client doit effectuer le suivi de plusieurs points de terminaison et gérer les échecs de façon résiliente.
- Elle crée un couplage entre le client et le serveur principal. Le client doit connaître la façon dont les services individuels sont décomposés. Cela rend plus difficiles la maintenance du client et la refactorisation des services.
- Une seule opération peut nécessiter des appels à plusieurs services. Cela peut entraîner plusieurs allers-retours réseau entre le client et le serveur, ajoutant ainsi une latence importante.
- Chaque service public doit gérer des problèmes tels que l’authentification, le SSL et la limitation du débit client.
- Les services doivent exposer un protocole pratique pour le client, comme HTTP ou WebSocket. Cela limite le choix des protocoles de communication.
- Les services avec des points de terminaison publics représentent une surface d’attaque potentielle et doivent être renforcés.
Une passerelle permet de résoudre ces problèmes en dissociant les clients des services. Les passerelles peuvent exécuter un certain nombre de fonctions différentes, et vous n’aurez peut-être pas besoin de toutes. Les fonctions peuvent être regroupées dans les modèles de conception suivants :
Routage de passerelle : utilisez la passerelle comme un proxy inverse pour acheminer les requêtes vers un ou plusieurs services principaux, à l’aide du routage de couche 7. La passerelle fournit un point de terminaison unique pour les clients et permet de découpler les clients des services.
Agrégation de passerelle : utilisez la passerelle pour agréger plusieurs requêtes individuelles dans une requête unique. Ce modèle s’applique lorsqu’une opération requiert des appels à plusieurs services principaux. Le client envoie une seule requête à la passerelle. La passerelle répartit les requêtes entre les différents services principaux, puis agrège les résultats et les renvoie au client. Cela permet de réduire les échanges excessifs entre le client et les services principaux.
Déchargement de passerelle : utilisez la passerelle pour décharger des fonctionnalités à partir des services individuels vers la passerelle, en particulier les problèmes transversaux. Il peut être utile de regrouper ces fonctions à un seul endroit, plutôt que de confier leur mise en œuvre à chaque service. C’est particulièrement vrai pour les fonctionnalités dont la bonne implémentation nécessite des compétences particulières, telles que l’authentification et l’autorisation.
Voici quelques exemples de fonctionnalités qui peuvent être déchargées sur une passerelle :
- Arrêt SSL
- Authentification
- Liste d’adresses IP autorisées ou bloquées
- Limitation du débit client
- Enregistrement et surveillance
- Mise en cache des réponses
- Pare-feu d’application web
- Compression GZIP
- Maintenance du contenu statique
Choix d’une technologie de passerelle
Voici quelques options justifiant l’implémentation d’une passerelle d’API dans votre application.
Serveur proxy inverse : Nginx et HAProxy sont des serveurs proxy inverse courants qui prennent en charge des fonctionnalités telles que l’équilibrage de charge, le SSL et le routage de couche 7. Tous deux sont des produits libres et open source, avec des éditions payantes qui fournissent des fonctionnalités supplémentaires et des options de support. Nginx et HAProxy sont des produits matures, dotés de riches ensembles de fonctionnalités et aux hautes performances. Vous pouvez les étendre avec des modules tiers ou en écrivant des scripts personnalisés dans Lua. Nginx prend également en charge un module de création de script basé sur JavaScript appelé « NGINX JavaScript ». L'ancien nom de ce module était nginScript.
Contrôleur d’entrée de maillage de service : Si vous utilisez un maillage de service tel que Linkerd ou Istio, considérez les fonctionnalités fournies par le contrôleur d’entrée de ce service de maillage. Par exemple, le contrôleur d’entrée Istio prend en charge le routage de couche 7, les redirections HTTP, les nouvelles tentatives et d’autres fonctionnalités.
Azure Application Gateway : Application Gateway est un service managé d’équilibrage de charge qui peut exécuter un routage de couche 7et un arrêt SSL. Il fournit également un pare-feu d’application web (WAF).
Azure Front Door est le cloud réseau de distribution de contenu moderne de Microsoft (CDN) qui offre un accès rapide, fiable et sécurisé entre vos utilisateurs et le contenu web statique et dynamique de vos applications dans le monde entier. Azure Front Door fournit votre contenu à l’aide du réseau de périmètre mondial de Microsoft, avec des centaines de points de présence globaux et locaux répartis dans le monde entier près des utilisateurs finaux de votre entreprise et de vos utilisateurs finaux consommateurs.
Azure API Management : API Management est une solution clé en main pour la publication d’API à destination des clients internes et externes. Elle fournit des fonctionnalités utiles à la gestion d’une API publique, notamment la limitation de débit, les restrictions d’adresse IP et l’authentification via Microsoft Entra ID ou d’autres fournisseurs d’identité. API Management n’effectue aucun équilibrage de charge. Par conséquent, elle doit être utilisée conjointement à un équilibreur de charge, tel qu’Application Gateway ou un proxy inverse. Pour plus d'informations sur l'utilisation de la Gestion des API avec Application Gateway, consultez Intégration de la Gestion des API dans un réseau virtuel interne avec Application Gateway.
Lors du choix d’une technologie de passerelle, considérez les points suivants :
Features. les options répertoriées ci-dessus prennent en charge le routage de couche 7, mais la prise en charge des autres fonctionnalités varie. Selon les fonctionnalités dont vous avez besoin, vous pouvez déployer plusieurs passerelles.
Déploiement. Azure Application Gateway et API Management sont des services managés. Nginx et HAProxy s’exécutent généralement dans des conteneurs situés à l’intérieur du cluster, mais ils peuvent également être déployés vers des machines virtuelles dédiées en dehors du cluster. Cela isole la passerelle du reste de la charge de travail, mais entraîne une surcharge de gestion plus élevée.
Gestion : lors de l’ajout ou de la mise à jour de services, les règles de routage de passerelle peuvent nécessiter une mise à jour. Envisagez le mode de gestion de ce processus. Des considérations similaires s’appliquent à la gestion des certificats SSL, des listes d’adresses IP autorisées et d’autres aspects de la configuration.
Déploiement Nginx ou HAProxy vers Kubernetes
Vous pouvez déployer Nginx ou HAProxy sur Kubernetes en tant que ReplicaSet ou DaemonSet qui spécifie l’image de conteneur Nginx ou HAProxy. Utilisez un élément ConfigMap pour stocker le fichier de configuration du proxy et montez l’élément ConfigMap en tant que volume. Créez un service de type LoadBalancer pour exposer la passerelle via un équilibreur de charge Azure.
Une alternative consiste à créer un contrôleur d’entrée. Un contrôleur d’entrée est une ressource Kubernetes qui déploie un équilibreur de charge ou un serveur proxy inverse. Plusieurs implémentations existent, y compris Nginx et HAProxy. Une ressource séparée appelée « entrée » définit des paramètres pour le contrôleur d’entrée, tels que des règles de routage et des certificats TLS. De cette façon, vous n’avez pas besoin de gérer des fichiers de configuration complexes propres à une technologie de serveur proxy spécifique.
La passerelle est un point de défaillance unique ou un goulot d’étranglement potentiel dans le système. Déployez donc toujours au moins deux réplicas pour une haute disponibilité. Vous devrez peut-être effectuer un scale-out des réplicas, en fonction de la charge.
Envisagez également d’exécuter la passerelle sur un ensemble dédié de nœuds dans le cluster. Cette approche présente les avantages suivants :
Isolement : tout le trafic entrant est envoyé vers un ensemble fixe de nœuds, qui peut être isolé des services principaux.
Configuration stable : si la passerelle est mal configurée, l’application entière peut devenir indisponible.
Les performances. vous pouvez utiliser une configuration de machine virtuelle spécifique pour la passerelle pour des raisons de performances.
Étapes suivantes
Les articles précédents se penchaient sur les interfaces entre microservices ou entre microservices et applications clientes. Par défaut, ces interfaces traitent chaque service comme une boîte opaque. Les microservices ne doivent jamais exposer de détails d'implémentation sur la façon dont ils gèrent les données. Cela influe sur l'intégrité et la cohérence des données présentées dans l'article suivant.