Explorations techniques de la passerelle API open source Apache APISIX

Contexte

Apache APISIX est une passerelle API open source dynamique, en temps réel et haute performance qui fournit des fonctions riches de gestion du trafic telles que l'équilibrage de charge, le routage dynamique, les mises en production canari, la coupure de circuit, l'authentification et l'observabilité.

En tant que passerelle API, Apache APISIX peut aider les entreprises à traiter rapidement et en toute sécurité le trafic des API et des microservices dans des scénarios tels que les passerelles, Kubernetes Ingress et les maillages de services. De plus, elle peut gérer le trafic nord-sud du client vers le serveur et le trafic est-ouest entre les différents microservices de l'entreprise.

Open-sourcé le 6 juin 2019, APISIX a été donné à la Apache Software Foundation en octobre 2019 et est rapidement devenu un projet de niveau supérieur de la Apache Software Foundation en quelques mois.

Pourquoi APISIX a-t-il connu un tel essor en si peu de temps ? Quelles explorations techniques magiques APISIX a-t-il réalisées ? Pourquoi de plus en plus de développeurs et d'entreprises sont-ils prêts à utiliser APISIX ? Découvrons-le.

Principales fonctionnalités d'Apache APISIX

Indépendance vis-à-vis des bases de données

Il existait de nombreuses passerelles API commerciales ou projets open source de passerelles API avant l'arrivée du projet APISIX. Le problème potentiel de ces concurrents est que la plupart de ces produits stockent leurs données API, informations de configuration, configurations de certificats et informations de routage dans une base de données relationnelle.

Les avantages évidents du stockage dans une base de données relationnelle sont qu'il est facile pour les utilisateurs d'effectuer des requêtes flexibles avec des instructions SQL et de réaliser des sauvegardes et une maintenance ultérieure.

Cependant, chaque médaille a son revers. En tant que middleware de base, la passerelle API traitera tout le trafic client, ce qui augmente les exigences en matière de disponibilité. Si votre passerelle API dépend d'une base de données relationnelle, la passerelle sera affectée en cas d'erreur de base de données, comme un crash ou une perte de données. Dans ce cas, la limitation de la disponibilité globale du système est renforcée.

Par conséquent, les concepteurs d'APISIX ont tout fait pour éviter de tels problèmes du point de vue de l'architecture sous-jacente.

L'architecture d'APISIX est principalement divisée en deux parties. La première partie, appelée le plan de données, est le composant qui traite les requêtes et le trafic des clients. Il prend en charge l'authentification, le déchargement des certificats, l'analyse des logs et l'observabilité. Le plan de données ne stocke aucune donnée, ce qui en fait une structure sans état.

La deuxième partie est appelée le plan de contrôle. APISIX n'utilise pas de stockage de configuration traditionnel comme MySQL, mais etcd sur le plan de contrôle.

Les avantages de cette approche :

1. Plus en phase avec l'architecture cloud-native des produits
2. Plus adapté aux types de données stockées par la passerelle API
3. Mieux reflète les caractéristiques de haute disponibilité
4. Notifications des changements en millisecondes

En utilisant etcd, le plan de données n'a besoin que de surveiller les changements d'etcd. Si vous interrogez la base de données, il peut falloir 5 à 10 secondes pour obtenir la dernière configuration. Cependant, si vous surveillez les changements de configuration d'etcd, vous pouvez obtenir un retour en millisecondes pour un effet en temps réel.

Par conséquent, l'utilisation d'etcd au lieu d'une base de données relationnelle rend APISIX plus compatible avec l'environnement cloud natif au niveau inférieur et renforce ses avantages en matière de haute disponibilité.

Plugins pour plusieurs langages de programmation

Les passerelles API sont quelque peu différentes des bases de données et autres middleware. Par rapport à ces derniers, les passerelles sont plus fréquemment utilisées dans le développement personnalisé et l'intégration de systèmes.

Bien qu'APISIX ait publié de nombreux plugins officiels, il est encore difficile de couvrir tous les scénarios d'utilisation pour différents utilisateurs. Par conséquent, dans l'utilisation réelle, certains plugins personnalisés doivent être développés pour les besoins de l'entreprise, plus ou moins. APISIX intègre également plus de protocoles ou de systèmes via la passerelle et finit par atteindre une gestion unifiée au niveau de la passerelle.

Au début, APISIX ne supportait que le développement de plugins en langage Lua. L'avantage est que les plugins développés peuvent avoir des performances élevées grâce à l'optimisation sous-jacente du langage de programmation natif. Cependant, il y a un inconvénient évident, c'est que l'apprentissage de Lua, un nouveau langage, nécessite du temps et des coûts d'apprentissage.

Essentiellement, APISIX résout les problèmes de deux manières.

La première manière est de supporter plus de langages de programmation courants, tels que Java, Python, Go, etc., via le Runner Plugin. Si vous êtes un ingénieur backend, vous devriez connaître au moins un de ces langages ; alors, vous pouvez facilement utiliser le protocole RPC et développer un plugin APISIX en utilisant le langage que vous connaissez.

D'une part, cela est bénéfique pour réduire les coûts de développement et améliorer l'efficacité du développement. Cependant, d'autre part, il y a une certaine latence au niveau des performances. La question se pose donc. Y aurait-il une solution qui pourrait atteindre les performances natives de Lua tout en tenant compte des langages de haut niveau ?

Voici la deuxième méthode, montrée dans la partie gauche de l'image ci-dessus. WebAssembly a d'abord été utilisé comme une technologie côté front-end ou navigateur et offre progressivement ses avantages côté serveur.

En intégrant WebAssembly dans APISIX, les utilisateurs peuvent l'utiliser pour compiler en bytecode WebAssembly exécuté dans APISIX. L'effet ultime est de développer efficacement un plugin APISIX à la fois performant et écrit dans des langages de programmation de haut niveau.

Donc, dans la version actuelle d'APISIX, les utilisateurs peuvent utiliser Lua, Go, Python, Wasm, et d'autres méthodes pour personnaliser le code basé sur APISIX. Cette conception abaisse le seuil pour les développeurs et offre plus de possibilités pour les fonctions d'APISIX.

Rechargement à chaud des plugins

APISIX a deux avancées significatives par rapport à NGINX : APISIX supporte la gestion de cluster et le rechargement dynamique.

Si vous avez utilisé NGINX, vous savez que toutes les configurations de NGINX seront écrites dans le fichier de configuration nginx.conf. Pour effectuer un contrôle de cluster, vous devez modifier le fichier nginx.conf sur chaque serveur. Il n'y a pas de plan de contrôle de gestion centralisé dans tout le processus. Chaque NGINX est une combinaison du plan de données et du plan de contrôle. Le coût de gestion sera exceptionnellement élevé si les utilisateurs ont des dizaines ou des centaines de serveurs NGINX.

Dans le scénario mentionné ci-dessus, chaque serveur NGINX doit être redémarré pour fonctionner après la modification du fichier nginx.conf. Par exemple, pour les mises à jour de certificats ou les changements d'upstream, vous devez d'abord modifier le fichier de configuration et redémarrer le serveur pour que cela prenne effet. Cette méthode est à peine acceptable si votre demande n'est pas particulièrement importante. Cependant, à mesure que les API et les microservices apparaissent de plus en plus, l'impact sur le client sera énorme si le serveur doit redémarrer pour chaque modification.

• Mises à jour à chaud et plugins à chaud : Met à jour en continu ses configurations et plugins sans redémarrage !
• Réécriture de proxy : Supporte la réécriture de l'hôte, de l'URI, du schéma, de la méthode et des en-têtes de la requête avant de l'envoyer à l'upstream.
• Réécriture de réponse : Définit un code d'état de réponse personnalisé, un corps et un en-tête pour le client.
• Équilibrage de charge dynamique : Équilibrage de charge en round-robin avec poids.
• Équilibrage de charge basé sur le hachage : Équilibrage de charge avec des sessions de hachage cohérentes.
• Vérifications de santé : Active les vérifications de santé sur le nœud upstream et filtre automatiquement les nœuds malsains pendant l'équilibrage de charge pour assurer la stabilité du système.
• Coupure de circuit : Suivi intelligent des services upstream malsains.
• Miroir de proxy : Fournit la capacité de refléter les requêtes des clients.
• Fractionnement du trafic : Permet aux utilisateurs de diriger progressivement des pourcentages de trafic entre différents upstreams.

L'image ci-dessus liste les composants où APISIX implémente actuellement le rechargement à chaud. Nous pouvons voir que le code prend effet en temps réel de l'upstream au certificat et même au plugin. Certains membres de la communauté peuvent comprendre pourquoi l'upstream et les certificats sont dynamiques car les données changent fréquemment. Cependant, ils demanderaient pourquoi la modification du plugin doit être dynamique car ils considèrent que la modification du plugin est peu fréquente, ce qui semble inutile d'être très actif.

En tant que concepteurs sous-jacents d'APISIX, nous espérons qu'il peut être finalement dynamique, ce qui apporte un avantage significatif en augmentant plus de possibilités pour l'entreprise. Par exemple, les utilisateurs peuvent dépanner le code tout en modifiant le plugin de débogage sans changer de code de plugin. Dans de telles circonstances, l'utilisateur peut reproduire le problème à tout moment et l'enregistrer sans redémarrer. Le plugin avec fonction de débogage combiné avec le mécanisme de rechargement à chaud sera très flexible, aidant les développeurs à gagner du temps et des efforts dans le dépannage.

Orchestration dynamique des plugins

En plus du rechargement à chaud, APISIX supporte l'orchestration dynamique en temps réel entre les plugins. L'orchestration dynamique apporte également des possibilités infinies pour le fonctionnement des plugins.

Qu'est-ce que l'orchestration de plugins ? Lorsque nous formulons diverses exigences, nous espérons transformer une requête en un plugin, comme jouer avec des LEGO. Nous pouvons construire une variété infinie de formes possibles à travers une norme unifiée comme l'ajustement de forme et l'intersection, ce qui est l'un des plaisirs des LEGO. Pour les plugins d'APISIX, chaque plugin remplit un cas d'utilisation indépendant. Nous ne pouvons pas nous empêcher de demander s'il est possible de permettre aux utilisateurs de personnaliser leurs besoins avec des plugins comme s'ils jouaient avec des LEGO.

Par exemple, s'il y a 100 plugins dans APISIX, les utilisateurs ne verront que les fonctions de ces 100 plugins plutôt que leur flexibilité sous-jacente. Par conséquent, lors du développement de middleware, nous devons considérer ce que le produit peut être et comment doter plus de possibilités lorsque les gens les utilisent.

APISIX compte actuellement près de 100 plugins, mais il a bien plus de 100 possibilités. Par conséquent, après avoir développé sa capacité d'arrangement de plugins, la combinaison devient 100 * 99 * 98 * 97 * 96 * ..., proche de l'infini.

Par exemple, un code d'erreur se produira généralement après avoir limité le taux d'un utilisateur. Vous pouvez essayer de connecter un plugin de journalisation ou un plugin de rapport d'erreur pour l'enregistrement des activités ultérieures. L'image ci-dessous montre le modèle d'orchestration de plugins d'APISIX.

Cette fonctionnalité a un avantage caché : une suite de tests complète couvre le code de chaque plugin. Lorsque l'utilisateur arrange le plugin, il n'a pas besoin d'écrire de code. La conception serait extrêmement conviviale pour les chefs de produit, les ingénieurs de sécurité et les ingénieurs d'exploitation qui n'ont pas besoin de passer de longues heures à se former et à apprendre. Au lieu de cela, ils peuvent créer un nouveau plugin APISIX en déposant des plugins pour ajuster certains paramètres. De plus, la qualité du code du nouveau plugin est aussi élevée que le code officiel de l'open source APISIX.

Passerelle pour le trafic omnidirectionnel

Les ingénieurs côté serveur qui font du développement lié aux passerelles pourraient être familiers avec deux concepts de base : le trafic Nord-Sud, qui fait référence au trafic des clients, navigateurs ou appareils IoT (Internet des Objets) vers le serveur, et le trafic Est-Ouest, qui fait référence aux appels mutuels entre les systèmes et les microservices au sein des entreprises.

Les composants sont différents pour traiter le trafic nord-sud et est-ouest. Par exemple, le trafic nord-sud peut passer par un équilibreur de charge, aller à la passerelle API, puis entrer dans une passerelle de service. C'est pourquoi il y a des composants comme NGINX, APISIX et Spring Cloud Gateway. Lors du traitement du trafic est-ouest avec un maillage de services, vous pouvez utiliser des composants comme Envoy, ce qui semble beaucoup, mais vous pouvez trouver leurs similitudes si vous vous concentrez sur leurs fonctions. La plupart sont des plugins pour la planification de routage, l'upstream dynamique et l'authentification sécurisée. Dans ce cas, pouvons-nous unifier les composants qui traitent le trafic nord-sud et est-ouest ? La manière idéale est que lorsqu'une requête d'un client entre dans le serveur, elle est entièrement prise en charge par APISIX. Qu'il s'agisse de trafic nord-sud ou est-ouest, tout le trafic et les données sont contrôlés via le plan de contrôle. C'est entièrement réalisable avec la technologie actuelle d'APISIX.

Certains de nos utilisateurs confirment déjà que ce mode peut réduire considérablement les coûts d'exploitation et de maintenance de l'utilisateur. En même temps, il peut réduire la complexité, améliorant ainsi la vitesse de réponse de l'ensemble du système. De plus, ces retours positifs donnent une direction plus claire pour les itérations ultérieures d'APISIX, permettant à APISIX d'essayer plus de fonctions et de rôles au niveau de la passerelle de trafic complet.

Support pour plusieurs composants de découverte de services

La passerelle est un composant fondamental mais vital. Elle traite toutes les requêtes des clients et s'intègre avec divers systèmes et projets open source, ce qui est plus important.

Un autre composant essentiel - la découverte de services et l'enregistrement seront utilisés dans l'intégration avec d'autres éléments. Les utilisateurs placeront divers services dans des parties séparées, comme Eureka et Nacos. Par conséquent, il est courant que plusieurs composants de découverte de services coexistent dans des systèmes informatiques à grande échelle et de longue durée.

Dans cette situation, tout le trafic d'entrée et de sortie devient des passerelles. Presque toutes les passerelles ne supportent qu'une seule découverte de services. Vous devez spécifier un composant de découverte de services Nacos séparé sur la route A et un autre composant Consul sur la route B. Par conséquent, vous devez déployer plusieurs passerelles pour faire correspondre des passerelles spécifiques à différents composants de découverte de services.

Actuellement, APISIX supporte non seulement la découverte de services sur le plan de données, mais supporte également progressivement les composants d'enregistrement et de découverte de services sur le plan de contrôle. C'est une solution très efficace pour certains services d'entreprise à grande échelle et de longue durée. Vous pouvez facilement vous connecter à divers composants de découverte et d'enregistrement de services en déployant une seule passerelle API.

Exploration des scénarios multi-cloud et hybrides

Si les utilisateurs déploient la passerelle dans un environnement de production équipé d'une architecture Cloud-Native, le multi-cloud et l'hybride doivent être un scénario technique à long terme. D'un autre côté, si APISIX est configuré avec toutes les fonctionnalités, performances, plugins et découverte de services multiples, le problème vient inévitablement de la manière de faire fonctionner les utilisateurs de manière optimale dans un environnement de production. Les scénarios multi-cloud et hybrides apportent plus de défis à APISIX. Par conséquent, plus de détails doivent être pris en compte.

1. Support de mTLS pour l'upstream et le downstream

Nous n'avions pas reconnu que la fonction de support de mTLS pour l'upstream était une priorité élevée auparavant. Cependant, une fois dans un scénario de cloud croisé, l'upstream peut être un service sur un autre cloud ou même devenir un autre service SaaS. Ainsi, il est nécessaire de supporter le mTLS pour l'upstream afin d'améliorer la sécurité des données.

2. Séparation complète de l'architecture du plan de contrôle et du plan de données

Plusieurs vulnérabilités de sécurité d'APISIX ont été exposées au cours de l'année écoulée, la plupart provenant du déploiement hybride de ses plans de contrôle et de données. En d'autres termes, les plans de contrôle et de données sont dans le même service après le démarrage du service APISIX. Donc, une fois qu'un pirate informatique envahit un plan de données spécifique à travers une faille de sécurité, il peut également accéder au plan de contrôle pour contrôler toutes les données, causant des conséquences désastreuses.

3. Renforcement de la gestion de la sécurité

La passerelle stocke généralement des données sensibles. Par exemple, certains utilisateurs peuvent stocker le certificat SSL ou les informations critiques pour se connecter à etcd sur la passerelle. Dans de telles circonstances, une fois qu'etcd ou le plan de données est compromis, cela peut entraîner une fuite de données grave. Par conséquent, lors du stockage de certaines informations essentielles, il est nécessaire de considérer l'utilisation d'un composant dédié à la conservation des clés comme Vault pour protéger les données sensibles.

4. Intégration de plus de standards cloud

Nous avons l'intention de nous assurer que les utilisateurs peuvent fonctionner de manière fluide sur diverses plateformes cloud sans rien configurer dans des scénarios multi-cloud. Cela ne signifie pas que les utilisateurs doivent configurer des plugins personnalisés, mais cela permet directement à APISIX d'intégrer des standards, des API ou d'autres services de divers clouds. Ce mode peut aider les utilisateurs à s'adapter à l'avance et assurer la commodité et le confort pour une utilisation ultérieure.

Supporters d'Apache APISIX

Tout au long de l'histoire du développement d'APISIX, de nombreuses innovations techniques ont été réalisées. Les contributeurs de la communauté en pleine croissance travaillent main dans la main depuis la phase de construction du code pour faire d'APISIX une passerelle API intégrée. Aujourd'hui, APISIX maintient une itération rapide, grâce aux efforts des supporters.

L'itération et la mise à niveau d'un produit open source doivent être attribuées aux contributeurs et aux utilisateurs.

Lorsqu'APISIX a été donné à la Apache Software Foundation il y a trois ans, c'était un projet immature avec seulement 20 contributeurs. Heureusement, APISIX a attiré plus d'utilisateurs, de contributeurs et d'entreprises dans le monde entier grâce à son développement rapide. Par exemple, nos clients incluent des entreprises telles que Tencent, WPS, Sina Weibo, et iQiyi, gérant des dizaines de milliards d'appels API par jour. De plus, de nombreux utilisateurs internationaux de divers secteurs, tels que la NASA, la European Factory Platform, Swisscom, etc., figurent parmi nos listes de clients.

Prenons WPS comme exemple. C'est une entreprise de logiciels de bureau SaaS en Chine, fournissant des logiciels comme Microsoft Office 365. Que vous travailliez avec plusieurs personnes sur des téléphones mobiles, des navigateurs ou des appareils terminaux, des dizaines ou des centaines d'utilisateurs peuvent éditer le même document et voir les modifications simultanément. Cette fonction est réalisée grâce à divers appels d'API.

La plupart des géants gèrent des dizaines de milliards d'appels API, avec un pic de QPS dépassant un million. Une telle échelle d'utilisation permet également à APISIX d'obtenir des retours d'utilisateurs réels dans des circonstances à grande échelle. Grâce au soutien de ces utilisateurs d'entreprise, APISIX s'est rapidement développé en un projet open source mature.

De plus, de nombreux utilisateurs partagent également leurs expériences ou les itérations de fonctionnalités de code d'utilisation d'APISIX dans la communauté, contribuant à un bénéfice mutuel et à une situation gagnant-gagnant pour les deux parties. Cela démontre que les utilisateurs considèrent APISIX comme un bon produit et plus encore comme un projet open source digne d'intérêt. Ce n'est qu'après avoir gagné la confiance des développeurs que nous avons l'opportunité de devenir un projet open source précieux.

Les contributeurs adaptent l'expérience et les retours pour créer de nombreuses fonctionnalités de produit ; les utilisateurs peuvent utiliser ces fonctionnalités pour apporter de la valeur aux entreprises. Un cercle vertueux se crée, ce qui est l'essence de l'open source. Nous recherchons toujours ce genre de vérité plutôt que de poursuivre aveuglément les bulles de nombreux followers.

Aperçu d'APISIX 3.0

Jusqu'à présent, nous avons beaucoup parlé de ce qu'APISIX a fait dans le passé et maintenant. Le processus de développement d'APISIX peut être divisé en plusieurs étapes.

La version 1.0 d'APISIX visait à construire son cadre, à renforcer l'architecture sous-jacente et à présenter certaines fonctions essentielles de la passerelle API. Nous avons exploré plus profondément dans la version 2.0, rendant la couche inférieure plus flexible et l'architecture plus mature.

Pour un projet open source mature, le signe de sa maturité ne se concentre pas sur sa grande fonctionnalité, mais sur l'apport d'une meilleure expérience pour les utilisateurs et les développeurs.

À l'étape actuelle, APISIX a fait beaucoup d'exploration et d'innovation techniques, mais n'a pas pleinement pris en compte les expériences utilisateur. Le problème se manifeste par une qualité de documentation instable et un manque de vidéos de tutoriels. Par conséquent, de nombreux utilisateurs sont perdus lorsqu'ils entrent en contact avec APISIX pour la première fois. Ils ne savent pas comment l'utiliser ou appliquer certaines fonctions à différents cas d'utilisation, et ils ne sont pas sûrs de la valeur unique qu'APISIX peut apporter aux entreprises.

Par conséquent, dans la prochaine version d'APISIX 3.0, nous essaierons de résoudre des problèmes similaires et de reconstruire de nombreuses lacunes peu conviviales pour l'expérience des développeurs. Par exemple, nous redessinerons l'API pour supprimer la dépendance à des valeurs de retour spécifiques d'etcd et renouvellerons la documentation officielle pour être plus conviviale avec des descriptions simples. Au niveau fonctionnel, le plan de contrôle et le plan de données seront également séparés pour renforcer la sécurité ; il supporte plus de protocoles de couche 4 et de protocoles RPC afin que les utilisateurs puissent rapidement obtenir le trafic de toutes les directions de la passerelle.

Après la mise en œuvre des fonctions ci-dessus, APISIX 3.0 deviendra plus sûr, plus fiable et plus facile à utiliser. Nous accordons toujours une attention particulière aux excellentes opérations et à l'expérience utilisateur. Nous espérons qu'APISIX pourra gérer les requêtes de toutes les API et microservices dans le monde et aider les entreprises à gérer le trafic des API et des microservices plus efficacement.

Il est prévu que APISIX publiera une nouvelle version, 3.0, à la fin de 2022. Nous espérons que vous continuerez à suivre les tendances de la dernière version d'APISIX et à participer activement à la contribution du projet Apache APISIX.

L'avenir d'APISIX

Le développement et le remplacement de la technologie côté serveur sont très rapides, car de nombreuses technologies et cadres populaires il y a cinq ans disparaissent. La raison n'est pas que les ingénieurs préfèrent les nouveautés, mais que ces technologies ne peuvent pas répondre aux besoins réels des ingénieurs et des entreprises. Leur sort est scellé : être écartées. La réalité cruciale nous dit que la technologie doit servir les entreprises et les produits et ne peut pas survivre sans correspondre aux besoins actuels du marché.

"Ne construisez pas un château sur un marécage." Ce dicton rappelle toujours aux développeurs d'Apache APISIX qu'ils doivent s'appuyer sur des besoins et des scénarios réels pour guider son développement et son évolution. Sinon, le produit sera progressivement abandonné par les ingénieurs.

Comment pouvons-nous maintenir la technologie d'Apache APISIX à la pointe de l'industrie ? C'est la question cruciale de savoir si Apache APISIX peut continuer à attirer les développeurs et les utilisateurs d'entreprise à l'avenir. La réponse est simple : rejoindre les entreprises et les ingénieurs en pleine croissance, grandir ensemble et se soutenir mutuellement. Cela permet à Apache APISIX de rester toujours à la pointe de la technologie. Ce n'est qu'en faisant ainsi qu'APISIX aura le potentiel de devenir un projet open source pérenne de classe mondiale.

L'avenir d'APISIX est de mieux supporter les scénarios Serverless, d'améliorer le maillage de services, de construire des plateformes de cycle de vie complet des API et d'améliorer l'expérience utilisateur sur le cloud public. Ces plans ne sont pas élaborés par quelques développeurs internes, mais par des milliers de développeurs dans l'industrie. Alors rejoignez-nous pour expérimenter le charme de l'open source !