Pas besoin d'écrire une seule ligne de code pour implémenter les capacités de protection du trafic de n'importe quelle méthode

Auteur: dix sommeil

Contexte

La stabilité des microservices a toujours été un sujet de grande préoccupation pour les développeurs. Avec l'évolution de l'entreprise d'une architecture monolithique vers une architecture distribuée et l'évolution des méthodes de déploiement, les dépendances entre les services sont devenues de plus en plus complexes, et les systèmes d'entreprise sont également confrontés à d'énormes défis de haute disponibilité. Pendant l'épidémie, vous avez peut-être vécu les scénarios suivants :

Lors d'une réservation en ligne pour acheter des masques, le pic de trafic instantané a fait que le système a dépassé la charge maximale, la charge a grimpé en flèche et l'utilisateur n'a pas pu passer de commande ;
Lors de la sélection de cours en ligne, trop de demandes de sélection de cours sont soumises en même temps et le système ne peut pas répondre ;
Il y a trop d'utilisateurs dans les conférences en ligne en même temps pendant le bureau/l'enseignement en ligne, et les conférences sont relativement bloquées ;

Ces scénarios de disponibilité réduite affecteront sérieusement l'expérience utilisateur, nous devons donc utiliser certains moyens pour nous protéger à l'avance contre les facteurs instables, et nous devons également avoir la capacité d'arrêter rapidement les pertes en cas de trafic soudain.

Dégradation du contrôle de flux - un élément important pour assurer la stabilité des microservices

De nombreux facteurs affectent la disponibilité des microservices, et ces scénarios instables peuvent avoir de graves conséquences. Du point de vue du trafic des microservices, nous pouvons grosso modo le diviser en deux scénarios courants :

Le propre trafic du service dépasse la capacité de charge, ce qui entraîne une indisponibilité. Par exemple, l'augmentation du trafic et la livraison de tâches par lots font monter en flèche la charge du service et la demande ne peut pas être traitée normalement.

Le trafic est très aléatoire et imprévisible. La première seconde peut être calme et la seconde suivante, il peut y avoir des pics de trafic (comme la scène de Double Eleven à 0h00). Cependant, la capacité de notre système est toujours limitée. Si le trafic soudain dépasse la capacité du système, cela peut entraîner le non-traitement des requêtes, le ralentissement du traitement des requêtes accumulées, la montée en flèche du CPU/de la charge, et enfin le plantage du système. . Par conséquent, nous devons limiter ce type de trafic en rafale pour nous assurer que le service n'est pas submergé lors du traitement des demandes autant que possible.

Le service n'est pas disponible dans sa propre chaîne en raison de sa dépendance à d'autres services indisponibles. Par exemple, notre service peut dépendre de plusieurs services tiers. Si un service de paiement est anormal, l'appel est très lent, et l'appelant ne l'empêche pas et ne le traite pas efficacement, le pool de threads de l'appelant sera plein, affectant le service lui-même. Dans un système distribué, la relation d'invocation est maillée et complexe, et la défaillance d'un service peut entraîner des réactions en cascade, rendant l'ensemble du lien indisponible.

Un service appelle souvent d'autres modules, qui peuvent être un autre service distant, une base de données ou une API tierce. Par exemple, lors d'un paiement, il peut être nécessaire d'appeler à distance l'API fournie par UnionPay ; pour interroger le prix d'un certain produit, une requête de base de données peut être nécessaire. Cependant, la stabilité de ce service dépendant n'est pas garantie. Si le service dépendant est instable et que le temps de réponse de la requête devient plus long, le temps de réponse de la méthode appelant le service deviendra également plus long, les threads s'accumuleront, et éventuellement le pool de threads de l'entreprise elle-même peut être épuisé, et le service lui-même changera également. ne doit pas être disponible. Les architectures de microservices modernes sont distribuées et se composent d'un très grand nombre de services. Différents services s'appellent pour former une chaîne d'appel complexe. Les problèmes ci-dessus auront un effet grossissant dans l'appel de lien. Si un anneau sur un lien complexe est instable, il peut être mis en cascade, rendant éventuellement le lien entier indisponible. Par conséquent, nous devons fusionner et rétrograder les services instables, couper temporairement les appels instables et éviter les facteurs instables locaux à l'origine de l'avalanche globale.

La gouvernance des services MSE est basée sur les capacités de protection de la stabilité du composant Sentinel de limitation et de rétrogradation du courant d'Ali, et prend le trafic comme point d'entrée pour aider à assurer la stabilité des services à partir de plusieurs dimensions telles que le contrôle de flux, le contrôle de la concurrence, la rétrogradation des disjoncteurs, la protection des points d'accès. , et la protection adaptative du système. , couvrant plusieurs scénarios tels que les microservices, les passerelles cloud natives et les maillages de services.

Après avoir présenté les scénarios et les capacités de dégradation du contrôle de flux, parlons du protagoniste sur lequel nous allons nous concentrer aujourd'hui : la capacité d'amélioration dynamique de l'exécution. Nous présenterons comment mettre en œuvre la dégradation du contrôle de flux à tout moment grâce à la gouvernance des services MSE en un clic, y compris, mais sans s'y limiter, les interfaces d'accès Web, Rpc, SQL, Redis et autres, les méthodes commerciales écrites arbitrairement, les interfaces de cadre, etc.

Capacité d'amélioration de l'exécution - dégradation du contrôle de flux en un clic à tout moment

Comment ajouter une capacité de dégradation du contrôle de flux à une méthode spécifiée lors de l'exécution ? Ci-dessous, je présenterai brièvement une démo à titre d'exemple. Nous avons écrit le code métier suivant, nous avons écrit une simple application Spring Boot, où une méthode est une méthode interne écrite à volonté.

@SpringBootApplication
public class AApplication {

    public static void main(String[] args) {
        SpringApplication.run(AApplication.class, args);
    }

    @Api(value = "/", tags = {"入口应用"})
    @RestController
    class AController {
        ...
    @ApiOperation(value = "HTTP 全链路灰度入口", tags = {"入口应用"})
        @GetMapping("/a")
        public String restA(HttpServletRequest request) {
            return a(request);
        }
        
        private String a(HttpServletRequest request) {
            StringBuilder headerSb = new StringBuilder();
            Enumeration<String> enumeration = request.getHeaderNames();
            while (enumeration.hasMoreElements()) {
                String headerName = enumeration.nextElement();
                Enumeration<String> val = request.getHeaders(headerName);
                while (val.hasMoreElements()) {
                    String headerVal = val.nextElement();
                    headerSb.append(headerName + ":" + headerVal + ",");
                }
            }
            return "A"+SERVICE_TAG+"[" + inetUtils.findFirstNonLoopbackAddress().getHostAddress() + "]" + " -> " +
                    restTemplate.getForObject("http://sc-B/b", String.class);
        }
        ...
    }
}

Jusqu'à présent, nous ne pouvons pas voir la méthode a dans la surveillance. Nous ne pouvons voir que l'interface de restA ou les données de surveillance de GET:/a, et nous pouvons configurer les règles de limitation et de dégradation actuelles pour celle-ci.

Dans la méthode open source, nous devons ajouter la dépendance de Sentinel au code et ajouter des fonctionnalités Sentinel à l'annotation de configuration de méthode com.alibabacloud.mse.demo.AApplication.AController#a ou à la méthode de codage

// 注解方式进行埋点，注解方式受 AOP 代理的诸多限制
@SentinelResource("com.alibabacloud.mse.demo.AApplication.AController:a")
private String a(HttpServletRequest request) {
    StringBuilder headerSb = new StringBuilder();
    Enumeration<String> enumeration = request.getHeaderNames();
    while (enumeration.hasMoreElements()) {
        String headerName = enumeration.nextElement();
        Enumeration<String> val = request.getHeaders(headerName);
        while (val.hasMoreElements()) {
            String headerVal = val.nextElement();
            headerSb.append(headerName + ":" + headerVal + ",");
        }
    }
    return "A"+SERVICE_TAG+"[" + inetUtils.findFirstNonLoopbackAddress().getHostAddress() + "]" + " -> " +
            restTemplate.getForObject("http://sc-B/b", String.class);
}

// SDK 方式增加流控降级能力，需要侵入业务代码
private String a(HttpServletRequest request) {
    Entry entry = null;
    try {
        entry = SphU.entry("HelloWorld");
        
        StringBuilder headerSb = new StringBuilder();
        Enumeration<String> enumeration = request.getHeaderNames();
        while (enumeration.hasMoreElements()) {
            String headerName = enumeration.nextElement();
            Enumeration<String> val = request.getHeaders(headerName);
            while (val.hasMoreElements()) {
                String headerVal = val.nextElement();
                headerSb.append(headerName + ":" + headerVal + ",");
            }
        }
        return "A"+SERVICE_TAG+"[" + inetUtils.findFirstNonLoopbackAddress().getHostAddress() + "]" + " -> " +
                restTemplate.getForObject("http://sc-B/b", String.class);
    } catch (BlockException ex) {
      System.err.println("blocked!");
    } finally {
        if (entry != null) {
            entry.exit();
        }
    }
}

Si vous avez besoin de coder, il y aura naturellement de nombreux inconvénients : pour augmenter les dépendances, il faut changer le code, et il faut republier.

Alors, comment pouvons-nous atteindre la limite actuelle et la capacité de rétrogradation de com.alibabacloud.mse.demo.AApplication.AController#a sans écrire une ligne de code ?

Configurer les règles d'écran blanc d'exécution

Configurez la règle de blanchiment d'exécution, sélectionnez l'interface actuellement appliquée du type d'incorporation personnalisé et renseignez les classes et les méthodes.

Bien sûr, nous pouvons voir que notre capacité de règle d'écran blanc prend non seulement en charge la limitation et la rétrogradation dynamiques du courant, mais prend également en charge la collecte des journaux d'accès et des contextes de demande à tout moment.

Données de surveillance observées pour la méthode spécifiée

Nous trouvons l'application cible dans Application Governance et voyons les données de surveillance de la méthode spécifiée com.alibabacloud.mse.demo.AApplication.AController#a dans Interface Monitoring > Custom Embedding Points

Configurer les règles de contrôle de flux

Nous pouvons cliquer sur le bouton "Ajouter une règle de protection" dans le coin supérieur droit de l'aperçu de l'interface pour ajouter une règle de contrôle de flux :

Nous pouvons configurer les règles de contrôle de flux les plus simples en mode QPS. Par exemple, dans l'exemple ci-dessus, le nombre d'appels d'une seule machine par seconde pour cette interface est limité à 1 fois au maximum.

Après avoir configuré les règles, attendez un moment pour voir l'effet de limitation actuel sur la page de surveillance :

Le trafic refusé renvoie également un message d'erreur. Les points intégrés au framework fournis avec MSE ont tous une logique de traitement de contrôle de flux par défaut, telle que le renvoi de 429 trop de demandes après la limitation de l'interface Web et la levée d'exceptions lorsque la couche DAO et les méthodes Java sont limitées.

Résumer

Nous résumons la capacité d'écran blanc d'exécution dans les règles suivantes : WhiteScreenRule = Taget + Action****

Cible:

ResourceTarget : interface cible, prend en charge Web, Rpc, SQL et toute méthode personnalisée
WorkloadTarget : instance cible, vous pouvez sélectionner toutes les machines ou spécifier l'adresse IP de la machine
TrafficCondition : que ce soit uniquement pour les exceptions, les appels lents et les étiquettes en niveaux de gris du lien complet

Action:

Collecte d'informations de diagnostic de contexte pertinentes, de paramètres, de valeurs de retour, de contextes de thread, d'objets cibles, d'informations sur le chargeur de classe, etc.
Si le journal est imprimé sur les liens suivants
Effectuez une rétrogradation de la limite actuelle
Flux spécifié pour le marquage et la teinture (planification)

Dans un avenir proche, MSE lancera un modèle basé sur les règles ci-dessus combinées à la gestion des journaux de la capacité d'amélioration dynamique. Nous avons non seulement une limite actuelle et une dégradation à tout moment en fonction de la capacité d'amélioration dynamique, mais nous aidons également à mieux comprendre dans le comportement de l'exploitation du trafic full-link et prendre des décisions Gouvernance et protection en temps réel.

MSE Sentinel a non seulement une large gamme d'applications dans les domaines du commerce électronique tels que Taobao et Tmall au sein d'Alibaba, mais a également un grand nombre de pratiques dans la finance Internet, l'éducation en ligne, les jeux, les industries de diffusion en direct et d'autres gouvernements à grande échelle et entreprises publiques. Avec la possibilité de limiter et de dégrader le courant pour n'importe quelle méthode, nous pouvons rapidement donner à n'importe quel système de microservice la capacité de se protéger contre le trafic, ce qui nous laisse plus de temps pour nous concentrer sur le développement rapide de l'entreprise et la stabilité du système. en toute confiance et laissez une équipe professionnelle faire des choses professionnelles.

Passerelle cloud native MSE prépayée, configuration enregistrée MSE prépayée premier achat 20 % de réduction, premier achat 1 an et plus 30 % de réduction. Cliquez ici pour plus de détails~