Comprendre le modèle API Gateway dans les microservices : un guide simple

La transition d’une application unique et monolithique vers une architecture de microservices résout de nombreux problèmes. Il permet aux équipes de travailler de manière indépendante, de déployer des services séparément et de faire évoluer certaines parties du système selon les besoins. Cependant, cela introduit également un nouveau défi : comment les clients interagissent-ils avec tous ces services indépendants ?

Si vous disposez de dix, cinquante ou centaines de petits microservices, une application mobile ou une page Web doit-elle se connecter directement à chacun d’eux ?

C’est là que le API Gateway Pattern entre en jeu. Dans ce guide, nous expliquerons ce qu’est une API Gateway, pourquoi vous en avez besoin et comment elle simplifie votre système de microservices à l’aide de mots simples et d’analogies réelles.

L’analogie avec le monde réel : le réceptionniste de l’hôtel

Imaginez que vous vous enregistrez dans un grand hôtel de luxe. La station compte de nombreux départements différents :

• Ménage (pour les draps propres)
• Service de chambre (pour la nourriture)
• Concierge (pour la réservation de visites)
• Facturation (pour payer la facture)

Si vous voulez une serviette propre, vous ne traversez pas le complexe pour essayer de trouver le bâtiment de ménage. Si vous voulez dîner, vous ne frappez pas à la porte de la cuisine. Au lieu de cela, vous appelez le réceptionniste de la réception.

Le réceptionniste écoute votre demande, détermine quel service peut la résoudre et vous met en relation ou s’en occupe pour vous.

Dans ce scénario :

• Vous êtes le client (application mobile ou navigateur).
• Le réceptionniste est la passerelle API.
• Les départements (Housekeeping, Room Service, Facturation) sont les Microservices.

Le problème : communication directe client-service

Avant d’examiner le fonctionnement de la passerelle, voyons ce qui se passe si nous n’en utilisons pas une.

Supposons que votre application de commerce électronique dispose de trois microservices distincts :

1. Service utilisateur (gère les profils)
2. Service produit (gère le catalogue)
3. Service de commande (gère le paiement)

Sans API Gateway, l’application client doit envoyer des requêtes distinctes directement à l’adresse individuelle de chaque service (IP ou URL) :

Cette approche de connexion directe crée plusieurs maux de tête majeurs :

• Trop de points de terminaison : l’application cliente doit mémoriser trois URL distinctes. Si vous divisez un service ou modifiez son adresse, vous devez mettre à jour l’application client.
• Cauchemar de sécurité : chaque microservice doit implémenter séparément l’authentification (vérification des jetons de connexion), les certificats SSL et les règles de pare-feu.
• Surcharge réseau : le client peut avoir besoin d’effectuer trois requêtes réseau distinctes sur des réseaux mobiles lents juste pour charger une seule page (par exemple, récupérer le profil, récupérer les détails du produit et récupérer l’historique des commandes).
• Différences de protocole : votre application cliente peut préférer utiliser des protocoles Web standard tels que HTTP/JSON, mais vos services internes peuvent communiquer plus rapidement à l’aide de protocoles spécialisés tels que gRPC ou AMQP.

La solution : le modèle de passerelle API

Une API Gateway est un serveur d’assistance situé entre les applications clientes et les microservices internes. Il constitue le point d’entrée unique pour toutes les demandes entrantes.

Au lieu d’appeler trois services différents, le client effectue un seul appel à API Gateway. La passerelle transmet ensuite la demande au service interne approprié, collecte les résultats et les renvoie au client.

Principales responsabilités d’une passerelle API

Une passerelle API fait bien plus que simplement diriger le trafic. Il s’occupe des « problèmes transversaux », c’est-à-dire des tâches pour lesquelles chaque microservice devrait autrement écrire du code :

1. Routage : la passerelle prend une URL entrante (comme /api/v1/orders) et la mappe à l’adresse de service interne correcte.
2. Authentification et autorisation : la passerelle valide les jetons de sécurité (comme les JWT) à la porte d’entrée. Si la requête n’est pas valide, elle est immédiatement rejetée, évitant ainsi à vos microservices de gaspiller des cycles CPU sur des requêtes non authentifiées.
3. Limitation du débit : il empêche les robots malveillants ou les clients bogués de spammer votre système en limitant le nombre de requêtes qu’un utilisateur peut effectuer par minute.
4. Équilibrage de charge : la passerelle peut répartir le trafic entrant de manière uniforme sur plusieurs instances d’un microservice pour empêcher la surcharge d’un seul serveur.
5. Traduction de protocole : il peut traduire les requêtes JSON adressées aux utilisateurs en messages gRPC internes hautes performances, permettant aux services de communiquer entre eux dans leurs langues préférées.

Une implémentation simple : exemple de code

Pour voir à quel point le routage devient simple, examinons deux manières courantes de configurer une passerelle API.

1. Routage déclaratif (Spring Cloud Gateway YAML)

Dans les systèmes Java d’entreprise, vous configurez souvent le routage à l’aide d’un simple fichier de configuration. La passerelle transmet automatiquement les demandes en fonction de ces règles :

spring:
  cloud:
    gateway:
      routes:
        - id: user_service_route
          uri: http://internal-user-service:8081
          predicates:
            - Path=/api/users/**
        - id: product_service_route
          uri: http://internal-product-service:8082
          predicates:
            - Path=/api/products/**

2. Routage programmatique (maquette de passerelle Node.js)

Si vous souhaitez créer une passerelle API légère en Javascript à l’aide d’Express, cela ressemble à ceci :

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 3000;

// 1. Simple Security/Authentication Check at the door
const authenticate = (req, res, next) => {
    const token = req.headers['authorization'];
    if (token === 'secret-handshake-token') {
        next(); // Token is valid, proceed
    } else {
        res.status(401).json({ error: 'Unauthorized Access!' });
    }
};

// Apply auth check to all incoming gateway requests
app.use(authenticate);

// 2. Route requests to correct internal microservices
app.use('/api/users', createProxyMiddleware({ target: 'http://localhost:8081', changeOrigin: true }));
app.use('/api/products', createProxyMiddleware({ target: 'http://localhost:8082', changeOrigin: true }));
app.use('/api/orders', createProxyMiddleware({ target: 'http://localhost:8083', changeOrigin: true }));

app.listen(PORT, () => {
    console.log(`API Gateway running smoothly on port ${PORT}`);
});

Avantages et inconvénients du modèle de passerelle API

Comme toute décision architecturale, l’utilisation d’une passerelle API comporte des compromis :

Conclusion

Le modèle API Gateway est la pierre angulaire de l’architecture moderne des microservices. En agissant comme un point d’entrée unique et intelligent, il protège les applications client de la complexité des configurations de services internes. Il simplifie le code côté client, centralise la sécurité et gère efficacement la gestion du trafic.

Bien qu’il introduit un saut de réseau mineur et doive être configuré avec une haute disponibilité en production, les avantages de bases de code plus propres, plus sécurisées et plus faciles à gérer en font un modèle hautement recommandé pour tout système distribué en pleine croissance.

Découvrez davantage d’informations sur le développement logiciel et l’ingénierie back-end sur le blog Ghaznix →