Dans Sentinel, le composant FlowSlot appplique des règles prédéfinies pour réguler le trafic en exploitant les statistiques en temps réel fournies par des slots tels que NodeSelectorSlot, ClusterNodeBuilderSlot et StatistcSlot.

L'effet direct de la limitation de flux se manifeste lors de l'exécution d'une entrée comme Entree noeudA = SphU.entrée(nomRessource), où une exception de type FlowException est levée. Cette exception, héritant de BlockException, peut être capturée pour personnaliser la logique de gestion des requêtes bloquées.

Une ressource peut être associée à plusieurs règles de limitation. FlowSlot parcourt toutes les règles applicables jusqu'à ce qu'une règle déclenche la limitation ou que l'ensemble soit épuisé.

Une règle de limitation se compose principalement des éléments suivants, permettant de combiner différents effets :

• ressource : nom de la cible de la règle
• seuil : valeur seuil de limitation
• typeSeuil : type de seuil, soit QPS (requêtes par seconde), soit nombre de threads
• : stratégie basée sur les relations d'appel

Le contrôle de flux repose sur deux types principaux de métriques : le nombre de threads simultanés et le QPS.

Types de contrôle de flux

Contrôle basé sur le QPS

Le QPS représente le nombre de requêtes par seconde. Ce type de contrôle active une limitation lorsque le QPS dépasse le seuil configuré, protégeant ainsi le système contre les surcharges soudaines.

Contrôle basé sur le nombre de threads

Cette méthode vise à éviter l'épuisement des threads métier. Par exemple, si un service dépendant ralentit, les requêtes en attente peuvent monopoliser les threads, menant à une dégradation des performances. Bien que des techniques d'isolation (comme les pools de threads dédiés) puissent limiter l'utilisation des ressources, elles ne contrôlent pas le temps d'attente des requêtes. Sentinel, en revanche, se contente de compter les threads actifs dans le contexte de la requête et rejette les nouvelles requêtes si le seuil est atteint, sans gérer la création de threads.

Exemple de démonstration : FlowThreadDemo sur GitHub.

Modes de contrôle de flux

Dans l'interface de configuration, trois modes sont disponibles sous les options avancées :

Pour illustrer, considérons une application Spring avec les ressources suivantes :

@RequestMapping("/accueil")
@SentinelResource("Consommateur-accueil")
public String accueil() {
    try {
        TimeUnit.SECONDS.sleep(1);
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    }
    return "accueil";
}

Mode direct : En configurant un seuil de QPS à 20 pour la ressource "Consommateur-accueil", un test de charge (par exemple avec JMeter) montrera environ 25% de requêtes rejetées lorsque le QPS dépasse ce seuil.

Mode d'association : Définissons deux ressources :

@RequestMapping("/ecriture")
@SentinelResource("Consommateur-ecriture")
public String ecriture() {
    return "succes";
}

@RequestMapping("/lecture")
@SentinelResource("Consommateur-lecture")
public String lecture() {
    return "succes";
}

En associant "Consommateur-lecture" à "Consommateur-ecriture", un test de charge sur "ecriture" entraînera la limitation des accès à "lecture". L'accès à "lecture" redeviendra normal une fois le test de charge terminé.

Mode chemin : Pour activer ce mode, il faut désactiver la convergence du contexte via la configuration :

spring.cloud.sentinel.web-context-unify=false

Ensuite, définissons une ressource commune :

@Service
public class ServiceBonjour {

    @SentinelResource("ServiceBonjour")
    public String bonjour() {
        return "Bonjour service";
    }
}

Et deux points d'entrée :

@RequestMapping("/consommateur/bonjour1")
public String bonjour1() {
    return serviceBonjour.bonjour();
}

@RequestMapping("/consommateur/bonjour2")
public String bonjour2() {
    return serviceBonjour.bonjour();
}

En configurant la limitation pour le chemin "/consommateur/bonjour1" vers "ServiceBonjour", seuls les accès via ce chemin seront limités. Un test de charge sur "/consommateur/bonjour1" provoquera des rejets, tandis que "/consommateur/bonjour2" restera accessible.

Effets de contrôle de flux

Ces effets ne sont applicables que lorsque le seuil est basé sur le QPS :

Réchauffement : En configurant une durée de réchauffement de 5 secondes et un seuil de QPS maximal de 20, le nombre de requêtes autorisées augmentera graduellement pendant cette période, comme le montrent les résultats de test.

File d'attente : Ce mode impose un intervalle constant entre les requêtes, assurant un débit uniforme. Par exemple, avec un seuil de QPS de 10 et un temps d'attente configuré à 5 secondes, le débit de sortie restera stable à 10 QPS, indépendamment des variations du trafic entrant, comme observé via les métriques en temps réel.