Acheminez le trafic entrant vers vos applications SAE à l'aide d'une API Gateway cloud native. Ce guide vous explique comment créer une route de passerelle via la console SAE et détaille les options de configuration clés.
Contexte
Une API Gateway cloud native est une solution unifiée qui regroupe les passerelles de trafic, les passerelles de microservices, les passerelles de sécurité et les passerelles d'IA au sein d'une seule plateforme. Elle gère la découverte de services, l'équilibrage de charge et la communication interservices, remplaçant ainsi l'architecture fragmentée requise par les passerelles distribuées traditionnelles. Pour plus d'informations, consultez la rubrique Qu'est-ce qu'une API Gateway cloud native ?.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
MSE : Une instance d'API Gateway cloud native. Consultez la rubrique Créer une instance d'API Gateway cloud native.
SAE: Un namespace situé dans la même région que la passerelle et associé au même Virtual Private Cloud (VPC). Consultez la rubrique Créer un namespace.
SAE: Une application déployée dans ce namespace.
Créer une route de passerelle
Accédez à la page Routage de la passerelle SAE, sélectionnez une région et un namespace, puis cliquez sur Create Gateway Route.
Sur la page Create Route, configurez les paramètres suivants et cliquez sur Save.
Paramètres de base
| Paramètre | Description | Exemple |
|---|---|---|
| Route name | Nom personnalisé de la règle de routage. | demo |
| Network type | Réseau via lequel les requêtes sont transférées. Internet : trafic provenant d'Internet public, facturé en fonction du trafic effectivement transféré. Private : trafic circulant uniquement au sein du VPC actuel, non facturé. | Internet |
| Gateway type | Sélectionnez Cloud-native API Gateway. | Cloud-native API Gateway |
| Gateway instance | Requis lorsque le paramètre Gateway type est défini sur Cloud-native API Gateway. Sélectionnez une instance située dans la même région et le même VPC que le namespace. Pour créer une nouvelle instance, cliquez sur Create Cloud-native API Gateway. Consultez la rubrique Créer une instance d'API Gateway cloud native. | demo |
| Domain name | Un ou plusieurs noms de domaine à faire correspondre. Pour ajouter un nouveau domaine, cliquez sur Create Domain Name. Consultez la rubrique Créer un nom de domaine. | www.demo.com |
Conditions de correspondance
Configurez la manière dont la passerelle identifie les requêtes prises en charge par cette route.
Correspondance de chemin
Définissez le modèle de chemin à rechercher dans les requêtes HTTP.
| Type de correspondance | Comportement | Exemple |
|---|---|---|
| Equals | Correspondance exacte uniquement. | /user correspond uniquement à /user. |
| Prefix | Correspond à tout chemin commençant par la valeur spécifiée. | /user correspond à /user, /user/profile et /user/settings. |
| Regular expression | Fait correspondre les chemins à un modèle d'expression régulière. | user (classe de caractères) correspond aux chemins contenant ce modèle. |
Lorsque plusieurs règles partagent le même type de correspondance, la règle associée au chemin le plus long est prioritaire. Entre les différents types de correspondance, l'ordre de priorité est le suivant : Equals > Prefix > Regular expression.
Exemple de priorité
Le tableau ci-dessous indique la route sélectionnée par SAE pour des exemples de requêtes :
| Chemin de la requête | Route sélectionnée | Raison |
|---|---|---|
/user |
Equals: /user |
La correspondance exacte est la plus prioritaire. |
/user/profile |
Prefix: /user |
Aucune correspondance exacte ; le préfixe s'applique. |
/account |
Regex: user |
Ni correspondance exacte ni par préfixe ; l'expression régulière s'applique. |
Autres conditions de correspondance
| Paramètre | Description | Exemple |
|---|---|---|
| Method | Méthodes HTTP à faire correspondre. Laissez ce champ vide pour accepter toutes les méthodes. | GET |
| Request header | Nom de l'en-tête, type de correspondance et valeur. Lorsque plusieurs règles partagent les mêmes conditions, celle comportant le plus grand nombre de paramètres d'en-tête est prioritaire. | Nom : demo, Condition : Prefix, Valeur : value |
| Request parameter (Query) | Clé de la chaîne de requête, type de correspondance et valeur. Lorsque plusieurs règles partagent les mêmes conditions, celle comportant le plus grand nombre de paramètres de requête est prioritaire. | Clé : key, Condition : Prefix, Valeur : value |
Source de service et backend
Service source
Sélectionnez le registre de services correspondant à la méthode d'enregistrement de votre application.
| Option | Cas d'utilisation |
|---|---|
| MSE Nacos | L'application utilise MSE Nacos pour l'enregistrement et la découverte de services. Il est nécessaire de sélectionner une MSE Nacos instance et un MSE Nacos namespace. |
| K8s Service | L'application utilise des ServiceNames Kubernetes. Cette option prend en charge l'enregistrement et la découverte de services multilingues, et attribue des noms de domaine fixes afin d'éviter les changements d'adresse IP après le déploiement. |
La source de service doit correspondre à la méthode d'enregistrement et de découverte de services utilisée par votre application.
Scénarios et service backend
| Paramètre | Description | Exemple |
|---|---|---|
| Scenarios | Single service : achemine toutes les requêtes correspondantes vers un seul backend. Multiple services (version canary) : répartit le trafic entre plusieurs backends selon un poids défini. Consultez la rubrique Présentation des méthodes de routage. | Single service |
| Backend service | Application cible, nom du service, protocole et port. Lors de l'utilisation de plusieurs services, la somme des pourcentages de poids du trafic doit être égale à 100 %. | Application : demo, Service : demo, Protocole : Auto Read, Port : 80 |
Exemple de version canary
Dans le cadre d'un déploiement canary (scénario à plusieurs services), vous pouvez répartir le trafic par pourcentage afin de valider une nouvelle version avant son déploiement complet :
Version stable (
demo-v1) : 90 % du traficVersion canary (
demo-v2) : 10 % du trafic
Une fois la version canary stabilisée, augmentez progressivement son pourcentage jusqu'à ce qu'elle prenne en charge 100 % du trafic.
Configuration avancée
| Paramètre | Description | Par défaut | Exemple |
|---|---|---|---|
| Fallback | Activez cette option pour spécifier un service de secours. Lorsqu'aucun nœud sain n'est disponible pour le backend principal, la passerelle transfère les requêtes vers le service de secours. Actuellement pris en charge uniquement entre les services HTTP. | Désactivé | Activé |
| Timeout (s) | Durée maximale (en secondes) pendant laquelle la passerelle attend une réponse du backend. Définissez la valeur sur 0 pour désactiver le délai d'attente. |
60 | 60 |
| Retries | Nombre de tentatives après l'échec d'une requête. Définissez la valeur sur 0 pour désactiver les nouvelles tentatives. |
— | 2 |
| Retry conditions | Événements déclenchant une nouvelle tentative. Consultez la rubrique Configurer une politique de nouvelle tentative. | — | connect-failure, cancelled |
| Retry status codes | Codes d'état HTTP déclenchant une nouvelle tentative. | — | 502 |
Gérer les règles de routage
Après avoir créé une route, accédez à la page Gateway Routing pour consulter, modifier ou supprimer les routes de passerelle.
Étapes suivantes
Présentation des méthodes de routage : découvrez le fonctionnement du routage vers un service unique et vers plusieurs services.
Configurer une politique de nouvelle tentative : affinez le comportement des nouvelles tentatives pour vos routes.