Pourquoi Apache APISIX est-il la meilleure passerelle API ?

De nos jours, les téléphones portables sont utilisés pour toutes sortes de choses, et diverses applications sont disponibles sur l'AppStore, y compris les réseaux sociaux, les utilitaires, les jeux, le style de vie, les achats en ligne, etc. La création de ces applications est indissociable des API. Par conséquent, les entreprises qui fournissent des services via des API doivent choisir une passerelle API fiable pour garantir la vitesse, la stabilité et la sécurité de leurs services.

Dans le paysage des passerelles API de la CNCF, il existe près de 20 types de passerelles API (sans inclure les services des fournisseurs de cloud), y compris Apache APISIX, Kong, Tyk, etc. Beaucoup d'entre elles se proclament comme étant le projet de passerelle API open source le plus populaire, la passerelle API de nouvelle génération, mais est-ce vraiment le cas ?

Dans cet article, nous allons analyser plusieurs passerelles API sous les angles de la popularité parmi les développeurs, de leurs licences open source, de leurs performances et de l'écosystème dans son ensemble. Dans cette analyse, nous verrons comment Apache APISIX est la passerelle API de nouvelle génération, surpassant ses pairs à bien des égards.

Les ingénieurs logiciels le savent bien

Les ingénieurs logiciels sont les utilisateurs et les développeurs des API et des passerelles API, donc la popularité parmi les ingénieurs est un indicateur direct de la tendance. Voici un graphique comparant le nombre total de contributeurs GitHub de quatre passerelles API : Apache APISIX, Kong, Tyk et Gloo.

Nous pouvons voir sur le graphique que Kong et Tyk ont commencé vers 2015, tandis qu'Apache APISIX et Gloo ont commencé plus tard en 2019. Plus significativement, nous pouvons également voir que le plus jeune, Apache APISIX, a la courbe la plus raide parmi tous et a accumulé plus de 320 contributeurs, surpassant Kong, le deuxième meilleur, de 57 personnes, devenant ainsi le projet de passerelle API ayant le plus grand nombre de contributeurs.

Outre le nombre total de contributeurs, le nombre de contributeurs actifs mensuels est un indicateur plus significatif. Les contributeurs actifs mensuels pour Tyk n'ont été qu'autour de 5 et dépassent rarement 10, tandis que Kong et Gloo ont fluctué entre 10 et 20. Pendant ce temps, Apache APISIX a des contributeurs actifs mensuels supérieurs à 20 de manière stable, et près de 40 au pic, ce qui en fait le projet de passerelle API le plus actif.

Derrière les quatre projets de passerelles API open source, il y a quatre entreprises commerciales correspondantes. Ainsi, un autre indicateur qui fait ressortir APISIX est le ratio du nombre de contributeurs actifs mensuels par rapport au nombre d'employés.

En 2022, Kong et Tyk ont un ratio de 4 %, et Gloo a un ratio de 24 %. En revanche, APISIX atteint presque 100 %. La raison derrière cela est que depuis le début, lorsque l'entreprise API7.ai a lancé le projet APISIX, elle a mis un effort continu dans la communauté open source et a gagné sa réputation parmi les développeurs.

Licence Open Source : Le facteur le plus important pour choisir une passerelle API open source

Depuis que MongoDB a changé sa licence open source en SSPL (Server Side Public License) en 2018, les entreprises doivent maintenant ouvrir leur propre code lorsque MongoDB est utilisé comme service géré. Par conséquent, les entreprises doivent prendre en compte sérieusement la licence open source d'un projet lors du choix d'un projet.

En surface, Apache APISIX, Kong et Gloo utilisent tous la licence Apache Version 2.0, favorable aux entreprises, et Tyk utilise la licence Mozilla Public License Version 2.0. En creusant plus profondément, Kong, Gloo et Tky sont tous soutenus par des fournisseurs open source commercialisés. Ils peuvent changer leur licence à tout moment, tout comme MongoDB, limitant l'utilisation libre par le cloud public ou d'autres entreprises, et vous obligeant à payer pour accéder aux nouvelles versions.

Personne ne connaît la probabilité des changements de licence. Ce risque, cependant, est comme l'épée de Damoclès, suspendue au-dessus des utilisateurs.

Dans de telles circonstances, choisir un projet open source de la Fondation Apache Software (ASF) ou de la CNCF est le meilleur choix, car ils ne peuvent pas modifier la licence du projet. Apache APISIX est un tel projet. C'est un projet de niveau supérieur de l'ASF, ce qui signifie qu'aucune entreprise commerciale n'a un contrôle absolu sur le projet Apache APISIX, tous les codes appartiennent à l'ASF et la licence ne sera pas modifiée. Les utilisateurs entreprises peuvent l'utiliser librement sans craindre de recevoir des e-mails d'enquête des avocats et des services de conformité.

Performance d'Apache APISIX, Kong et Gloo

Une question fréquemment posée dans la communauté : lequel a la meilleure performance, Gloo basé sur Envoy ou APISIX basé sur NGINX ? Bien que la performance ne soit pas la métrique la plus critique, c'est sans aucun doute la métrique la plus directe. Le tableau ci-dessous montre les scores de référence d'Apache APISIX et de Gloo. Le QPS d'Apache APISIX est 4,6 fois celui de Gloo, et la latence d'Apache APISIX est seulement 7 % de celle de Gloo.

Le choix de NGINX ou Envoy n'est pas le facteur principal de la différence de performance, mais l'optimisation sous-jacente qu'APISIX a effectuée dans son code source. Même comparé à KONG, qui est également basé sur NGINX, APISIX a un énorme avantage en termes de performance. Le graphique ci-dessous est extrait du rapport de GigaOm sur les tests de l'édition Enterprise de Kong et de l'édition Enterprise de AP7 (Vous pouvez nous contacter pour les données complètes).

La latence de Kong est des dizaines voire une centaine de fois supérieure à celle d'API7 (édition Enterprise créée par les auteurs d'Apache APISIX).

Pourquoi APISIX a-t-il un tel avantage en termes de performance ? Il n'y a pas de secrets devant le code.

Les paroles sont bon marché, montrez-moi le code

Maintenant, analysons Apache APISIX, Kong et Gloo d'un point de vue technique. L'avantage d'Apache APISIX repose principalement sur l'optimisation et l'innovation du code source. Les avantages de ces technologies ne se reflètent pas nécessairement dans un simple PoC (Proof of Concept), mais dans un environnement de production plus complexe.

Avant l'émergence du projet APISIX, il existait de nombreuses passerelles API commerciales ou produits de passerelles API open source. Ces produits stockaient les données API, les informations de routage, les certificats et les données de configuration dans une base de données relationnelle. Les avantages de stocker ces données dans des bases de données relationnelles sont très évidents. Les utilisateurs peuvent utiliser des instructions SQL pour effectuer des requêtes flexibles, et il est également pratique pour les utilisateurs d'effectuer des sauvegardes et une maintenance ultérieure.

Cependant, la passerelle est un middleware qui gère tout le trafic provenant du client. L'exigence de disponibilité est extrêmement élevée. Si la passerelle API dépend d'une base de données relationnelle, cela signifie qu'une fois que la base de données relationnelle tombe en panne (comme une panne ou une perte de données), la passerelle API sera également affectée, et la disponibilité de l'ensemble du système en souffrira.

Pour réduire les dommages, APISIX a structuré son architecture pour éviter la possibilité de panne et de perte de données. APISIX a utilisé etcd pour stocker les données de configuration au lieu d'une base de données relationnelle, les avantages de cette approche sont les suivants :

1. Elle est plus alignée avec l'architecture cloud-native
2. Elle représente mieux le type de données nécessaire pour la passerelle API
3. Elle aura une disponibilité plus élevée
4. Les changements peuvent être notifiés en moins d'une milliseconde

Après avoir utilisé etcd pour stocker les données de configuration, les utilisateurs n'ont qu'à surveiller les mises à jour d'etcd pour les changements de données. APISIX sera en mesure d'obtenir la dernière configuration en quelques millisecondes, atteignant un effet en temps réel. Si nous interrogeons la base de données, cependant, cela peut prendre 5 à 10 secondes pour obtenir les dernières informations de configuration. Par conséquent, l'utilisation d'etcd comme schéma de stockage rend non seulement APISIX plus cloud-native, mais aussi plus disponible.

Algorithme de correspondance de route haute performance

Pour traiter une requête, la passerelle API doit faire correspondre l'expression cible avec les informations d'hôte, l'URI, les méthodes HTTP et d'autres informations de chaque requête. Ainsi, un algorithme de correspondance efficace est crucial. L'algorithme basé sur le hachage a de bonnes performances, mais ne peut pas réaliser de correspondance floue. Les expressions régulières peuvent effectuer une correspondance floue, mais les performances ne sont pas aussi bonnes. La solution d'Apache APISIX est d'utiliser un arbre, une structure de données de recherche efficace qui supporte la correspondance floue. Plus précisément, Apache APISIX utilise un arbre radix (arbre de préfixes compressé), une structure de données qui ne compresse que les nœuds intermédiaires avec un seul enfant. Parmi tous les produits de passerelle API connus, Apache APISIX est le premier à appliquer l'arbre radix dans la correspondance de routes et supporte le scénario où un préfixe peut correspondre à plusieurs routes. Pour les détails d'implémentation, voir lua-resty-radixtree.

Lors de la correspondance d'une requête, l'algorithme avec l'arbre radix la fera correspondre progressivement, avec une complexité O(K) (K est la longueur de l'URI dans la route, et elle est indépendante du nombre d'API). Cet algorithme convient très bien dans les scénarios où il y a un grand nombre de routes, comme sur les clouds publics ou les CDN. Il n'a également aucun problème à gérer un grand nombre de routes qui augmentent rapidement.

Algorithme de correspondance d'IP haute performance

Une adresse IP a deux notations : la notation IP standard et la notation CIDR, prenant l'IPv4 32 bits comme exemple :

• Notation IP standard : 192.168.1.1
• Notation CIDR : 192.168.1.1/8

La correspondance d'IP et la correspondance de routes d'Apache APISIX utilisent des algorithmes différents. Prenons l'IP 192.168.1.1 comme exemple, puisque la plage de chaque segment IP est de 0 à 255, nous pouvons penser que l'adresse IP est composée de quatre nombres entiers de 16 bits, et la longueur de l'IP est fixe. Ainsi, nous pouvons utiliser un algorithme plus efficace pour compléter la correspondance.

Supposons qu'il y ait une bibliothèque d'IP contenant 500 enregistrements IPv4, APISIX mettra en cache les 500 enregistrements IPv4 dans la table de hachage, et utilisera la table de hachage pour la correspondance d'IP. La complexité temporelle est O(1). D'autres passerelles API complètent la correspondance d'IP par itération de liste et chaque requête envoyée à la passerelle peut être itérée jusqu'à 500 fois. Par conséquent, l'algorithme de correspondance d'IP haute précision d'APISIX améliore grandement l'efficacité des scénarios nécessitant une correspondance massive de listes d'autorisation et de refus d'IP (comme WAF).

Raffinement des routes

Les passerelles API font correspondre les règles prédéfinies avec diverses informations des requêtes, telles que les informations d'hôte, l'URI, les paramètres de requête URI, les paramètres de chemin URI, les méthodes HTTP, les en-têtes de requête, etc. Ces informations sont supportées par la plupart des passerelles API. Cependant, Apache APISIX supporte plus de données en plus de celles-ci pour résoudre des cas plus complexes.

Premièrement, Apache APISIX supporte les variables intégrées de NGINX, ce qui signifie que nous pouvons utiliser des dizaines de variables intégrées de NGINX comme paramètres de correspondance, y compris uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_name.

Pour une liste des variables intégrées de NGINX, voir les variables NGINX.

Deuxièmement, Apache APISIX supporte les expressions conditionnelles comme règles de correspondance, et sa structure est [var, opérateur, val], ...]], où :

• Les valeurs de var peuvent être des variables intégrées de NGINX.
• L'opérateur supporte égal, supérieur à, inférieur à, expressions régulières, contient, etc.

En supposant que l'expression est ["arg_name", "==", "json"], cela signifie s'il y a une valeur de paramètre name égale à json dans les paramètres de requête URI de la requête actuelle. Apache APISIX implémente cette fonctionnalité via sa bibliothèque lua-resty-expr. Pour plus de détails, veuillez vous référer à lua-resty-expr. Cette fonctionnalité donne à l'utilisateur beaucoup de flexibilité et est hautement extensible.

En outre, Apache APISIX permet aux utilisateurs de configurer le ttl (time to live) des routes.

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

Le code ci-dessus signifie qu'APISIX supprimera automatiquement la configuration de routage après 60 secondes, ce qui sera nécessaire pour certains scénarios de vérification temporaire, comme la mise en production progressive. C'est également très pratique pour le fractionnement du trafic en ligne, une fonctionnalité que les autres produits de passerelle n'ont pas.

Enfin, Apache APISIX supporte les fonctions de filtre personnalisées, on peut écrire des fonctions Lua personnalisées dans le paramètre filter_func, par exemple :

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

Le paramètre d'entrée de filter_func est vars, et les variables NGINX peuvent être obtenues à partir de vars, puis la logique de filtrage peut être personnalisée.

Support des plugins multi-langages

Les utilisateurs ont souvent besoin de personnaliser certains développements et intégrations système de la passerelle API pour des scénarios spécifiques.

APISIX supporte actuellement plus de 80 plugins, mais il est encore difficile de couvrir tous les scénarios utilisateurs. Ainsi, la plupart des entreprises développeront des plugins personnalisés pour des métiers spécifiques, intégreront plus de protocoles et de systèmes via la passerelle, et réaliseront une gestion unifiée au niveau de la passerelle.

Dans les versions antérieures d'APISIX, les développeurs ne pouvaient utiliser que Lua pour développer des plugins. Bien que les plugins développés dans des langages de calcul natifs aient des performances très élevées, l'apprentissage de Lua, un nouveau langage de développement, nécessite du temps et des coûts d'apprentissage.

En réponse à cette situation, APISIX propose deux solutions.

La première solution est de supporter plus de langages de programmation courants (comme Java, Python, Go, etc.) via Plugin Runner. En utilisant Plugin Runner, les ingénieurs back-end peuvent communiquer via RPC local pour développer des plugins APISIX en utilisant les langages de programmation qu'ils connaissent. L'avantage est de réduire les coûts de développement et d'améliorer l'efficacité du développement. L'inconvénient sera des pertes de performance. Alors, existe-t-il un moyen d'atteindre des performances quasi-natives de Lua en utilisant des langages de haut niveau que les développeurs connaissent ?

La deuxième solution est d'utiliser Wasm pour développer des plugins, comme montré dans la partie gauche de la figure ci-dessus. Wasm (WebAssembly) a d'abord été utilisé comme une nouvelle technologie qui s'exécute dans les navigateurs, mais maintenant il montre également ses avantages côté serveur. Nous avons intégré Wasm dans APISIX, et les utilisateurs peuvent utiliser Wasm pour compiler du bytecode Wasm pour s'exécuter dans APISIX. Pour utiliser Wasm, nous avons développé un plugin Wasm où les utilisateurs peuvent développer des plugins APISIX quasi-natifs en utilisant des langages de programmation de haut niveau.

En conséquence, les utilisateurs peuvent utiliser Lua, Go, Java, Python, Node.js et Wasm pour écrire des plugins personnalisés sur APISIX. En rendant le développement facile, cela ouvre des portes pour le développement de plugins APISIX.

Conclusion

Dans cet article, nous avons analysé et comparé des produits de passerelles API sous plusieurs angles tels que les ingénieurs logiciels, les protocoles open source, l'évaluation des performances, la technologie et l'écosystème dans son ensemble. Nous pouvons voir qu'Apache APISIX est supérieur à bien des égards, un pionnier dans le réseau API.

Apache APISIX n'est pas seulement une passerelle API qui peut gérer le trafic nord-sud, mais a également des produits open source tels que APISIX Ingress Controller et Service Mesh.

Il fournit également des produits de niveau entreprise et des produits SaaS basés sur APISIX.

Essayez Apache APISIX et les produits Enterprise API7 dès aujourd'hui !