10 modèles de conception courants pour la résilience des API avec API Gateway
November 1, 2023
La résilience des API consiste à construire des API robustes capables de résister à divers défis, en garantissant qu'elles continuent à fonctionner efficacement. Les API Gateways jouent un rôle clé à cet égard, agissant comme point d'entrée pour les requêtes externes et gérant la communication entre différents services en tenant compte des modèles courants de résilience des API. L'un des API Gateways open-source populaires, Apache APISIX, offre une variété de fonctionnalités pour améliorer la résilience et la robustesse des API. Dans cet article, nous explorerons 10 modèles de conception courants pour la résilience des API et comment ils peuvent être implémentés en utilisant APISIX.
Voici la liste des 10 modèles de résilience des API :
- Limitation de débit.
- Réessai.
- Délai d'attente.
- Secours.
- Cache.
- Redondance.
- Vérifications de santé.
- Disjoncteur.
- Cloisonnement.
- Injection de fautes.
Qu'est-ce que la résilience des API ?
La résilience des API fait référence à la capacité d'une API à exécuter de manière constante et fiable ses fonctions prévues, même en cas d'erreurs, de trafic élevé ou de conditions imprévues. Il ne s'agit pas d'éviter les échecs, mais d'accepter le fait que les échecs se produiront et d'y répondre de manière à éviter les temps d'arrêt ou la perte de données. L'objectif de la résilience est de ramener l'application à un état de fonctionnement complet après un échec. Les API résilientes sont conçues pour gérer les échecs de manière élégante, que ces échecs proviennent de l'API elle-même, de services dépendants ou de facteurs externes tels que des problèmes de réseau ou de latence, une incompatibilité de version d'API, et d'autres problèmes pouvant survenir en raison de changements dans l'environnement ou de comportements utilisateurs inattendus.
Pourquoi la résilience des API au niveau de l'API Gateway ?
De nombreux frameworks de développement logiciel existants englobent un ensemble de pratiques et de modèles conçus pour garantir que les API restent disponibles, réactives et précises. Cependant, implémenter la résilience des API au niveau de l'API Gateway, plutôt que dans des services individuels ou ailleurs dans le système, offre plusieurs avantages stratégiques.
1. Contrôle centralisé : L'API Gateway sert de point d'entrée central pour toutes les requêtes API, offrant une opportunité unique de gérer et d'appliquer des modèles de résilience de manière unifiée sur tous les services. Cette centralisation simplifie l'implémentation et la maintenance des fonctionnalités de résilience.
2. Cohérence : En gérant la résilience au niveau de l'API Gateway, vous assurez une approche cohérente pour gérer les échecs, la limitation de débit, les délais d'attente et d'autres stratégies de résilience sur tous les services. Cette cohérence est cruciale pour maintenir un comportement système fiable et prévisible.
3. Réduction de la complexité : Implémenter des fonctionnalités de résilience dans chaque microservice peut entraîner des efforts dupliqués et une complexité accrue. L'API Gateway abstrait ces préoccupations, permettant aux développeurs de services de se concentrer sur la logique métier plutôt que sur la gestion de la résilience.
4. Amélioration de l'utilisation des ressources : L'API Gateway peut gérer efficacement les ressources et distribuer le trafic, en s'assurant qu'aucun service unique ne soit submergé. Cet équilibrage de charge contribue à la résilience globale du système.
5. Surveillance et journalisation simplifiées : Avoir un point unique par lequel tout le trafic API transite facilite la surveillance de la santé de vos services et la journalisation des problèmes. Cette vue centralisée est inestimable pour identifier et répondre rapidement aux problèmes.
6. Sécurité simplifiée : Les mesures de sécurité telles que l'authentification, l'autorisation et le chiffrement peuvent être appliquées de manière cohérente au niveau de l'API Gateway, garantissant que tous les services sont protégés sans nécessiter de configurations redondantes.
7. Performance améliorée : L'API Gateway peut implémenter la mise en cache et l'agrégation des réponses, réduisant le nombre d'appels aux services backend et améliorant les performances globales du système.
8. Dégradation gracieuse : En cas de défaillance d'un service, l'API Gateway peut rediriger le trafic ou fournir des réponses de secours, garantissant que le système dégrade gracieusement et continue à fournir des fonctionnalités.
9. Récupération plus rapide : La nature centralisée de l'API Gateway permet une implémentation plus rapide des correctifs et des mises à jour, garantissant que le système peut être rapidement restauré à pleine fonctionnalité après un échec.
10. Interaction client simplifiée : Les clients n'ont besoin d'interagir qu'avec l'API Gateway, qui fournit une interface cohérente et fiable, en abstraisant la complexité des microservices sous-jacents.
D'un point de vue développement, l'approche par API Gateway réduit également le temps nécessaire pour implémenter des modèles de résilience couramment utilisés. Découvrons chaque modèle dans l'exemple de la communication API entre les services d'une application de conférence typique et comprenons comment les activer.
Ce post se concentre principalement sur la partie théorique et fournit des références à la documentation pertinente. Les développeurs peuvent implémenter ces modèles en vérifiant chaque lien et en suivant les guides fournis. Avec APISIX, il est possible de configurer ces modèles de conception en utilisant l'Admin API, un fichier YAML statique ou l'APISIX Dashboard.
1. Limitation de débit
Comme son nom l'indique, la limitation de débit contrôle le nombre de requêtes qu'un client peut effectuer dans une période donnée. APISIX propose un plugin limit-req pour configurer la limitation de débit. Ce plugin vous permet de définir des règles basées sur les propriétés des requêtes individuelles (trop de requêtes d'un utilisateur, d'une application cliente ou d'un emplacement donné) pour limiter les requêtes, en s'assurant que votre API ne soit pas submergée par trop de requêtes.
La politique de limitation de débit peut également être utilisée pour limiter l'accès aux utilisateurs non autorisés. Consultez le guide pour voir comment utiliser le plugin pour la limitation de débit.
2. Réessai
Le modèle de réessai consiste à réessayer automatiquement une requête API si elle échoue. Avec APISIX, vous pouvez configurer le mécanisme de réessai pour un objet Upstream pour spécifier le nombre de réessais et les conditions dans lesquelles un réessai doit être tenté.
En configurant l'upstream avec des propriétés de réessai, APISIX envoie des requêtes de réessai automatiques au service backend Attendee si la requête précédente a expiré ou a échoué en raison d'un problème de réseau.
3. Délai d'attente
Définir un délai d'attente garantit qu'une requête ne reste pas indéfiniment en attente si le service backend ne répond pas. APISIX vous permet de configurer des délais d'attente pour vos API dans la même configuration de l'objet Upstream, en s'assurant que les requêtes sont terminées si elles prennent trop de temps à répondre.
Dans le cas où le service attendee répond lentement, APISIX peut appliquer un modèle fail-fast et répondre rapidement à la requête de l'application cliente pour améliorer la réactivité globale du système.
4. Secours
Un modèle de secours fournit une réponse par défaut lorsqu'un service est indisponible. APISIX vous permet de définir les priorités des upstream lorsque le point de terminaison principal échoue, l'API Gateway peut rediriger le trafic vers un service secondaire ou retourner une réponse prédéfinie en utilisant un plugin response-rewrite en cas de défaillances de service comme HTTP 500.
Ou vous pouvez utiliser le plugin proxy-cache pour mettre en cache les réponses et les servir lorsque le backend est indisponible. Par exemple, l'application mobile affiche une liste mise en cache des participants à la conférence lorsque le service attendee est indisponible.
5. Cache
La mise en cache des réponses peut réduire considérablement la charge sur vos services backend. APISIX propose un plugin proxy-cache qui vous permet de mettre en cache les réponses et de les servir directement depuis l'API Gateway, réduisant ainsi la latence et améliorant les performances.
Consultez le tutoriel Cache API responses pour apprendre comment utiliser le plugin proxy-cache.
6. Redondance
Chaque API Gateway fournit une fonctionnalité commune comme l'équilibrage de charge qui répartit les requêtes API entrantes sur plusieurs services backend (nœuds ou instances). Avoir des instances redondantes rend le système plus robuste contre ces événements irréguliers. APISIX prend en charge divers algorithmes d'équilibrage de charge tels que le round-robin, les connexions les moins utilisées et le hachage cohérent.
Dans le cas du service Attendee, vous pouvez démarrer deux instances et si le serveur A tombe en panne, les requêtes peuvent être servies par le second serveur.
7. Vérifications de santé
La vérification de santé est un mécanisme qui détermine si les services upstream sont sains ou non en fonction de leur réactivité. APISIX identifie si le service est disponible ou non en utilisant des vérifications de santé actives des upstream. Avec les vérifications de santé activées, APISIX ne transférera les requêtes qu'aux services upstream considérés comme sains, et ne transférera pas les requêtes aux services considérés comme non sains.
Pour vérifier périodiquement la santé de l'API, APISIX a besoin d'un chemin HTTP du point de terminaison de santé du service upstream. Ainsi, vous devez d'abord ajouter un point de terminaison /health pour le service attendee.
8. Disjoncteur
Le modèle de disjoncteur empêche un système d'effectuer des appels à un service susceptible d'échouer, protégeant ainsi le système contre les défaillances en cascade. APISIX propose deux options pour implémenter la fonctionnalité de disjoncteur : Utiliser un plugin api-breaker dans une configuration de Route ou activer des vérifications de santé passives des upstream. Les deux méthodes gèrent les échecs et empêchent les services upstream de tenter constamment des réessais si le service échoue ou fonctionne lentement.
APISIX surveille le nombre d'échecs récents qui se sont produits et utilise ces informations pour décider si l'opération doit être autorisée à continuer ou si une exception doit être retournée immédiatement.
9. Cloisonnement
Le modèle de cloisonnement isole les éléments au sein d'une application, en s'assurant que si une partie du système échoue ou est sous charge importante, les autres parties du système continuent à fonctionner. Pour garantir qu'un trafic important ou des problèmes dans les opérations de lecture du service Attendee n'affectent pas la disponibilité et les performances des opérations d'écriture vers le service Attendee, vous pouvez implémenter le modèle de cloisonnement en utilisant APISIX.
Vous créez des points de terminaison de route séparés dans l'API Gateway pour deux nœuds upstream afin que toutes les requêtes d'écriture soient transférées vers le Service A et toutes les requêtes de lecture vers le Service B.
10. Test de chaos
Le test de chaos peut aider à garantir qu'une API est résiliente dans des environnements de production. En l'utilisant, vous pouvez évaluer et renforcer la résilience de votre application ou des API de microservices contre divers types de défaillances, améliorant ainsi la fiabilité. Cette méthode permet l'introduction intentionnelle de délais et la terminaison forcée des requêtes avec des codes d'erreur désignés, facilitant la simulation de divers scénarios défavorables, y compris les interruptions de service, la demande excessive de service, les délais réseau importants et la segmentation du réseau.
Le Plugin d'injection de fautes d'APISIX offre également le même mécanisme pour simuler divers scénarios de défaillance tels que des erreurs ou des délais dans le service Attendee pour tester comment l'application cliente réagit à eux.
Conclusion
Dans ce billet de blog, nous avons passé en revue 10 modèles de conception courants pour la résilience des API, en démontrant comment les implémenter efficacement en utilisant APISIX. En centralisant les stratégies de résilience au niveau de l'API Gateway, les organisations peuvent atteindre une gestion cohérente, simplifiée et efficace du trafic API et de la gestion des erreurs.