API Gateway:Configure policies and plug-ins

Politique de limitation du débit

Cloud-native API Gateway prend en charge les politiques de limitation du débit aux niveaux de l'API et de l'opération. Ces politiques empêchent les requêtes entrantes de submerger vos services backend et vous aident à éviter les pannes en cascade. Dans les scénarios à forte concurrence, la limitation du débit protège la disponibilité des services backend en bloquant certaines requêtes. Cela vous permet de contrôler précisément le nombre de requêtes pour chaque API et opération sur une période donnée, en veillant à ce que ce nombre ne dépasse pas un seuil prédéfini.

Les politiques de limitation du débit incluent le Contrôle de la concurrence, le Contrôle du trafic et le Disjoncteur.

• Politique de contrôle de la concurrence : Cette politique limite le nombre de requêtes simultanées. Elle fonctionne en comptabilisant le nombre total de requêtes actuellement traitées par la passerelle. Lorsque ce nombre atteint le seuil configuré, la passerelle bloque immédiatement le nouveau trafic. Vous pouvez définir ce seuil pour qu'il corresponde au nombre maximal de requêtes simultanées que votre service backend peut gérer, protégeant ainsi sa disponibilité lors des pics de trafic.

  Procédure

  Sur la page Add Policy, cliquez sur la carte Concurrency Control. Dans le panneau Add Policy: Concurrency Control, configurez les paramètres.

  Paramètre			Description
  Enable or Not			Active la règle de contrôle de la concurrence.
  Overall Concurrency Threshold			Définissez le Overall Concurrency Threshold.
  Web Fallback Behavior	Return Specific Content	HTTP Status Code	Définissez le HTTP Status Code. La valeur par défaut est 429.
  		Type of Returned Content	Définissez Type of Returned Content sur Regular Text ou JSON.
  		HTTP Text	Le contenu du corps de réponse personnalisé.
  	Return Specific Content	Redirect URL	Saisissez l'Redirect URL.

• Politique de contrôle du trafic : Cette politique limite le débit des requêtes en fonction du nombre de requêtes par seconde (QPS). Elle fonctionne en surveillant le QPS pour une API ou une opération. Lorsque le QPS atteint le seuil configuré, la passerelle bloque immédiatement le nouveau trafic. Cela empêche les services backend d'être submergés par des pics de trafic soudains et garantit une haute disponibilité.

  Procédure

  Sur la page Add Policy, cliquez sur la carte Traffic Control. Dans le panneau Add Policy: Traffic Control, configurez les paramètres.

  Paramètre			Description
  Enable or Not			Active la règle de contrôle du trafic.
  Overall QPS Threshold			Définissez le Overall QPS Threshold.
  Web Fallback Behavior	Return Specific Content	HTTP Status Code	Définissez le HTTP Status Code. La valeur par défaut est 429.
  		Type of Returned Content	Définissez Type of Returned Content sur Regular Text ou JSON.
  		HTTP Text	Le contenu du corps de réponse personnalisé.
  	Redirect to Specified Page	Redirect URL	Saisissez l'Redirect URL.

• Politique de disjoncteur : Cette politique protège les services backend en surveillant le temps de réponse ou le taux d'erreur des API et des opérations. Lorsqu'un seuil spécifié est atteint, la passerelle « déclenche le disjoncteur », échouant immédiatement les requêtes vers le service instable pour éviter une charge supplémentaire. Après une durée configurée, la passerelle passe à un état « semi-ouvert » et autorise un nombre limité de requêtes de test pour vérifier si le service a récupéré. Si le service est stable, le circuit se ferme ; sinon, il se déclenche à nouveau.

  L'état du disjoncteur est maintenu indépendamment par chaque nœud de la passerelle. Chaque nœud compte les requêtes et calcule le ratio d'appels lents ou le ratio d'exceptions de manière autonome. Le seuil de déclenchement du disjoncteur s'applique par nœud et n'est pas agrégé à l'échelle du cluster. Lorsque vous configurez le Minimum Number of Requests, la Statistical Window Duration et le seuil de ratio de déclenchement du disjoncteur, gardez à l'esprit que ces valeurs s'appliquent aux statistiques locales d'un seul nœud, et non à l'ensemble du cluster de passerelles.

  Procédure

  Sur la page Add Policy, cliquez sur la carte Circuit Breaking. Dans le panneau Add Policy: Circuit Breaking, configurez les paramètres.

  Paramètre			Description
  Enable or Not			Active la règle de disjoncteur.
  Statistical Window Duration			La durée de la fenêtre temporelle pour la collecte des statistiques. Valeurs valides : de 1 seconde à 120 minutes.
  Minimum Number of Requests			Le nombre minimal de requêtes dans la fenêtre statistique requis pour déclencher le disjoncteur. Si le nombre de requêtes est inférieur à cette valeur, le disjoncteur ne se déclenchera pas, même si le seuil d'erreur est atteint.
  Threshold Type			Sélectionnez soit Slow Call Ratio (%), soit Exception Ratio (%) comme type de seuil. Si vous sélectionnez Slow Call Ratio (%), vous devez définir le Slow Call RT (temps de réponse maximal). Une requête est comptée comme un appel lent si son temps de réponse dépasse cette valeur. Lorsque la règle est activée, si le nombre de requêtes dans la fenêtre statistique est supérieur au nombre minimal de requêtes et que le pourcentage d'appels lents dépasse le seuil, le circuit est déclenché. Une fois la durée de déclenchement du disjoncteur écoulée, le disjoncteur passe à un état de récupération par sondage (semi-ouvert). Si le temps de réponse de la prochaine requête de test est inférieur au Slow Call RT spécifié, le circuit se ferme. Sinon, le circuit est à nouveau déclenché. Si vous sélectionnez Exception Ratio (%), vous devez définir le seuil de pourcentage d'erreurs. Lorsque la règle est activée, si le nombre de requêtes dans la fenêtre statistique est supérieur au nombre minimal de requêtes et que le pourcentage d'erreurs dépasse le seuil, le circuit est déclenché pour la durée configurée.
  Slow Call RT			Définissez le Slow Call RT autorisé (c'est-à-dire le temps de réponse maximal).
  Circuit Breaking Ratio Threshold			Le pourcentage d'appels lents ou d'erreurs qui déclenche le disjoncteur. Valeurs valides : de 0 à 100 (représentant 0 % à 100 %).
  Circuit Breaking Duration (s)			La durée pendant laquelle le circuit reste ouvert après avoir été déclenché. Pendant cette période, toutes les requêtes vers la ressource échoueront immédiatement.
  Web Fallback Behavior	Return Specific Content	HTTP Status Code	Définissez le HTTP Status Code. La valeur par défaut est 429.
  		Type of Returned Content	Définissez Type of Returned Content sur Regular Text ou JSON.
  		HTTP Text	Le contenu du corps de réponse personnalisé.
  	Redirect to Specified Page	Redirect URL	Saisissez l'Redirect URL.

Politique de réécriture

Une politique de réécriture vous permet de modifier le chemin de la requête et le nom d'hôte avant de transférer la requête au service backend. Cela permet de répondre à des exigences métier et architecturales spécifiques en garantissant que les requêtes sont routées vers le bon service ou endpoint.

Politique de modification des en-têtes

La fonctionnalité de modification des en-têtes vous permet de changer les en-têtes de requête avant qu'ils ne soient transférés au service backend, ou dans une réponse avant qu'elle ne soit renvoyée au client.

Politique CORS

Le partage de ressources cross-origin (CORS) est une fonctionnalité de sécurité qui permet à un serveur d'application web de contrôler l'accès cross-origin, permettant ainsi un transfert de données sécurisé. Cloud-native API Gateway prend en charge les politiques CORS aux niveaux de l'API et de l'opération. Vous pouvez spécifier quels domaines et méthodes de requête peuvent accéder à vos ressources.

Politique de réplication du trafic

La politique de réplication du trafic vous permet de copier le trafic applicatif en direct vers un service spécifié. Cette fonctionnalité est utile pour les tests de simulation et le diagnostic des problèmes, afin de vous aider à évaluer les performances de l'application et à résoudre les pannes.

Politique de délai d'attente

Cloud-native API Gateway fournit des paramètres de délai d'attente aux niveaux de l'API et de l'opération. Vous pouvez configurer le temps maximum que la passerelle attend une réponse du service backend. Si la passerelle ne reçoit pas de réponse dans le délai spécifié, elle renvoie un code d'état HTTP 504 (Gateway Timeout) au client.

Politique de nouvelle tentative

Cloud-native API Gateway fournit des paramètres de nouvelle tentative aux niveaux de l'API et de l'opération pour retenter automatiquement les requêtes ayant échoué. Vous pouvez configurer les conditions de nouvelle tentative, telles que le déclenchement d'une nouvelle tentative en cas d'échec de connexion, de service backend indisponible ou de code d'état HTTP spécifique.

Conditions de nouvelle tentative pour les API et les opérations

Lorsque le service backend renvoie une erreur 5xx, Cloud-native API Gateway retente automatiquement la requête ayant échoué selon le nombre de nouvelles tentatives configuré.

• Les conditions de nouvelle tentative pour le protocole HTTP sont les suivantes :

  • 5xx : Si le service backend renvoie une réponse 5xx, ou si une connexion est déconnectée ou réinitialisée, ou si un délai de lecture expire, Cloud-native API Gateway retente la requête ayant échoué.

    Remarque

    La condition 5xx inclut les conditions connect-failure et refused-stream.

  • reset : Si une connexion est déconnectée ou réinitialisée, ou si un délai de lecture expire, Cloud-native API Gateway retente la requête ayant échoué.

  • connect-failure : Si une requête échoue parce qu'une connexion est déconnectée, Cloud-native API Gateway retente la requête ayant échoué.

  • refused-stream : Si le service backend réinitialise un flux avec le code d'erreur REFUSED_STREAM, Cloud-native API Gateway retente la requête ayant échoué.

  • retriable-status-codes : Si le code d'état HTTP dans la réponse du service backend correspond à un code d'état de nouvelle tentative que vous avez spécifié, Cloud-native API Gateway retente la requête.

    Remarque

    Vous pouvez spécifier des codes d'état de nouvelle tentative uniquement si vous sélectionnez retriable-status-codes comme condition de nouvelle tentative.

• Les conditions de nouvelle tentative pour le protocole gRPC sont les suivantes :

  • cancelled : Si le code d'état gRPC dans l'en-tête de réponse du service gRPC backend est cancelled, Cloud-native API Gateway retente la requête.

  • deadline-exceeded : Si le code d'état gRPC dans l'en-tête de réponse du service gRPC backend est deadline-exceeded, Cloud-native API Gateway retente la requête.

  • internal : Si le code d'état gRPC dans l'en-tête de réponse du service gRPC backend est internal, Cloud-native API Gateway retente la requête.

  • resource-exhausted : Si le code d'état gRPC dans l'en-tête de réponse du service gRPC backend est resource-exhausted, Cloud-native API Gateway retente la requête.

  • unavailable : Si le code d'état gRPC dans l'en-tête de réponse du service gRPC backend est unavailable, Cloud-native API Gateway retente la requête.