La protection du trafic intègre les capacités de protection du trafic de Microservices Engine (MSE) dans Serverless App Engine (SAE) et contrôle le trafic atteignant une application au niveau de l'API. Utilisez des règles de limitation de débit, d'isolation de la concurrence, de disjoncteur et de protection des paramètres sensibles pour maintenir la disponibilité d'une application lors de pics de trafic ou lorsque une dépendance en aval devient instable. La protection du trafic analyse la répartition du trafic avec une granularité à la seconde.
Prérequis
Vous avez déployé une application.
Vous avez activé MSE Microservices Governance Enterprise Edition.
L'utilisation de MSE fait l'objet d'une facturation distincte. Pour plus d'informations sur la facturation de MSE, consultez la rubrique Facturation de MSE Microservices Governance.
Limites
Les limites suivantes s'appliquent à la protection du trafic :
Applications prises en charge — La protection du trafic s'applique uniquement aux applications de microservices créées le 8 novembre 2023 ou après cette date.
Débit de mise en file d'attente — Lorsque les requêtes limitées sont mises en file d'attente, ne définissez pas le QPS sur une valeur supérieure à 1 000, ce qui correspond à un intervalle de requête de 1 milliseconde.
Versions Apache Dubbo — Les versions 2.7.0 à 2.7.3 d'Apache Dubbo ne prennent pas en charge les comportements personnalisés. Dans ces versions, une requête limitée renvoie
java.lang.RuntimeException, et le contenu contientSentinelBlockedExceptionainsi que les informations de limitation.Types de réponse personnalisés — Une réponse personnalisée ne prend pas en charge les types d'objets contenant des génériques avec des types non définis, tels que
Map<K, V>etList<T>.
Choisir un type de règle de protection
La protection du trafic propose cinq types de règles, chacun disposant de son propre onglet dans la console SAE. Le tableau suivant décrit ce que chaque type de règle contrôle et où vous le configurez.
|
Type de règle |
Élément contrôlé |
Dimension statistique |
Onglet de la console |
|
Limitation au niveau de l'interface |
Le nombre de requêtes par seconde (QPS) d'une application ou d'un service. Le trafic est bloqué dès que le QPS atteint le seuil. |
QPS |
Limitation au niveau de l'interface |
|
Isolation de la concurrence |
Le nombre de threads simultanés d'une API ou de ses dépendances. |
Threads simultanés |
Isolation de la concurrence |
|
Disjoncteur |
Les appels vers une API instable ou une dépendance en aval, basés sur le temps de réponse ou le taux d'erreur. |
Taux d'appels lents ou proportion anormale |
Règles de disjoncteur |
|
Protection des paramètres sensibles (RPC) |
Les appels de ressources comportant des paramètres fréquemment appelés. Un paramètre est identifié par sa position d'index au point d'instrumentation. |
Nombre de requêtes ou nombre simultané, par paramètre sensible |
Protection des paramètres sensibles (RPC) |
|
Protection des paramètres sensibles (requête HTTP) |
Les requêtes d'accès à une application fournissant des services web, basées sur les propriétés de la requête telles que l'adresse IP du client, l'hôte, l'en-tête et le paramètre URL. |
Nombre de requêtes, par paramètre sensible |
Protection des paramètres sensibles (requête HTTP) |
Les règles de limitation au niveau de l'interface et les règles de protection des paramètres sensibles vous permettent également de choisir la manière dont le trafic limité est géré. L'échec rapide bloque immédiatement les requêtes excédentaires. La mise en file d'attente place les requêtes excédentaires en file d'attente afin qu'elles soient traitées à un rythme régulier ; cette méthode est généralement utilisée pour le lissage des pics de charge. Si vous mettez les requêtes en file d'attente, respectez la limite de débit de mise en file d'attente décrite dans la section Limites.
Accéder à l'onglet Protection du trafic
Dans la liste des applications SAE, sélectionnez la région et le namespace en haut de la page, puis cliquez sur l'ID d'application de l'application pour accéder à la page des détails de l'application.
Dans le volet de navigation de gauche, choisissez Microservices Governance > Traffic Governance, puis cliquez sur l'onglet Traffic Protection.
Configuration des règles de protection
Pour les types de règles dont le flux de création inclut l'assistant Configure Protection Behavior, la dernière étape consiste à sélectionner un Associated Behavior. Ce dernier définit la réponse qu'une requête reçoit après avoir déclenché la règle. Si vous n'avez pas besoin d'une réponse personnalisée pour les requêtes rejetées, sélectionnez le comportement par défaut. Pour plus d'informations sur les paramètres de comportement et les étapes de création, consultez la section Gestion des comportements.
Pour les règles de limitation au niveau de l'interface, les règles d'isolation de la concurrence et les règles de protection des paramètres sensibles, l'option Whether to open est désactivée par défaut. Ces règles ne prennent effet qu'après activation de cette option.
Configuration des règles de limitation au niveau de l'interface
Une règle de limitation au niveau de l'interface surveille le nombre de requêtes par seconde (QPS) d'une application ou d'un service. Lorsque le QPS atteint le seuil spécifié, la règle bloque immédiatement le trafic. Cette mesure empêche les pics de trafic momentanés de submerger l'application et garantit une haute disponibilité (HA).
Cliquez sur l'onglet Interface-level Throttling, puis cliquez sur Create Throttling Rule.
-
Dans la boîte de dialogue Create Throttling Rule, suivez les assistants ci-dessous :
Dans l'assistant Select Protection Scenario, sélectionnez le API Type, le Traffic Type et le API Name, puis cliquez sur Next.
Dans l'assistant Configure Protection Rule, configurez les paramètres décrits dans le tableau suivant, puis cliquez sur Next.
Dans l'assistant Configure Protection Behavior, sélectionnez un Associated Behavior, puis cliquez sur Create.
Le tableau suivant décrit les paramètres de l'assistant Configure Protection Rule.
|
Configuration item |
Description |
|
Whether to open |
Si vous activez cette option, la règle prend effet immédiatement après sa création. L'option est désactivée par défaut. |
|
Per-instance QPS threshold |
Seuil QPS de l'objet dans la dimension statistique de l'API limitée. |
|
Flow control effect |
Sélectionnez la méthode de gestion du trafic limité. Fast failure : lorsque le seuil est atteint, les requêtes sont bloquées immédiatement. Le contenu de la réponse est déterminé par les paramètres du module d'adaptateur dans les paramètres système de l'application. Waiting in line : les requêtes passent à un débit constant et les requêtes excédentaires sont mises en file d'attente. Cette méthode est généralement utilisée pour le lissage des pics de charge. Vous devez définir une période de délai d'expiration. Une requête échoue rapidement lorsqu'elle atteint la période de délai d'expiration. |
La règle apparaît dans l'onglet Interface-level Throttling, où vous pouvez la modifier ou la supprimer.
Exemple : lisser les pics de charge pour que le trafic passe à un débit constant
Le trafic des requêtes présente des pics et des creux. La limitation retarde le trafic de pointe en mettant les requêtes en file d'attente et en les traitant ultérieurement. Cette approche permet de traiter autant de requêtes que possible tout en maintenant l'expérience utilisateur. Configurez la règle de limitation avec les paramètres suivants :
Définissez le Stand-alone QPS threshold sur 5 pour le mode à débit constant.
Définissez l'option Flow control effect sur Waiting in line.
-
Définissez le Timeout sur 5 secondes.
Le système traite une requête toutes les 200 millisecondes et met en file d'attente les tâches excédentaires. Étant donné que le temps d'attente est de 5 secondes, une tâche dont le temps d'attente estimé dépasse 5 secondes échoue rapidement et renvoie directement la réponse de limitation par défaut, telle qu'un message texte ou une page statique.
Configuration des règles d'isolation de la concurrence
Une règle d'isolation de la concurrence contrôle le nombre de threads simultanés d'une API ou de ses dépendances afin de maintenir la stabilité du système.
Cliquez sur l'onglet Concurrency Isolation, puis cliquez sur Create Isolation Rule.
-
Dans la boîte de dialogue Create Isolation Rule, suivez les assistants ci-dessous :
Dans l'assistant Select Protection Scenario, sélectionnez le API Type, le Traffic Type et le API Name, puis cliquez sur Next.
Dans l'assistant Configure Protection Rule, configurez les paramètres décrits dans le tableau suivant, puis cliquez sur Next.
Dans l'assistant Configure Protection Behavior, sélectionnez un Associated Behavior, puis cliquez sur Create.
Le tableau suivant décrit les paramètres de l'assistant Configure Protection Rule.
|
Configuration item |
Description |
|
Whether to open |
Si vous activez cette option, la règle prend effet immédiatement après sa création. L'option est désactivée par défaut. |
|
Concurrency threshold |
Seuil du nombre de threads simultanés de la ressource, c'est-à-dire le nombre de threads en cours d'exécution pour la ressource. |
La règle apparaît dans l'onglet Concurrency Isolation, où vous pouvez la modifier ou la supprimer.
Exemple : garantir des ressources suffisantes pour votre application
Lorsque le temps de réponse d'une requête augmente, le nombre de threads simultanés croît. Une fois la concurrence supérieure au seuil, le système rejette les requêtes excédentaires jusqu'à ce que les tâches accumulées soient terminées et que le nombre de threads simultanés diminue. Cela permet d'isoler les pannes et de réduire l'instabilité.
Par exemple, une instruction SQL met 20 millisecondes à s'exécuter et 20 requêtes par seconde sont attendues pour cette demande. Configurez la règle d'isolation avec les paramètres suivants :
Saisissez le Interface Name.
-
Définissez le Concurrency threshold sur 10.
Avec cette configuration, si l'instruction SQL rencontre un interblocage ou des problèmes de performance et devient une instruction SQL lente, elle n'occupe que 10 threads même si les requêtes continuent d'arriver. Les requêtes continues, qui ne peuvent pas se terminer dans un court laps de temps, ne peuvent donc pas épuiser les threads actifs du processus. Lorsque l'instruction SQL revient à la normale, la concurrence diminue rapidement. Lorsque la concurrence tombe en dessous du seuil prédéfini, le système cesse de rejeter les requêtes et la capacité de traitement de l'application se rétablit rapidement. Cette méthode ajuste automatiquement la capacité en fonction du temps de réponse et isole les applications instables.
Configuration des règles de disjoncteur
Une règle de disjoncteur surveille le temps de réponse ou le taux d'erreur de votre application ou de ses dépendances en aval. Lorsque le seuil spécifié est atteint, le système abaisse immédiatement la priorité de la dépendance en aval. Pendant la période spécifiée, le système n'appelle pas la ressource instable. Cela empêche l'application de fonctionner dans un état instable et garantit une haute disponibilité. Une fois la période spécifiée écoulée, le système reprend les appels vers la ressource.
Cliquez sur l'onglet Circuit Breaking Rules, puis cliquez sur Create Circuit Breaking Rule.
-
Dans la boîte de dialogue Create Circuit Breaking Rule, suivez les assistants ci-dessous :
Dans l'assistant Select Protection Scenario, sélectionnez le API Type et le API Name, puis cliquez sur Next.
Dans l'assistant Configure Protection Rule, configurez les paramètres décrits dans le tableau suivant, puis cliquez sur Create.
Le tableau suivant décrit les paramètres de l'assistant Configure Protection Rule.
|
Configuration item |
Description |
|
Statistical window duration |
Durée de la fenêtre temporelle pour les statistiques. Valeurs valides : de 1 seconde à 120 minutes. |
|
Minimum number of requests |
Nombre minimal de requêtes déclenchant le disjoncteur. Si le nombre de requêtes dans la fenêtre temporelle statistique actuelle est inférieur à cette valeur, la règle n'est pas déclenchée même si la condition de disjonction est remplie. |
|
Threshold Type |
Sélectionnez Slow call ratio (%) ou Abnormal proportion (%) comme seuil. Si vous sélectionnez Slow call ratio comme seuil, vous devez spécifier le Slow call RT autorisé, qui correspond au temps de réponse maximal. Une requête dont le temps de réponse est supérieur à cette valeur est comptabilisée comme un appel lent. Dans le champ Circuit Breaking Ratio Threshold, définissez le ratio d'appels lents qui déclenche le disjoncteur. Une fois la règle activée, si le nombre de requêtes dans une fenêtre temporelle statistique est supérieur au Minimum number of requests et que le ratio d'appels lents est supérieur au seuil, les requêtes suivantes sont automatiquement bloquées pendant la durée spécifiée dans Circuit Breaking Duration (s). Une fois la durée de disjonction écoulée, le disjoncteur entre dans l'état de récupération par sondage. Si le temps de réponse de la requête suivante est inférieur au Slow call RT spécifié, la disjonction prend fin. Si le temps de réponse est supérieur au Slow call RT spécifié, la disjonction est de nouveau déclenchée. Si vous sélectionnez Abnormal proportion comme seuil, vous devez définir le taux d'erreur qui déclenche la disjonction dans le champ Circuit Breaking Ratio Threshold. Une fois la règle activée, si le nombre d'erreurs métier dans une fenêtre temporelle statistique est supérieur au Minimum number of requests et que le taux d'erreur est supérieur au seuil, les requêtes suivantes sont automatiquement bloquées pendant la durée spécifiée dans Circuit Breaking Duration (s). |
|
Circuit Breaking Duration (s) |
Cliquez sur Show Advanced Options pour configurer ce paramètre. Durée pendant laquelle la disjonction persiste après son déclenchement. Lorsqu'une ressource entre dans l'état de disjonction, les requêtes échouent rapidement pendant la durée de disjonction spécifiée. |
|
Circuit Breaking Policy |
Cliquez sur Show Advanced Options pour configurer ce paramètre. Politique de récupération utilisée par le disjoncteur lorsqu'il entre dans la phase de récupération, c'est-à-dire l'état semi-ouvert. Single detection recovery : une fois la durée de disjonction écoulée, le disjoncteur sonde la requête suivante. Si la requête répond aux attentes, c'est-à-dire qu'il ne s'agit ni d'un appel lent ni d'une erreur, la disjonction prend fin. Sinon, le disjoncteur retourne à la phase de disjonction. Progressive recovery : vous devez définir le Number of recovery phases et le Minimum number of passes per step . Une fois la durée de disjonction écoulée, le disjoncteur récupère progressivement en fonction du nombre spécifié de phases de récupération. Si le nombre de requêtes dans une phase atteint le nombre minimal de passages par étape, une vérification est déclenchée. Si aucune des requêtes vérifiées ne dépasse le seuil, le système augmente progressivement le ratio de requêtes autorisées à passer jusqu'à ce que le trafic soit entièrement rétabli. Si une métrique dans l'une des étapes dépasse le seuil, le disjoncteur retourne à la phase de disjonction. Le ratio de requêtes T = 100/N, où N est le nombre de phases de récupération. Le ratio dans la première phase est T, le ratio dans la deuxième phase est 2T, et ainsi de suite, jusqu'à ce que le ratio atteigne 100 %. Par exemple, si le nombre de phases de récupération est de 3 et que le nombre minimal de passages par étape est de 5, les requêtes sont autorisées à passer avec des ratios de 33 %, 67 % et 100 % dans les trois phases. Lorsque le nombre de requêtes dans une phase est supérieur ou égal à 5, une vérification est effectuée. Si les métriques de requête ne dépassent pas le seuil, le disjoncteur passe à la phase de récupération suivante jusqu'à ce que le trafic soit entièrement rétabli. |
La règle apparaît dans l'onglet Circuit Breaking Rules, où vous pouvez la modifier ou la supprimer.
Exemple : déclencher la disjonction en cas d'appels lents ou d'erreurs
Appliquez la disjonction lorsqu'un appel à un service tiers répond trop lentement et affecte l'API actuelle, ou lorsque votre système renvoie des erreurs lors de l'affichage de contenu tiers. Les deux cas utilisent le même type de règle et ne diffèrent que par le Threshold Type que vous sélectionnez.
|
Configuration item |
Example: slow calls |
Example: errors |
|
Interface Name |
test |
test |
|
Statistical window duration |
1 |
1 |
|
Minimum number of requests |
10 |
10 |
|
Threshold Type |
Slow call ratio |
Abnormal proportion |
|
Slow call RT |
1000 |
Not required |
|
Circuit Breaking Ratio Threshold |
80 % |
80 % |
|
Circuit Breaking Duration (s) |
10 |
10 |
|
Circuit Breaking Policy |
Single detection recovery |
Single detection recovery |
Avec l'une ou l'autre configuration, la fenêtre temporelle statistique est de 1 seconde, la règle n'est pas déclenchée sauf si la fenêtre contient au moins 10 requêtes, et la disjonction dure 10 secondes. Dans l'exemple d'appel lent, une requête qui prend plus de 1 000 millisecondes est considérée comme lente, et le ratio d'appels lents qui déclenche la disjonction est de 80 %. Dans l'exemple d'erreur, le taux d'erreur qui déclenche la disjonction est de 80 %.
Configurer les règles de protection des paramètres critiques (RPC)
Une fois que vous avez configuré les règles pour une application, le système analyse les paramètres statistiques, c'est-à-dire les paramètres appelés fréquemment lors des appels de ressources. Sur la base de ces règles, le système applique une limitation du débit aux appels de ressources contenant des paramètres critiques afin de préserver la stabilité du système. Utilisez ce type de règle pour les appels de ressources RPC, dans lesquels un paramètre critique est identifié par sa position d'index au point d'instrumentation.
Cliquez sur l'onglet Hotspot Parameter Protection (RPC), puis cliquez sur Create Hotspot Parameter Protection Rule (RPC).
-
Dans la boîte de dialogue Create Hotspot Parameter Protection Rule (RPC), suivez les assistants ci-dessous :
Dans l'assistant Select Protection Scenario, sélectionnez le API Name, puis cliquez sur Next.
Dans l'assistant Configure Protection Rule, configurez les paramètres décrits dans le tableau suivant, puis cliquez sur Next.
Dans l'assistant Configure Protection Behavior, sélectionnez un Associated Behavior, puis cliquez sur Create.
Le tableau suivant décrit les paramètres de l'assistant Configure Protection Rule.
|
Configuration item |
Description |
|
Parameter position Index |
La position d'index du paramètre transmis au niveau de la ressource du point d'instrumentation. Cela correspond à la position d'index du paramètre dans |
|
Statistical dimension |
Vous pouvez mesurer soit le nombre de requêtes, soit le nombre de threads simultanés. Number of requests : limite le nombre d'appels sur une période donnée. Concurrent number : limite le nombre d'appels simultanés à la ressource. |
|
Statistical cycle time |
La durée de la fenêtre statistique, en secondes. Par exemple, si la fenêtre statistique est de 10 secondes et que le seuil QPS est de 5, chaque paramètre critique peut être accédé au maximum 5 fois en 10 secondes. |
|
Single machine threshold |
Le seuil qui s'applique à chaque paramètre critique. |
|
Flow control effect |
Si Statistical dimension est défini sur Number of requests, vous pouvez choisir la manière dont le trafic limité est géré. Fast failure : lorsque le seuil est atteint, les requêtes sont immédiatement bloquées. Dans ce mode, vous pouvez également définir un Number of buffered requests, qui correspond au nombre de requêtes supplémentaires autorisées en cas de pics de trafic. Waiting in line : les requêtes passent à un rythme constant et les requêtes excédentaires sont mises en file d'attente. Cette méthode est généralement utilisée pour lisser les pics de charge. Vous devez définir un délai d'expiration. Lorsqu'une requête est mise en file d'attente, le système calcule son temps d'attente estimé. Si ce temps dépasse le délai d'expiration maximal, la requête est rejetée. Par exemple, si Single machine threshold est défini sur 5, une seule requête passe toutes les 200 millisecondes et les requêtes excédentaires sont mises en file d'attente. Si Timeout est défini sur 1 000 millisecondes, les nouvelles requêtes sont rejetées lorsque plus de 5 requêtes sont déjà en file d'attente, ce qui correspond à un temps d'attente supérieur à 1 000 millisecondes. |
|
Whether to open |
Si vous activez cette option, la règle prend effet immédiatement après sa création. L'option est désactivée par défaut. |
La règle apparaît dans l'onglet Hotspot Parameter Protection (RPC), où vous pouvez la modifier ou la supprimer.
Exemple : mettre en file d'attente les requêtes pour un article populaire lors d'une vente flash
Lors des ventes flash et autres événements d'achat massif, un trafic élevé peut ralentir les réponses du système, voire provoquer son arrêt. Pour maintenir la stabilité du système, vous pouvez configurer une règle de paramètre critique afin que le système mette en file d'attente le trafic pour les articles populaires une fois qu'un seuil est dépassé. Cet exemple met en file d'attente les requêtes excédentaires vers une API RPC au lieu de les rejeter : si les requêtes d'achat pour le même article dépassent 100 en 1 seconde, les requêtes restantes sont mises en file d'attente.
Saisissez le Interface Name.
Définissez Statistical dimension sur Number of requests.
Définissez Statistical cycle time sur 1 seconde et Single machine threshold sur 100.
Définissez Flow control effect sur Waiting in line.
-
Définissez Timeout sur 30 millisecondes.
Si cette API est appelée plus de 100 fois en 1 seconde, les requêtes excédentaires sont mises en file d'attente. Une requête qui attend plus de 30 millisecondes échoue immédiatement.
Exemple : limiter les appels fréquents qui consomment trop de ressources système
Lors d'une vente flash, les clients doivent parfois modifier l'adresse de livraison d'une commande. Un grand nombre de ces demandes de modification consomme d'importantes ressources d'écriture de base de données. Vous pouvez limiter les appels simultanés portant le même paramètre critique afin que les clients effectuent la modification ultérieurement.
Saisissez le Interface Name.
Définissez Statistical dimension sur Concurrent number.
-
Définissez Statistical cycle time sur 1 seconde et Single machine threshold sur 100.
Cette configuration autorise un maximum de 100 appels simultanés pour chaque paramètre critique. Les requêtes excédentaires sont rejetées.
Configurer les règles de protection des paramètres critiques (requête HTTP)
Les règles de protection des paramètres critiques pour les requêtes HTTP s'appliquent aux applications qui fournissent des services web. Ces règles effectuent un façonnage granulaire du trafic sur des paramètres spécifiques dans les requêtes d'accès. Vous pouvez façonner le trafic pour les appels de ressources en fonction de dimensions de requête telles que l'adresse IP, l'hôte, l'en-tête et le paramètre URL afin de maintenir la stabilité métier et système.
Cliquez sur l'onglet Hotspot Parameter Protection (HTTP Request), puis cliquez sur Create Hotspot Parameter Protection Rule (HTTP Request).
-
Dans la boîte de dialogue Create Hotspot Parameter Protection Rule (HTTP Request), suivez les assistants ci-dessous :
Dans l'assistant Select Protection Scenario, sélectionnez le API Name, puis cliquez sur Next.
Dans l'assistant Configure Protection Rule, configurez les paramètres décrits dans le tableau suivant, puis cliquez sur Next.
Dans l'assistant Configure Protection Behavior, sélectionnez un Associated Behavior, puis cliquez sur Create.
Le tableau suivant décrit les paramètres de l'assistant Configure Protection Rule.
|
Configuration item |
Description |
|
Parameter Properties |
Façonne le trafic en fonction des propriétés de paramètre de l'API sélectionnée. Client IP : l'adresse IP du client. Si une requête passe par un proxy, le système tente d'abord d'obtenir l'adresse IP à partir de l'en-tête de requête |
|
Threshold Type |
La valeur par défaut est Request count. |
|
Threshold |
Le seuil QPS de l'objet dans la dimension statistique de l'API limitée. Lorsque vous définissez le seuil, vous devez sélectionner un intervalle statistique. Les intervalles pris en charge sont la seconde, la minute, l'heure et le jour. Par exemple, si vous définissez le seuil sur 10 et sélectionnez minute comme intervalle, pas plus de 10 requêtes ne sont autorisées par minute. |
|
Whether to open |
Si vous activez cette option, la règle prend effet immédiatement après sa création. L'option est désactivée par défaut. |
|
Throttling method |
Cliquez sur Show Advanced Options pour configurer ce paramètre. Fast failure : si le type de seuil est QPS, le trafic limité échoue rapidement, ce qui signifie que les requêtes sont immédiatement bloquées lorsque le seuil est atteint. Les requêtes rejetées reçoivent la réponse personnalisée configurée dans la gestion des comportements. Si aucune réponse personnalisée n'est configurée, le comportement par défaut s'applique, qui renvoie le code d'erreur 429 et le message texte par défaut. Waiting in line : si le type de seuil est QPS, les requêtes limitées passent à un rythme constant et sont autorisées à être mises en file d'attente. Vous devez définir un délai d'expiration. Une requête dont on prévoit qu'elle atteindra le délai d'expiration échoue immédiatement au lieu d'être mise en file d'attente. Par exemple, si le QPS est défini sur 10, une seule requête passe toutes les 100 millisecondes et les requêtes excédentaires sont mises en file d'attente. Le délai d'expiration est le temps d'attente maximal. Les requêtes qui dépassent le temps d'attente maximal sont rejetées. Pour la limite QPS qui s'applique lorsque les requêtes sont mises en file d'attente, consultez Limites. |
|
Burst size |
Cliquez sur Show Advanced Options pour configurer ce paramètre. Si Throttling method est défini sur Fast failure, vous pouvez définir une taille de pic, qui correspond au nombre de requêtes supplémentaires autorisées en cas de pics de trafic. |
|
Timeout |
Cliquez sur Show Advanced Options pour configurer ce paramètre. Si Throttling method est défini sur Waiting in line, vous devez définir un délai d'expiration, en millisecondes. Par exemple, si le QPS est défini sur 5, une seule requête passe toutes les 200 millisecondes et les requêtes excédentaires sont mises en file d'attente. Le délai d'expiration est le temps d'attente maximal. Les requêtes qui dépassent le temps d'attente maximal sont rejetées. |
La règle apparaît dans l'onglet Hotspot Parameter Protection (HTTP Request), où vous pouvez la modifier ou la supprimer.
Exemple : vente flash d'un produit populaire
Lors des ventes flash et autres événements d'achat massif, un trafic élevé peut ralentir les réponses du système, voire provoquer son arrêt. Pour maintenir la stabilité du système, vous pouvez configurer une règle de protection des paramètres critiques afin que le système rejette le trafic excédentaire pour les articles populaires une fois qu'un seuil est dépassé. Cet exemple s'applique à une API HTTP et rejette les requêtes excédentaires au lieu de les mettre en file d'attente.
Par exemple, pour rejeter les requêtes excédentaires après que les requêtes pour le même produit ont dépassé 100 en 1 seconde, configurez les paramètres suivants. Cette règle autorise un maximum de 100 requêtes de commande par seconde pour chaque ID de produit individuel et rejette les requêtes de commande excédentaires pour ce produit avec une réponse personnalisée.
Définissez Parameter Properties sur URL parameter.
Saisissez
stockIdpour URL parameter name.Saisissez 100 requêtes par second pour Threshold.
Définissez Throttling method sur Fast failure.
Dans les propriétés de paramètre, sélectionnez le champ de paramètre qui correspond à l'ID du produit populaire. Par exemple, si un champ stockId dans les paramètres URL transporte l'ID du produit demandé, vous pouvez définir la propriété de paramètre sur URL parameter et saisir le nom du champ de la propriété dans la requête comme nom de paramètre.
Exemple : prévenir les commandes malveillantes
Lors d'un événement promotionnel, un grand nombre de requêtes de commande malveillantes occupe l'inventaire des produits ou les ressources du serveur. Dans ce cas, vous pouvez mettre les requêtes en file d'attente en fonction de leurs adresses IP source afin que les requêtes d'accès passent à un rythme constant. Cela empêche les requêtes excessives d'affecter la stabilité du service. Configurez la règle suivante :
Définissez Parameter Properties sur Client IP.
Conservez la valeur par défaut Request count pour Threshold Type.
Saisissez 100 requêtes par second pour Threshold.
Définissez Throttling method sur Waiting in line.
Saisissez 30 millisecondes pour Timeout.
-
Activez Whether to open.
Avec cette règle, les requêtes de chaque adresse IP source passent à un rythme d'une requête toutes les 10 millisecondes (1 seconde/100 = 10 millisecondes), et les requêtes excédentaires sont mises en file d'attente. Une requête en file d'attente qui attend plus de 30 millisecondes échoue immédiatement.
Gérer les comportements
Un comportement web renvoie une réponse personnalisée lorsqu'une règle est déclenchée sur une ressource de point d'instrumentation web. Par exemple, une API web peut renvoyer le message Blocked by Sentinel après avoir déclenché une règle de limitation du débit.
Créer un comportement
Cliquez sur l'onglet Behavior Management, puis cliquez sur Create Behavior.
-
Dans la boîte de dialogue Create Behavior, configurez les paramètres décrits dans les tableaux suivants, puis cliquez sur Create.
Le tableau ci-dessous détaille les paramètres applicables lorsque Resource Type est défini sur Web.
|
Parameter |
Description |
Example value |
|
Behavior Name |
Nom du comportement. Il peut contenir jusqu'à 128 caractères et doit être unique au sein de l'application. |
Test behavior |
|
Resource Type |
Sélectionnez Web. |
Web |
|
**Web throttling handler Web Throttling Policy |
Définit le comportement du système après le déclenchement d'une règle lors de l'accès à une API web. Réponse personnalisée : vous devez définir le code d'état HTTP, le format du contenu renvoyé et le contenu lui-même. L'API web renvoie ce contenu personnalisé lorsqu'une règle est déclenchée. |
Custom response |
|
HTTP Status Code |
La valeur par défaut est 429. Ce paramètre est obligatoire lorsque Web throttling handler est défini sur Custom response. |
429 |
|
Returned Content-Type |
Définissez le format du contenu renvoyé sur Plain text ou JSON. |
JSON string |
|
Returned HTTP Text |
Saisissez le contenu renvoyé lorsqu'une règle est déclenchée lors de l'accès à l'API web. Ce paramètre est obligatoire lorsque Web throttling handler est défini sur Custom response. |
|
Le tableau suivant présente les paramètres applicables lorsque Resource Type est défini sur RPC.
|
Parameter |
Description |
Example value |
|
Behavior Name |
Nom du comportement. Il peut contenir jusqu'à 128 caractères et doit être unique au sein de l'application. |
Test behavior |
|
Resource Type |
Sélectionnez RPC. Pour connaître les versions d'Apache Dubbo qui ne prennent pas en charge les comportements personnalisés, consultez la section Limites. |
Rpc |
|
RPC throttling handler |
Définit le comportement du système après le déclenchement d'une règle lors de l'accès à une API RPC. Custom response : renvoie un résultat personnalisé. Vous devez définir le code d'état HTTP, le format du contenu renvoyé et le contenu lui-même. L'API RPC renvoie ce contenu personnalisé lorsqu'une règle est déclenchée. Custom exception : lève une exception personnalisée. Vous devez définir le nom de la classe d'exception et le texte de l'exception. Le système renvoie les informations d'exception spécifiées lorsqu'une règle est déclenchée lors de l'accès à l'API RPC. |
Custom response/Custom exception |
|
Custom response class name |
Obligatoire lorsque RPC throttling handler est défini sur Custom response. Saisissez le chemin du nom de la classe. Pour connaître les types d'objets non pris en charge par une réponse personnalisée, consultez la section Limites. |
|
|
Custom response content (JSON) |
Obligatoire lorsque RPC throttling handler est défini sur Custom response. Saisissez le contenu de l'objet renvoyé lorsqu'une règle est déclenchée lors de l'accès à l'API RPC. |
|
|
Exception class name |
Obligatoire lorsque RPC throttling handler est défini sur Custom exception. Saisissez le chemin du nom de la classe d'exception. |
|
|
Exception message |
Obligatoire lorsque RPC throttling handler est défini sur Custom exception. Saisissez le texte de l'exception personnalisée levée lorsqu'une règle est déclenchée lors de l'accès à l'API RPC. |
|
Le comportement que vous créez apparaît dans l'onglet Behavior Management, où vous pouvez le modifier ou le supprimer.
Associer un comportement à une règle existante
Un comportement est associé à une règle via l'assistant Configure Protection Behavior lors de la création de la règle. Pour modifier le comportement d'une règle existante, modifiez cette dernière.
Cliquez sur l'onglet Traffic Protection, puis sur l'onglet correspondant au type de règle.
Repérez la règle et cliquez sur Edit dans la colonne Actions.
Suivez les assistants Select Protection Scenario et Configure Protection Rule.
Dans l'assistant Configure Protection Behavior, sélectionnez le comportement dans la liste déroulante Associated Behavior. Vous pouvez également cliquer sur Create Behavior pour créer un comportement et l'associer à la règle.
-
Cliquez sur Save.
Avant d'associer un comportement, tenez compte des points suivants :
Default behavior — Si vous n'avez pas besoin d'un comportement de secours personnalisé pour les requêtes limitées, sélectionnez le comportement par défaut. Le type d'API du comportement par défaut est vide.
Existing binding — Lors de la création d'une règle, si un comportement est déjà lié à l'API, le nouveau comportement remplace le comportement existant de l'API.
API type — Lorsque vous sélectionnez un comportement, le comportement par défaut est lié si vous ne sélectionnez pas de type d'API. Une fois que vous avez sélectionné un type d'API et lié un comportement du type correspondant, vous ne pouvez plus modifier le type.