Nouveautés d'API7 Enterprise 3.2.9 : Amélioration de la configuration du Health Check
April 16, 2024
Introduction aux nouvelles fonctionnalités de vérification de santé
Dans la version 3.2.9 de API7 Enterprise, l'expérience d'interaction de configuration pour les vérifications de santé a été entièrement optimisée.
-
Les éléments de configuration auparavant dispersés ont été regroupés de manière logique, tels que les paramètres de sonde et les critères de détermination des nœuds sains et non sains, les rendant plus structurés.
-
Certains noms d'éléments de configuration abstraits ont été transformés en expressions plus intuitives et sémantiques, permettant aux utilisateurs de saisir directement les paramètres pertinents via un format de remplissage, offrant ainsi une compréhension plus claire des effets pratiques des configurations.
-
Lors de la configuration des nœuds en amont et des processus de vérification de santé, davantage de messages d'aide ont été ajoutés pour aider les utilisateurs à mieux comprendre le lien inhérent entre les nœuds en amont et les vérifications de santé, facilitant ainsi plus facilement la réalisation des tâches de configuration.
Concepts de base des vérifications de santé
Dans API7 Enterprise, le paramétrage de la priorité des nœuds en amont est étroitement lié aux mécanismes de répartition de charge et de vérification de santé. Lorsque les utilisateurs configurent plusieurs nœuds en amont avec des priorités différentes pour la passerelle, celle-ci donne la priorité aux nœuds de plus haute priorité lors de la répartition de charge. Cela signifie que tant que les nœuds de plus haute priorité restent sains, la passerelle continuera à acheminer le trafic vers ces nœuds.
Ce n'est que lorsque tous les nœuds de plus haute priorité sont considérés comme indisponibles en raison d'échecs de vérification de santé que la passerelle dégrade automatiquement, redirigeant le trafic vers les nœuds en amont de priorité inférieure. Cette conception garantit une utilisation efficace du trafic et une haute disponibilité du système.
Il est à noter que si plusieurs niveaux de priorité de nœuds en amont sont configurés dans le service, mais que la fonction de vérification de santé est désactivée, toutes les requêtes des clients seront toujours acheminées vers les nœuds de plus haute priorité, quel que soit leur état de santé réel.
Méthodes de configuration des vérifications de santé
Configuration de la sonde
Une sonde est utilisée pour détecter la vivacité et l'état de service des nœuds en amont. Dans APISIX, la sonde est comme un "inspecteur" qui frappe régulièrement à la porte pour vérifier si le service en amont fonctionne correctement. Si elle détecte des problèmes ou si le service est "indisponible", elle informe APISIX : "Ce service est actuellement indisponible, donc retenez les requêtes ici." Ce processus de "frapper à la porte" est effectué via des sondes.
La sonde comprend principalement les éléments de configuration suivants :
-
Schéma de la sonde : Le type de protocole utilisé par la sonde de vérification de santé, prenant en charge TCP, HTTP et HTTPS.
-
Concurrence : Cet élément de configuration permet de définir le nombre de requêtes de vérification de santé concurrentes. En d'autres termes, c'est le nombre de fois que vous souhaitez "frapper à la porte" simultanément pour vérifier la réactivité des services en amont. En ajustant la concurrence, vous pouvez simuler les requêtes concurrentes possibles dans des scénarios réels, évaluant ainsi mieux les performances et la stabilité des services en amont.
-
Hôte : Spécifie l'adresse de l'hôte du serveur en amont à vérifier. C'est comme déterminer à quelle maison "frapper à la porte".
-
Port : Le numéro de port du service en amont. C'est comme savoir à quelle porte frapper lors de la sonde.
-
Chemin : Si vous utilisez une sonde HTTP, cet élément de configuration spécifie le chemin de l'URL que vous souhaitez accéder. C'est comme dire à la sonde de vérifier la pièce exacte une fois à l'intérieur.
Critères de détermination des nœuds sains
Concernant la détermination des nœuds sains, le système vérifie régulièrement les nœuds précédemment marqués comme non sains à l'intervalle défini par l'utilisateur (en secondes) pour garantir une détection rapide et une gestion appropriée de toute anomalie transitoire des nœuds.
Si la sonde utilise le protocole TCP, le nœud est considéré comme sain après que la sonde se soit connectée avec succès au nœud en amont le nombre de fois défini par l'utilisateur.
Si la sonde utilise le protocole HTTP/HTTPS, le système considère le nœud comme sain uniquement lorsqu'il reçoit continuellement des requêtes de sonde avec des codes d'état spécifiés (tels que 200
et 302
) du nœud. Cela signifie que le nœud est considéré comme fonctionnant correctement uniquement lorsqu'il retourne continuellement ces codes d'état spécifiques.
Critères de détermination des nœuds non sains
Concernant la détermination des nœuds non sains, la méthode de configuration est similaire à celle des nœuds sains. Le système vérifie régulièrement les nœuds marqués comme sains à l'intervalle défini par l'utilisateur. Une fois que ces nœuds répondent aux conditions prédéfinies de non-santé, ils sont reclassés comme non sains.
Légèrement différent de la détermination des nœuds sains, un élément de configuration supplémentaire, la vérification des requêtes clients, est ajouté lors du processus de détermination des nœuds non sains. Lorsque cette fonctionnalité est activée, la passerelle ne se repose pas uniquement sur les résultats d'inspection de la sonde, mais observe et analyse également en profondeur les requêtes des clients et les réponses réelles des services en amont. Sur la base de ces données et des critères de jugement définis par l'utilisateur, la passerelle peut évaluer plus précisément l'état de fonctionnement des services en amont.
Meilleures pratiques pour les vérifications de santé
Sélection du type de sonde approprié
-
Sonde TCP : Adaptée aux scénarios nécessitant uniquement la confirmation de l'ouverture et de l'accessibilité du port de service. Par exemple, un service de base de données peut nécessiter uniquement une sonde TCP pour confirmer l'ouverture du port.
-
Sonde HTTP/HTTPS : Plus adaptée aux scénarios nécessitant la vérification que non seulement la connexion réseau est normale, mais aussi que le service peut traiter correctement les requêtes. Par exemple, pour un serveur web ou un service API, nous devons nous assurer qu'il peut non seulement recevoir des connexions, mais aussi retourner des pages ou des données correctes.
Configuration raisonnable des paramètres de vérification de santé
Lors de la configuration des vérifications de santé, faites attention à plusieurs paramètres clés :
-
Intervalle de vérification : Il ne doit pas être trop court pour éviter une surcharge inutile ou trop long pour éviter une réponse lente en cas de problème. Par exemple, pour un site web de commerce électronique à fort trafic, vérifier toutes les 30 secondes est un choix relativement raisonnable. Cet intervalle ne consomme pas excessivement les ressources du système et ne retarde pas la détection et la gestion des problèmes sur le site.
Bien sûr, cet intervalle n'est pas absolu, et des ajustements doivent être effectués en fonction de la situation réelle du site. Par exemple, si le site connaît des fluctuations importantes de trafic ou des pics de trafic pendant des périodes spécifiques (comme pendant des campagnes promotionnelles), il peut être nécessaire d'ajuster l'intervalle de vérification pour s'adapter à ces changements.
-
Délai d'attente : Le temps que la sonde attend pour une réponse du service. Si le service ne répond pas dans ce délai, la sonde considère le service comme non sain. Cette valeur doit être définie en fonction du temps de réponse réel du service.
-
Nombre de tentatives : Le nombre de fois que la sonde tente de se connecter avant de déterminer que le service est non sain. Cette valeur doit être modérée pour éviter des erreurs de jugement.
Ajustement des stratégies en fonction des besoins métier
Les stratégies de vérification de santé doivent être ajustées en fonction de la situation réelle des besoins métier. Si un service connaît généralement des charges élevées pendant des périodes spécifiques, les intervalles de vérification de santé peuvent être augmentés ou le nombre de tentatives réduit pendant ces périodes pour éviter une pression supplémentaire sur le service.
Activation de la vérification des requêtes clients selon les besoins
La vérification des requêtes clients peut déterminer efficacement l'état du service en fonction des requêtes métier réelles, en particulier pour identifier les problèmes étroitement liés à la logique métier. Cependant, elle peut ne pas convenir à tous les scénarios métier.
-
Services à faible trafic : Si le trafic du service est faible, les vérifications de santé passives basées sur les requêtes clients peuvent ne pas fournir suffisamment de points de données pour évaluer précisément l'état du service. Dans de tels cas, s'appuyer sur des vérifications actives par sonde peut être plus fiable.
-
Considérations de performance dans des environnements à haute concurrence : Les vérifications de santé passives nécessitent la surveillance et le traitement de chaque requête client, ce qui peut augmenter la surcharge de performance dans des environnements à haute concurrence. Si la performance est une préoccupation principale et que le service est déjà suffisamment surveillé par d'autres moyens, les vérifications de santé passives peuvent être envisagées pour être désactivées.
-
Existence d'autres systèmes de surveillance : Si des systèmes de surveillance matures ont déjà été déployés dans l'entreprise, capables de capturer et d'analyser l'état du service en temps réel, les vérifications de santé passives peuvent ne pas être nécessaires pour éviter la redondance des données et la complexité supplémentaire.
Conclusion
Les vérifications de santé sont un aspect crucial pour garantir la haute disponibilité des passerelles API. Dans la version 3.2.9 d'API7 Enterprise, nous avons entièrement optimisé l'interaction de configuration des vérifications de santé, simplifiant les opérations et améliorant l'expérience utilisateur.
En configurant correctement les sondes, en définissant les critères pour les nœuds sains et non sains, et en ajustant les stratégies en fonction des besoins métier réels, les utilisateurs peuvent surveiller plus efficacement l'état des services en amont, garantissant que le trafic est toujours acheminé vers les nœuds sains. Cela améliore non seulement la stabilité et la disponibilité du système, mais garantit également que les requêtes des utilisateurs reçoivent des réponses rapides et précises.