Décoder la haute disponibilité des microservices : Exploration des stratégies de gouvernance des API avec Apache APISIX

Introduction

L'architecture des microservices est devenue le choix dominant pour l'architecture informatique aujourd'hui. Sa flexibilité et son extensibilité permettent aux entreprises de s'adapter plus facilement aux exigences commerciales en évolution rapide. Cependant, garantir la haute disponibilité des microservices est devenu un enjeu clé dans la conception architecturale. Dans ce contexte, les trois stratégies centrales de la gouvernance des services API — la limitation de débit, le disjoncteur et la dégradation — sont particulièrement importantes.

En tant que composant fondamental essentiel dans l'architecture des microservices, la passerelle API joue un rôle crucial dans la gouvernance des services. Apache APISIX, en tant que passerelle API cloud-native de nouvelle génération, offre non seulement des capacités de haute performance et de sécurité, mais fournit également des fonctionnalités riches de gestion du trafic. Dans la discussion qui suit, nous approfondirons l'approche "à trois volets" de la gouvernance des services API et fournirons des informations détaillées sur la manière d'appliquer ces stratégies dans APISIX pour garantir la haute disponibilité de nos services.

Stratégies de gouvernance des API

Limitation de débit

La limitation de débit, comme son nom l'indique, est un mécanisme restrictif mis en œuvre sur le trafic. Son principe central est de prévenir la surcharge du système, voire son effondrement, causée par un trafic excessif. Le concept fondamental réside dans la régulation du volume de requêtes dans des intervalles de temps spécifiques, permettant uniquement aux requêtes répondant à certaines contraintes d'accéder au système, assurant ainsi le fonctionnement stable des microservices et de l'ensemble du système. Dans des scénarios réels, le concept de limitation de débit est également évident. Par exemple, pendant les heures de pointe dans les stations de métro, plusieurs portes d'accès sont installées pour les contrôles de sécurité afin de guider une file d'attente ordonnée et fluide.

La limitation de débit peut être mise en œuvre de diverses manières, notamment :

Basée sur le nombre de requêtes : Suivi du nombre de requêtes dans chaque période de temps et limitation à un certain seuil. Par exemple, traiter un maximum de 100 requêtes par seconde.
Basée sur la fréquence des requêtes : Restriction de la fréquence des requêtes par client ou adresse IP pour éviter un nombre excessif de requêtes. Par exemple, autoriser un maximum de 10 requêtes par minute.
Basée sur le nombre de connexions : Limitation du nombre de connexions simultanées établies pour éviter de consommer des ressources système excessives. Par exemple, autoriser un maximum de 100 connexions simultanées.

Différentes stratégies de limitation de débit nous permettent de répondre à divers besoins de scénarios. Par exemple, pour des ressources API précieuses, nous pouvons limiter le nombre de requêtes à 10 par minute. Ou, pour améliorer la disponibilité des services, nous pouvons limiter le nombre de requêtes simultanées pour réduire le temps de réponse des services, entre autres scénarios. Une mise en œuvre appropriée de ces stratégies de limitation de débit peut aider à garantir le fonctionnement normal des services sous haute concurrence et des pics de trafic soudains.

Disjoncteur

Dans une architecture de microservices, il peut y avoir des situations où les services s'appellent mutuellement. Une fois qu'un service tombe en panne, il peut affecter d'autres services, voire entraîner l'effondrement de l'ensemble du système, un phénomène vivement qualifié de "défaillance en cascade" ou "effet avalanche". Le mécanisme de disjoncteur, en tant que mesure de protection contre les défaillances en cascade dans les microservices, est utilisé pour empêcher la propagation des défaillances. Lorsqu'un microservice présente des anomalies ou des retards, le disjoncteur sera déclenché rapidement en bloquant temporairement les requêtes vers ce service, assurant ainsi que la stabilité de l'ensemble du système ne soit pas compromise.

Le principe central du mécanisme de disjoncteur réside dans la surveillance en temps réel du temps de réponse des services ou des taux d'erreur. Une fois que ces métriques dépassent les seuils prédéfinis, le disjoncteur se déclenche automatiquement, arrêtant rapidement les requêtes vers le service défaillant jusqu'à ce qu'il revienne à un fonctionnement normal. Après la stabilisation du service, le disjoncteur se referme automatiquement, rétablissant l'accès au service. Ce mécanisme est similaire à une résistance dans un circuit électrique. Lorsque la tension dépasse sa plage de tolérance, la résistance coupe automatiquement le circuit pour empêcher un courant excessif d'endommager d'autres composants électroniques. Après inspection et réparation du circuit, la résistance se referme et le circuit reprend son fonctionnement normal.

En introduisant des mécanismes de disjoncteur, l'architecture des microservices peut mieux faire face aux problèmes potentiels de défaillance en cascade résultant des appels mutuels de services, assurant la stabilité et la fiabilité du système, en particulier dans des scénarios de haute pression.

Dégradation

La dégradation, en tant que stratégie efficace pour faire face à des charges système élevées, consiste à désactiver temporairement certaines fonctions non critiques ou à réduire modérément la qualité de certains services pour garantir le fonctionnement stable de l'ensemble du système. Dans l'architecture des microservices, l'application de mécanismes de dégradation peut masquer intelligemment certaines fonctions non essentielles ou temporairement dispensables, assurant ainsi le fonctionnement continu et stable des fonctions principales. Par exemple, dans une application de visioconférence, lorsque la bande passante du réseau est limitée, nous pouvons réduire la qualité de transmission vidéo ou désactiver temporairement la fonctionnalité vidéo pour garantir des appels audio clairs et stables, répondant ainsi aux besoins de communication de base de la réunion.

Les stratégies courantes incluent :

Dégradation de fonction : Fermeture ou restriction temporaire de l'accès à certaines fonctions pour garantir le fonctionnement normal des services principaux. Par exemple, une application de médias sociaux peut temporairement désactiver les fonctions "j'aime" ou "commentaire" pendant les heures de pointe pour permettre aux utilisateurs de naviguer normalement dans le contenu.
Dégradation de qualité : Pendant les charges système élevées, abaissement des exigences de qualité de certains services ou fonctions. Par exemple, comme mentionné précédemment, réduire la clarté vidéo ou le taux de trame pour garantir une communication fluide.

Limitation de débit, disjoncteur et dégradation dans APISIX

Comment pouvons-nous utiliser les trois grandes stratégies mentionnées ci-dessus activées dans APISIX pour améliorer la haute disponibilité des microservices ? Voici quelques exemples courants d'application à titre d'illustration.

Limitation de débit avec le plugin `limit-count`

APISIX fournit divers plugins intégrés de gestion du trafic tels que limit-count, limit-req et limit-conn. En fonction des besoins réels, nous pouvons choisir la méthode appropriée pour le contrôle du trafic. Prenons l'exemple du plugin limit-count, il limite le nombre total de requêtes dans un intervalle de temps spécifique et renvoie le nombre de requêtes restantes dans l'en-tête HTTP.

curl -i http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/get",
    "plugins": {
        "limit-count": {
            "count": 3,
            "time_window": 60,
            "rejected_code": 429,
            "key_type": "var",
            "key": "remote_addr"
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "httpbin.org:80": 1
        }
    }
}'

Disjoncteur avec le plugin `api-breaker`

Le plugin api-breaker dans APISIX déclenche automatiquement des mécanismes de disjoncteur basés sur des seuils prédéfinis pour prévenir les défaillances en cascade. Par exemple, il peut initier un disjoncteur lorsque les services en amont renvoient 3 codes d'état 500 ou 503 consécutifs et reprendre l'accès lorsqu'un code d'état 200 est reçu.

curl "http://127.0.0.1:9180/apisix/admin/routes/1" \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "api-breaker": {
            "break_response_code": 502,
            "unhealthy": {
                "http_statuses": [500, 503],
                "failures": 3
            },
            "healthy": {
                "http_statuses": [200],
                "successes": 1
            }
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "httpbin.org:80": 1
        }
    },
    "uri": "/get",
}'

Dégradation avec le plugin `fault-injection`

Les plugins fault-injection et mocking d'APISIX prennent en charge la définition de stratégies de dégradation pour désactiver temporairement certaines fonctions ou renvoyer directement des données prédéfinies pendant les charges système élevées, assurant la stabilité du système. Par exemple, le plugin fault-injection peut renvoyer directement des codes d'état HTTP et des valeurs de corps spécifiés aux clients.

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
       "fault-injection": {
           "abort": {
              "http_status": 200,
              "body": "Fault Injection!"
           }
       }
    },
    "upstream": {
       "nodes": {
           "httpbin.org:80": 1
       },
       "type": "roundrobin"
    },
    "uri": "/get"
}'

Conclusion

La limitation de débit, le disjoncteur et la dégradation, en tant que mesures cruciales de gouvernance des services dans l'architecture des microservices, jouent un rôle irremplaçable dans l'amélioration de la haute disponibilité des microservices. Ils agissent comme des boucliers solides, défendant l'architecture des microservices contre divers risques et défis potentiels. Face à des scénarios commerciaux divers, nous devons appliquer ces mesures de manière flexible et prudente pour garantir que la stabilité et la fiabilité de l'architecture des microservices soient optimalement protégées.