Pourquoi choisir Apache APISIX plutôt que NGINX ou Kong

La passerelle API est un composant d'infrastructure important à l'ère du cloud-native. Il existe deux critères courants pour évaluer une passerelle API : son niveau de dynamisme et la maturité de son observabilité. De nombreuses entreprises utilisaient auparavant Nginx ou Kong comme passerelle API, mais ont ensuite migré vers Apache APISIX. En tant que passerelle API conçue pour l'ère du cloud-native, Apache APISIX résout effectivement de nombreux points de douleur pour les entreprises dans diverses dimensions. Vous vous demandez peut-être pourquoi ?

Les limites de NGINX et Kong

À l'ère des services monolithiques, NGINX pouvait gérer la plupart des scénarios. Cependant, à l'ère du cloud-native, NGINX présente deux inconvénients dus à son architecture :

• NGINX ne prend pas en charge la gestion de clusters. Presque chaque entreprise possède son propre système de gestion de configuration NGINX. Bien que ces systèmes soient similaires, il n'existe pas de solution unifiée.
• NGINX ne prend pas en charge le rechargement à chaud des configurations. Si un utilisateur modifie la configuration de NGINX, il est nécessaire de recharger NGINX. De plus, dans Kubernetes, les services changent fréquemment. Ainsi, si NGINX est utilisé pour gérer le trafic, vous devez redémarrer le service souvent, ce qui est inacceptable pour les entreprises.

Kong résout les inconvénients de NGINX mais introduit de nouvelles limitations :

• Kong dépend d'une base de données PostgreSQL ou Cassandra, ce qui rend l'architecture de Kong très lourde et introduit une limitation de haute disponibilité pour l'entreprise. Si la base de données tombe en panne, toute la passerelle API échoue.
• Le routage de Kong utilise une recherche par parcours. Lorsqu'il y a plus de mille routes dans la passerelle, ses performances chutent considérablement.

APISIX résout toutes ces limitations et devient la meilleure passerelle API de l'ère du cloud-native.

Les avantages d'Apache APISIX

Architecture bien conçue

Tout d'abord, Apache APISIX possède une excellente architecture. Le cloud-native, en tant que tendance technologique actuelle, modifie l'architecture technique des entreprises traditionnelles. De nombreuses applications migrent vers des microservices et la conteneurisation. APISIX a suivi cette tendance technologique depuis sa création :

Comme le montre la figure ci-dessus, les côtés gauche et droit représentent respectivement le plan de données (Data Plane) et le plan de contrôle (Control Plane) d'APISIX :

• Data Plane : Basé sur la bibliothèque réseau de NGINX (sans utiliser le routage, la configuration statique et les modules C de NGINX), il utilise Lua et NGINX pour contrôler dynamiquement le trafic des requêtes.
• Control Plane : Les administrateurs peuvent opérer etcd via l'API RESTful intégrée. Grâce au mécanisme de surveillance (Watch) d'etcd, APISIX peut synchroniser la configuration sur chaque nœud en quelques millisecondes.

Pour la mise à jour des données, Kong utilise une méthode de sondage de base de données ; il peut prendre 5 à 10 secondes pour obtenir la dernière configuration, tandis qu'APISIX y parvient en surveillant les changements de configuration d'etcd, ce qui permet de contrôler le temps en millisecondes.

Comme APISIX et etcd prennent en charge le déploiement multi-instances, il n'y a pas de point de défaillance unique.

Écosystème riche

La figure suivante montre la carte de l'écosystème d'APISIX. On peut voir qu'APISIX prend en charge les protocoles de couche 7 (L7) tels que HTTP(S), HTTP2, Dubbo, et le protocole IoT MQTT, entre autres. De plus, APISIX prend en charge les protocoles de couche 4 (L4) comme TCP/UDP.

La partie droite de la figure contient des services open source ou SaaS, tels qu'Apache SkyWalking, Prometheus, HashiCorp Vault, etc. Au bas de la figure se trouvent les environnements de système d'exploitation, les fournisseurs de cloud et les environnements matériels les plus courants. En tant que logiciel open source, APISIX peut également être exécuté sur des serveurs ARM64.

APISIX prend en charge non seulement de nombreux protocoles et systèmes d'exploitation, mais aussi des plugins de programmation multi-langages. À ses débuts, APISIX ne prenait en charge que le langage Lua pour écrire des plugins. Dans ce cas, les développeurs devaient maîtriser la pile technologique liée à Lua et NGINX. Cependant, Lua et NGINX sont des technologies relativement niche, peu familières à la plupart des développeurs. Par conséquent, nous avons ensuite permis le développement de plugins sur APISIX avec plusieurs langages, et avons officiellement pris en charge des langages tels que Java, Golang, Node.js et Python.

Communauté active

La figure ci-dessous montre la courbe de croissance des contributeurs, où l'axe horizontal représente la chronologie et l'axe vertical représente le nombre total de contributeurs. On peut voir que les deux projets, Apache APISIX et Kong, sont relativement plus actifs. Apache APISIX a maintenu un excellent taux de croissance dès le premier jour et croît rapidement à un rythme proche du double de celui de Kong. En juillet 2022, le nombre de contributeurs d'APISIX a dépassé celui de Kong, ce qui montre la popularité d'APISIX. Bien sûr, il existe de nombreuses autres façons d'évaluer l'activité d'un projet, comme le nombre mensuel d'issues actives, le nombre total de PR, etc. La bonne nouvelle est qu'APISIX est également inégalé dans ces aspects.

Infrastructure de proxy unifiée

À partir de la figure ci-dessous, je pense que vous avez déjà compris l'objectif d'APISIX : unifier l'infrastructure de proxy.

Parce que le cœur d'APISIX est un service proxy haute performance, il ne lie aucune propriété environnementale. Par conséquent, lorsqu'il évolue en produits tels qu'Ingress et Service Mesh, vous n'avez pas besoin de modifier la structure interne d'APISIX. La suite vous présentera étape par étape comment APISIX prend en charge ces scénarios.

Équilibrage de charge et passerelle API

Le premier scénario concerne les cas traditionnels d'équilibrage de charge (LB) et de passerelle API. Comme APISIX est implémenté sur NGINX + LuaJIT, il possède des fonctionnalités de haute performance et de sécurité, et prend en charge le chargement dynamique de certificats SSL, l'optimisation de la poignée de main SSL, entre autres. En termes d'équilibrage de charge, APISIX performe également mieux. Passer de NGINX à APISIX ne dégrade pas les performances, mais améliore plutôt l'efficacité de gestion grâce à des fonctionnalités telles que la gestion unifiée.

Passerelle de microservices

APISIX vous permet d'écrire des plugins d'extension dans plusieurs langages, ce qui peut résoudre le principal problème rencontré par les passerelles API de microservices est-ouest : comment gérer de manière unifiée dans des environnements hétérogènes. APISIX prend également en charge la découverte de services comme Nacos, etcd et Eureka, ainsi que les méthodes DNS standard, ce qui peut complètement remplacer les passerelles API de microservices telles que Zuul, Spring Cloud Gateway et Dubbo.

Kubernetes Ingress

Actuellement, le projet officiel Kubernetes Ingress Controller de K8s est principalement développé sur la base du fichier de configuration NGINX, ce qui le rend légèrement insuffisant en termes de capacité de routage et de mode de chargement, avec certaines limitations évidentes. Par exemple, lors de l'ajout ou de la modification d'une API, il est nécessaire de redémarrer le service pour mettre à jour la nouvelle configuration NGINX. Redémarrer le service a un impact important sur le trafic en ligne.

Le APISIX Ingress Controller résout parfaitement toutes les limitations mentionnées ci-dessus : il prend en charge le rechargement à chaud complet. En même temps, il hérite de tous les avantages d'APISIX et prend également en charge les CRD natifs de Kubernetes, ce qui facilite la migration pour les utilisateurs.

Service mesh

Dans les cinq à dix prochaines années, l'architecture de service mesh basée sur le modèle cloud-native commencera à émerger. APISIX a également commencé à se positionner sur ce créneau à l'avance. Après de nombreuses recherches et analyses techniques, APISIX a pris en charge le protocole xDS. APISIX Mesh est né, et APISIX a également sa place dans le domaine du service mesh.

Résumé

Cela fait trois ans depuis le jour où Apache APISIX a été open-sourcé. La communauté très active et les études de cas ont prouvé qu'APISIX est la passerelle API parfaite pour l'ère du cloud-native. En lisant cet article, je pense que vous avez une compréhension plus complète d'APISIX.

Si vous avez des questions, vous pouvez laisser un message dans les issues GitHub ; les contributeurs de la communauté répondront rapidement ; bien sûr, vous pouvez également rejoindre le canal Slack d'APISIX et la liste de diffusion ; veuillez vous référer à Join Us.