Comment mettre en œuvre l'orchestration de plugins dans une API Gateway

Regarder la vidéo

Permettez-moi tout d'abord de me présenter. Je suis Ming Wen, co-fondateur de API7.ai. Je suis vice-président et membre du PMC du projet open source Apache APISIX. Je suis également contributeur d'Apache SkyWalking. En outre, je suis le fondateur du comité open source de Qihoo 360, TVP de Tencent Cloud, et membre du TOC de la TARS Foundation. Je possède plus de 40 brevets en sécurité.

Dans le sujet d'aujourd'hui, je vais aborder 4 parties. Tout d'abord, une brève introduction à Apache APISIX. Qu'est-ce qu'Apache APISIX et en quoi peut-il nous aider ? La deuxième partie concerne le développement personnalisé dans la passerelle API, et la troisième partie est consacrée aux plugins dans Apache APISIX. Comment pouvons-nous les générer automatiquement ? La dernière partie porte sur quelques réflexions concernant l'avenir des passerelles API.

Tout d'abord, permettez-moi de présenter brièvement Apache APISIX. En une phrase, il s'agit d'une passerelle API cloud-native. Voici l'adresse du dépôt d'Apache APISIX sur GitHub.

Apache APISIX est un projet très jeune. Il a été open-sourcé en juin dernier et a été donné à l'incubateur Apache en octobre. En juillet de cette année, il a obtenu son diplôme de l'incubateur Apache et est devenu un projet de premier plan. C'est une communauté en pleine croissance, cela n'a pris que neuf mois.

Pour les développeurs qui ne connaissent pas Apache APISIX, vous pouvez simplement le considérer comme une version améliorée de NGINX, qui couvre toutes les fonctionnalités de NGINX tout en utilisant Lua. Il apporte des fonctionnalités plus dynamiques à NGINX, transformant NGINX en une passerelle API très puissante. La plus grande caractéristique d'Apache APISIX est qu'il est entièrement dynamique, y compris le routage, les certificats SSL, les plugins, etc. Dans Apache APISIX, toutes les fonctionnalités sont configurées dynamiquement via l'API admin, sans avoir à redémarrer le service. Dans Apache APISIX, les besoins métier des utilisateurs sont tous réalisés en utilisant Lua pour développer des plugins. APISIX dispose de plus de 40 plugins intégrés, y compris l'authentification, la limitation de débit, la limitation de requêtes, la sécurité, les logs, l'observabilité, etc., ce qui couvre essentiellement toutes les fonctionnalités que les utilisateurs peuvent rencontrer en entreprise.

Alors, voyons ce qu'Apache APISIX peut faire pour vous ? Il peut gérer le trafic de couche 4 et de couche 7, y compris HTTP, HTTPS, TCP, UDP, MQTT, etc.

Parce qu'Apache APISIX est basé sur NGINX, vous pouvez naturellement utiliser Apache APISIX à la place de NGINX pour gérer le trafic nord-sud. En même temps, Apache APISIX peut également bien gérer le trafic entre les microservices, vous pouvez donc l'utiliser pour remplacer Envoy. Nous avons également des utilisateurs qui utilisent Apache APISIX comme contrôleur d'entrée de Kubernetes. En même temps, avec l'aide du plugin MQTT d'Apache APISIX, nous pouvons utiliser Apache APISIX comme une passerelle IoT, ou utiliser le plugin IDP pour transformer APISIX en une passerelle zero-trust. Donc APISIX se concentre davantage sur la puissance de la passerelle elle-même. Grâce aux plugins, les utilisateurs peuvent transformer APISIX en diverses passerelles nécessaires à leur activité.

Voici l'architecture technique d'Apache APISIX. Nous pouvons voir qu'APISIX a deux parties, celle de gauche est le plan de données, et celle de droite est le plan de contrôle.

Regardons d'abord le plan de données. Après que la requête de l'utilisateur est traitée par Apache APISIX, elle peut être transmise à une API privée, publique ou partenaire. À l'intérieur d'Apache APISIX, les plugins sont construits de manière similaire à des briques Lego. Vous pouvez facilement retirer ou ajouter un plugin sans redémarrer le service.

Ensuite, regardons le plan de contrôle. Dans le plan de contrôle, l'administrateur écrit les configurations dans le cluster etcd via l'API admin, et le plan de données d'APISIX surveillera etcd, de sorte que les configurations atteignent tous les plans de données en quelques millisecondes. Après que les nœuds du plan de données ont traité les données, ils rapportent ensuite certaines métriques et données de log à des composants tels que SkyWalking, Prometheus, etc.

À partir de ce diagramme d'architecture, nous pouvons voir qu'APISIX ne dépend que d'etcd, et n'a pas de RDS comme MySQL et PostgreSQL. Par conséquent, APISIX est mieux conçu pour la haute disponibilité. En même temps, son architecture sera plus simple, pratique pour le déploiement et les opérations.

Cette image est le paysage d'Apache APISIX. En la regardant de gauche à droite, APISIX prend en charge de nombreux protocoles de couche 4 et couche 7. Il prend non seulement en charge le trafic des navigateurs et des applications mobiles, mais aussi divers appareils IoT pour rapporter le trafic à APISIX.

Apache APISIX prend également en charge de nombreux centres de découverte de services externes, y compris etcd consoul.

En tant que logiciel d'infrastructure très important, la passerelle API est généralement placée à l'entrée du trafic. Par conséquent, elle doit non seulement traiter toutes les requêtes des clients, mais aussi se connecter à certains services backend, tels que SkyWalking, Datadog, Kafka, etc.

Au bas de cette image, APISIX prend non seulement en charge l'exécution sur du matériel nu, mais aussi sur des serveurs dans divers clouds publics. Nous prenons également en charge l'exécution sur la plateforme ARM.

OK, la première partie est une brève introduction à APISIX, puis dans la deuxième partie, je vais présenter le développement de plugins personnalisés dans la passerelle API.

Le développement personnalisé est un point très important lorsque nous utilisons des passerelles open source, et il a une barre élevée. La passerelle n'est pas un logiciel qui peut être utilisé directement. Cela diffère des bases de données et des files d'attente de messages. MQ et les bases de données peuvent être utilisées directement après leur installation, mais la passerelle ne le peut pas. Cela est dû au fait que la passerelle nécessite plus ou moins de développement personnalisé.

Par exemple, si votre entreprise dispose de certains systèmes anciens, ou de certains protocoles spéciaux, comme certains protocoles dans l'industrie financière et de sécurité, vous devez effectuer une certaine transcodification au niveau de la passerelle.

D'autre part, bien qu'APISIX fournisse plus de 40 plugins, il est certainement incapable de répondre à tous les besoins de l'entreprise, car chaque entreprise a des besoins uniques. Donc, nous devons souvent faire un certain développement personnalisé des plugins existants pour répondre à nos besoins. C'est en fait un gros problème, car le développement de plugins nécessite encore plus de compétences. Pour le développement de plugins, différents projets open source ont des solutions différentes.

Regardons d'abord Kong. C'est un projet de passerelle API bien connu. Il a 5 ans. La pile technologique de Kong est fondamentalement la même que celle d'APISIX, et les deux sont implémentées sur NGINX et Lua. Mais l'architecture technique de Kong n'est pas la même que celle d'APISIX. Kong est basé sur des RDS comme PostgreSQL et Cassandra. APISIX utilise etcd, et la solution d'APISIX est plus proche de Kubernetes et du cloud natif.

Le point commun entre Kong et APISIX est que les développeurs doivent utiliser Lua pour développer des plugins. Lua n'est pas un langage de programmation populaire, et de nombreux développeurs ne le connaissent pas, bien que Lua lui-même soit simple. Donc, en plus de rendre le plugin plus simple, quelle meilleure solution existe-t-il ?

La solution de Kong est de prendre en charge Go pour écrire des plugins. Cette approche attirera plus de développeurs Go pour écrire des plugins afin de répondre aux besoins personnalisés de leur propre entreprise. C'est une bonne idée, mais d'un autre côté, Kong est nativement implémenté sur Nginx et Lua, et les plugins écrits en Go doivent en fait appeler un autre processus, ce qui entraîne une communication inter-processus, ce qui pose des problèmes de performance.

Regardons le deuxième, qui est également un projet de plan de données open source très connu pour traiter le trafic est-ouest, Envoy, qui est écrit en C++. Donc, le plugin d'Envoy est naturellement implémenté en C++ aussi. Donc, ce n'est pas facile à prendre en main.

Envoy prend également en charge d'autres langages pour le développement. Par exemple, Envoy prend en charge le filtre Lua, et le filtre Lua a le même problème que Kong, c'est-à-dire qu'il y a peu de développeurs familiers avec Lua. Donc Envoy prend également en charge WASM, ce qui peut attirer plus de développeurs d'autres langages pour écrire des plugins. Cette solution n'est pas parfaite, et la stabilité et les performances de WASM ont encore besoin de temps pour s'améliorer.

Les solutions de Kong et Envoy sont les mêmes : elles espèrent que plus de développeurs auront la capacité de développer des plugins, qu'ils utilisent Go, Lua ou WASM. Donc, revenons à APISIX, nous espérons trouver une solution miracle.

Alors, à quoi ressemble cette solution miracle ? Nous pensons qu'au niveau de la passerelle, les deux problèmes suivants doivent d'abord être résolus pour résoudre le problème du développement personnalisé.

Le premier est que de nombreux plugins qui doivent être développés sont en fait simples. Comment réutiliser les plus de 40 plugins open source qui existent déjà ?

Le second est de permettre aux demandeurs de la passerelle dans l'entreprise, tels que les chefs de produit, les opérations et l'équipe de sécurité, de mettre en œuvre leurs propres besoins sur la passerelle avec le moins de coût possible, il serait préférable de ne pas avoir à écrire de code.

Si nous pouvons résoudre ces deux problèmes, alors nous avons l'opportunité de permettre à plus de personnes, pas seulement les développeurs, de développer la passerelle API.

Tout d'abord, regardons comment résoudre le premier problème, qui est la réutilisation des plugins existants. Les microservices sont déjà une technologie très populaire, alors pouvons-nous introduire ce concept dans les plugins de passerelle API ?

Nous pouvons faire en sorte que chaque plugin ne fasse qu'une seule fonctionnalité, tout comme un microservice, ce qui est également la même chose que la conception des processus dans Linux. Par conséquent, nous avons proposé un concept appelé micro-plugin.

Chacun de nos plugins ne fait qu'une fonctionnalité indépendante. Ensuite, nous avons besoin d'une conception similaire au pipe de Linux pour connecter ces micro-plugins.

Par exemple, j'appelle d'abord un plugin de blocage d'URI. Après l'appel, je vais juger si l'URI est vraiment bloqué. S'il est bloqué, alors je continue à appeler le plugin Kafka.

En utilisant cette méthode de pipe, ces plugins peuvent être connectés. Apache APISIX dispose maintenant de plus de 40 plugins. La permutation de plus de 40 plugins a des possibilités illimitées, suffisantes pour répondre aux besoins des utilisateurs.

Mais le problème maintenant est que dans toutes les passerelles API qui ont été open-sourcées, les plugins ne partagent pas de contexte et ne peuvent pas coopérer entre eux. Donc, nous devons connecter ces plugins ensemble. Ce n'est qu'en faisant cela que nous pouvons résoudre le problème de la réutilisation des plugins avec les micro-plugins.

Le deuxième problème est, après avoir les micro-plugins, comment pouvons-nous réduire le coût de développement du nouveau plugin de la passerelle API à zéro autant que possible pour répondre aux besoins des utilisateurs. Nous espérons que pour les non-développeurs, c'est-à-dire ceux qui sont chefs de produit et de sécurité qui n'ont pas de formation technique et ne savent pas programmer, ils peuvent réaliser leurs besoins sans développement, car ils comprennent le mieux nos besoins.

En même temps, cela abaissera la barrière pour le développement de la passerelle API, permettant à de plus en plus de personnes de contribuer à la passerelle API. Si nous utilisons un slogan, c'est "de la créativité à la création", nous pouvons non seulement écrire nos propres idées dans un document pour les développeurs, mais aussi directement créer un nouveau plugin.

Cela semble être une bonne idée, alors peut-elle être réalisée ? En fait, nous pouvons sortir de la pensée technique pour voir comment d'autres industries résolvent ce problème.

Par exemple, dans le moteur de processus de l'industrie médicale, ils sont construits de manière GUI, car leurs utilisateurs sont des médecins. Ensuite, Lego pour les enfants est le même. Vous pouvez utiliser un nombre limité de blocs pour construire un nombre infini de formes possibles.

Mettez ensemble les idées de GUI et de Lego, alors nous pouvons voir que c'est en fait Scratch, qui est la façon dont les enfants apprennent à programmer, donc la barrière sera très basse.

Sur la base des deux problèmes précédents que nous avons résolus, APISIX a proposé de manière unique un nouveau concept : l'orchestration de plugins. Voici une démo de l'orchestration de plugins, nous pouvons d'abord regarder cette courte vidéo.

Dans cette vidéo, nous créons d'abord un plugin de blocage d'URI, puis nous créons un jugement conditionnel. Si le blocage d'URI est vrai, alors nous l'ajouterons au plugin d'injection de faute ; si le résultat du blocage d'URI est faux, nous le transmettrons au plugin Kafka pour enregistrer les logs.

Ensuite, nous configurons chaque plugin et la condition de jugement. Enfin, vérifions avec curl si ce nouveau plugin fonctionne vraiment sur le nœud de la passerelle. Oui, cela fonctionne.

Ensuite, je vais vous expliquer comment cette orchestration de plugins est implémentée. Cela peut également être une question technique qui préoccupe tout le monde.

Pour implémenter l'orchestration de plugins, nous devons suivre trois étapes.

Dans l'étape 1, nous devons utiliser DAG pour décrire ce nouveau plugin. Nous pouvons voir que le graphique avec la flèche à gauche est en fait un DAG (graphe acyclique dirigé), qui est le même que le code décrit dans la vidéo précédente. Ensuite, c'est une méthode de description qui est conviviale pour les humains. Pour l'ordinateur, nous devons le transformer en une description de langage de structure de données à droite. Par exemple, le nœud numéro 1 suivi de 2 4 6 signifie le nœud 1, qui pointe vers le deuxième, le quatrième et le sixième nœuds ; la valeur du numéro 3 est nil, ce qui signifie qu'il n'y a pas d'autres nœuds derrière le nœud numéro 3, et les autres sont similaires. De cette façon, nous convertissons un DAG en une description de structure de données.

Après avoir cette structure de données, nous convertissons ensuite cette structure de données en une chaîne JSON, puis nous passons cette chaîne JSON au serveur. La chaîne JOSN à droite est convertie à partir du plugin que nous avons vu dans la démo.

Après l'étape 1, nous avons déjà une chaîne décrite par JSON, mais comment convertissons-nous cette chaîne en code pouvant être exécuté par APISIX ?

Nous savons que dans APISIX, nous exécutons du code Lua, donc nous avons besoin d'un compilateur, pour analyser JSON en un AST (arbre de syntaxe abstraite), et enfin générer du code Lua. À ce stade, nous avons utilisé jsonschema pour faire cette étape. Voici le dépôt open source.

Après avoir généré le code Lua, nous utilisons le plan de contrôle d'APISIX pour écrire le code Lua dans etcd via l'API admin, puis le nœud du plan de données d'APISIX obtient le code Lua via la surveillance d'etcd. APISIX a la capacité d'exécuter dynamiquement le code Lua, tout comme le plugin serverless d'APISIX.

Par conséquent, le nouveau plugin généré par l'orchestration de plugins, de DAG à l'exécution réelle du nœud de données, l'ensemble du processus est entièrement dynamique, ce qui est une caractéristique très importante d'APISIX.

Si vous voyez cela, avez-vous une question, où puis-je l'essayer ? Ne vous inquiétez pas, il y a un projet open source ici, et nous avons également une démo en ligne.

Dans la dernière partie, je veux parler de nos réflexions sur l'avenir de la passerelle API. La passerelle API existe depuis longtemps. Il y a eu de nombreuses entreprises et projets open source faisant des passerelles API il y a plus de dix ans. Ensuite, à l'ère du cloud natif, la passerelle API est confrontée à des changements dans les besoins des utilisateurs, et des exigences plus élevées sont posées pour les passerelles API.

Une tendance est que les passerelles API traditionnelles nord-sud commencent à traiter le trafic est-ouest des microservices. Par exemple, NGINX a lancé NGINX Control et NGINX Unit. Kong et APISIX agissent également comme des passerelles API de microservices.

En même temps, le projet de service mash est-ouest essaie également d'agir comme une passerelle d'accès nord-sud. Donc, pour les projets open source, tous veulent traiter tout le trafic.

Les projets open source sur le traitement du trafic fleurissent, nous pouvons voir BFE de Baidu et MOSN d'Alibaba. Ils se concentrent tous sur le trafic.

Le deuxième est le low code. La meilleure solution est que le chef de produit puisse directement implémenter des fonctionnalités par orchestration de plugins, afin que les développeurs se concentrent davantage sur la passerelle elle-même.

De cette façon, le métier et le cœur de la passerelle API sont découplés. Vous pouvez laisser des personnes qui ne comprennent pas la technologie et le développement de plugins contribuer des plugins au projet open source. C'est très important.

Le troisième point est le temps réel. Avec la popularisation de la 5G et de l'IoT, et l'adoption de Kubernetes dans l'entreprise, cela a posé des exigences très élevées pour l'effet en temps réel de la configuration, le traitement des requêtes et l'analyse des données en temps réel. Pour la passerelle, si vous ne pouvez pas être en temps réel, très performant et avec une très faible latence, alors elle ne pourra pas survivre dans les trois à cinq prochaines années.

Enfin et surtout, c'est l'open source. Nous pouvons voir que le logiciel mange le matériel, et que le logiciel open source mange le logiciel. À la fin, tous les logiciels d'infrastructure sont open source.

Il en va de même pour la passerelle API. L'open source permet aux entreprises de l'utiliser à moindre coût sans craindre le verrouillage fournisseur. De plus, l'opportunité commerciale de l'open source apportera également plus aux développeurs open source. C'est un bon modèle pour une situation gagnant-gagnant.