Dynamic

Rich Features

Cluster Management

Go for Apache APISIX

Looking for the best API Gateway?

Built on NGINX, with more features than NGINX.

 Many companies have migrated from NGINX to Apache APISIX, immediately achieving fast growth and reducing operational costs.

Apache APISIX vs NGINX:

## Aperçu

En tant que fournisseur d'infrastructure et de solutions de blockchain de consortium de niveau entreprise de premier plan, [Hyperchain Technologies](https://www.hyperchain.cn/en/about/company) s'engage à construire une infrastructure innovante et à favoriser le développement numérique de la société. Au cours de sa croissance rapide, Hyperchain a rencontré de nombreux problèmes lors de la mise en place de sa plateforme blockchain Hyperchain, notamment :

- Absence de gestion standardisée du trafic avec un risque potentiel d'effondrement du système
- Contrôle de sécurité et gestion de l'authentification incomplets
- Contrôle des permissions peu pratique
- Coût élevé des adresses IP publiques
- Instabilité des nœuds blockchain : un seul nœud vulnérable aux attaques
- Manque de gestion unifiée de plusieurs protocoles

Hyperchain a essayé Kong et NGINX, mais malheureusement, ils ne répondaient pas aux scénarios métier d'Hyperchain. **Cependant, après avoir adopté Apache APISIX, tous les problèmes mentionnés ci-dessus ont été résolus, donnant à la plateforme blockchain Hyperchain une vitalité sans fin.**

### À propos de la plateforme blockchain Hyperchain

La plateforme blockchain Hyperchain consiste à intégrer le framework blockchain dans une plateforme de cloud computing, en tirant parti des avantages de déploiement et de gestion de l'infrastructure de services cloud. Il s'agit d'une plateforme blockchain ouverte qui peut fournir aux développeurs un écosystème blockchain pratique et performant ainsi que des services de support associés, tout en soutenant l'expansion et l'exploitation des activités des développeurs dans le web3.

**La plateforme blockchain Hyperchain permet de construire rapidement et de manière flexible un réseau blockchain. Grâce à cette plateforme, les entreprises peuvent gérer leurs activités blockchain de manière unifiée.** Par exemple, via la plateforme, il est possible de signer des contrats dans l'environnement de développement intégré, puis de déployer ces contrats sur le réseau blockchain créé. Le module de service supérieur peut appeler les contrats liés à la blockchain pour poursuivre le processus métier.

Comme il existe de nombreux nœuds dans la chaîne, allant de quelques dizaines à plusieurs milliers, il devient difficile de surveiller et de maintenir le fonctionnement de la chaîne sans le support de la plateforme. **En utilisant la plateforme blockchain Hyperchain, les utilisateurs peuvent non seulement réduire les coûts, mais aussi gérer la blockchain plus facilement et renforcer la sécurité de l'ensemble du système.**

Prenons l'exemple d'Hyperchain pour comprendre comment et pourquoi les entreprises blockchain devraient choisir Apache APISIX parmi les nombreuses passerelles API. Nous analyserons ci-dessous l'application d'APISIX dans la plateforme blockchain Hyperchain et dans les nœuds blockchain.

## Application d'APISIX dans la plateforme blockchain Hyperchain

Voici un diagramme d'interaction d'application d'APISIX dans la plateforme blockchain Hyperchain. Le service backend enregistre les informations de service avec etcd en fonction de ses caractéristiques métier, puis enregistre le service avec APISIX via le module d'enregistrement de route.

APISIX agit comme l'entrée unifiée des microservices internes du système. Les requêtes externes sont d'abord envoyées à APISIX ; elles accèdent ensuite à la couche d'accès via l'API après avoir passé l'authentification, puis accèdent aux services principaux via RPC (appel de procédure à distance).

![Diagramme d'interaction d'application Hyperchain](https://static.api7.ai/2022/11/15/637335a53d73c.png)

### Routage des requêtes

Parfois, il est souhaitable d'exposer les API sous le même nom de domaine. Dans ce cas, nous pouvons ajouter des préfixes au chemin de l'API du même service, tels que `/baas-core` ou `/baas-other`. Lorsque le client demande ces API, la passerelle API doit supprimer ces préfixes ajoutés, puis transférer la requête au service backend. Le plugin [proxy-rewrite](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/) d'APISIX peut nous aider à gérer facilement de tels cas.

Par exemple :
Lors de la visite : http://apisix:8080/baas-{service}/api/v1/…
La requête peut être transférée à http://{service}/api/v1/…
en écrivant une expression régulière : `^/baas-core/(.*)$,/$1`

![Édition du plugin proxy-rewrite](https://static.api7.ai/2022/11/15/637335b538dc0.png)

### Gestion de la limitation du trafic

Les utilisateurs peuvent choisir des blockchains de consortium selon leurs besoins, non seulement celle d'Hyperchain mais aussi IBM Data Fabric, Baidu XuperChain, etc. Par conséquent, Hyperchain doit gérer le cycle de vie de toutes les blockchains de consortium dans le système.

Lors de la création d'une chaîne de consortium, Hyperchain n'a qu'à écrire le code sur la plateforme blockchain et télécharger les composants de pilote enfichables sur la plateforme blockchain pour les appeler afin de créer la chaîne de consortium. Dans certains cas de déploiement privé, les composants de pilote enfichables peuvent être supportés rapidement.

Chaque appel aux composants de pilote est un processus qui doit être limité, surtout lorsque le nombre est élevé. Par conséquent, le plugin [limit-req](https://apisix.apache.org/docs/apisix/plugins/limit-req/) d'APISIX peut être bénéfique pour limiter l'entrée et la sortie du trafic de la plateforme afin de garantir sa stabilité.

Le plugin limit-req permet une configuration personnalisée concernant le taux et le burst.

![Modèle du plugin limit-req](https://static.api7.ai/2022/11/15/637335b790f49.jpeg)

### Contrôle de sécurité et gestion des autorisations

Pour collaborer avec APISIX, Hyperchain a développé un plugin pour les circonstances de déploiement privé. La partie A préfère souvent utiliser ses services d'authentification ou son système de comptes de service. Lorsque le trafic frontal visite le site, il passe d'abord par le plugin Access-auth, et il ne peut accéder au backend BFF (Backend for Frontend) que s'il passe l'authentification.

![Diagramme du processus d'authentification](https://static.api7.ai/2022/11/15/637335b994030.png)

Selon les trois facteurs clés de la spécification standard Restful (les informations d'authentification, le chemin Restful et les verbes HTTP comme GET, POST, PUT, DELETE, PATCH, etc.), une authentification compte-rôle-autorité est effectuée. Si l'authentification est réussie, les informations utilisateur sont renvoyées dans l'en-tête ; sinon, elle renvoie un code 403.

![Chemin d'authentification API](https://static.api7.ai/2022/11/15/637335bd3e080.png)

### Rechargement à chaud

APISIX offre un [rechargement à chaud](https://apisix.apache.org/docs/java-plugin-runner/hot-reloading/) des plugins développés en interne. Cela permet de gagner du temps pendant le développement et permet aux utilisateurs de modifier des parties de leur code sans redémarrer l'ensemble du plugin runner. De cette manière, les développeurs peuvent apporter des ajustements à l'interface dans le backend, qui prennent effet immédiatement, ce qui est pratique et convivial pour la mise en ligne.

### Pourquoi pas Kong ?

Hyperchain avait utilisé Kong auparavant mais l'a finalement remplacé par Apache APISIX principalement parce que :

- **Coût élevé de déploiement et de maintenance**

    Le cluster Kong nécessite une collaboration avec la base de données Postgresql et nécessite un administrateur de base de données spécifique pour une haute disponibilité. Le déploiement en cluster de la base de données Postgresql est relativement difficile à mettre en œuvre et augmente le coût de l'exploitation et de la maintenance ultérieures.

- **Augmentation de la complexité du système et du taux de défaillance**

    La plateforme blockchain Hyperchain utilise la base de données MySQL, ce qui entraîne la présence de deux bases de données relationnelles dans le système si Kong est adopté, ce qui rend le système plus complexe. Cela augmente également le taux de défaillance en améliorant la compatibilité entre les deux ensembles de bases de données.

## Application d'APISIX dans les nœuds blockchain

![Diagramme blockchain Hyperchain](https://static.api7.ai/2022/11/15/637335bfa08dc.png)

### Réduction des coûts sur les adresses IP publiques

L'utilisateur achète des blockchains via la plateforme blockchain Hyperchain. Ensuite, les entreprises de niveau supérieur et les clients développeurs peuvent se connecter aux nœuds. Les services peuvent se connecter à un ou plusieurs nœuds, et les utilisateurs peuvent accéder à un ou plusieurs nœuds, ce qui pose un problème : presque tous les nœuds seront visités, ce qui augmente la pression de visite sur un seul nœud.

Cela est relativement facile à gérer dans certains environnements de déploiement privé. Cependant, trop de nœuds et d'adresses IP publiques sont nécessaires pour les systèmes ciblant les utilisateurs internet. Le prix de chaque adresse IP publique de 4 mégaoctets de trafic peut atteindre près de 200 CNY par mois. Il y a des milliers de nœuds sur la plateforme Hyperchains, ce qui entraîne des coûts élevés en adresses IP publiques.

APISIX gère toutes les demandes de visite et distribue le trafic aux nœuds blockchain correspondants. De cette manière, Hyperchain a réalisé des économies importantes.

![Mode Hyperchain avec APISIX](https://static.api7.ai/2022/11/15/637335c23f4f8.png)

### Contrôle des permissions pratique

Il existe diverses blockchains sur la plateforme blockchain Hyperchain, et chaque chaîne a un contrôle des permissions RBAC complexe. Par conséquent, différents types de certificats doivent être ajoutés côté client, tels que les certificats TLS, ce qui pose également des problèmes aux utilisateurs.

Actuellement, le plugin [key-auth](https://apisix.apache.org/docs/apisix/plugins/key-auth/) d'APISIX peut être utilisé pour résoudre ce problème efficacement. Les utilisateurs autorisés peuvent accéder directement à la blockchain sans se soucier de la configuration des permissions, car APISIX unifie la couche sous-jacente de la chaîne.

### Le clustering améliore la stabilité des nœuds

Comme mentionné précédemment, les nœuds sont fréquemment visités. Une haute concurrence existe chez la plupart des utilisateurs bancaires, car le TPS (Transactions Par Seconde) peut atteindre 40 000 à 50 000 fois.

Il s'avère qu'un seul nœud sur la blockchain est vulnérable car chaque transaction a un impact sur le nœud visité.

Hyperchain a déployé Apache APISIX sur K8s avec le Horizontal Pod Autoscaler. Comme APISIX utilise etcd avec une bonne extensibilité dynamique, il peut résoudre efficacement le problème de l'impact du trafic sur un seul point.

### Support de plusieurs protocoles

Les protocoles des chaînes hétérogènes sur la plateforme blockchain Hyperchain sont divers, tels que le protocole HTTP, le protocole Websocket, le protocole gRPC, le protocole TCP, le protocole UDP, etc.

APISIX supporte plusieurs protocoles, s'adaptant de manière flexible aux couches sous-jacentes des différentes blockchains, réduisant ainsi les coûts de développement.

### Pourquoi pas NGINX ?

Il semble qu'Hyperchain pourrait utiliser NGINX pour résoudre ses problèmes. Cependant, après l'essai, Hyperchain l'a abandonné car :

- **Inadapté à l'expansion dynamique**

    Hyperchain doit ajouter et supprimer fréquemment des nœuds dans la plateforme blockchain, ce qui ne prend effet qu'après un redémarrage, ce qui est peu pratique pour les développeurs. De plus, les développeurs doivent écrire un code de règles complexe pour les plugins dans le fichier conf de NGINX.

- **Difficulté de clustering**

    NGINX ne supporte pas le clustering, ce qui est relativement complexe et peu convivial pour les utilisateurs.

- **Pas de support direct pour TCP et UDP**

    NGINX ne peut proxier que le protocole de couche 7 plutôt que le protocole de couche 4 et ne peut pas directement supporter les protocoles TCP et UDP. De plus, le module n'est pas compilé par défaut, nécessitant un traitement supplémentaire.

- **Pas de tableau de bord**

    Il n'y a pas d'interface visuelle pour NGINX, ce qui rend difficile pour les développeurs et les opérateurs de gérer autant de nœuds.

## Résumé

D'après ce qui précède, nous savons qu'Apache APISIX est une passerelle API dynamique qui peut être appliquée dans le domaine de la blockchain. De plus, Apache APISIX fournit des fonctionnalités riches de gestion du trafic comme l'équilibrage de charge, l'upstream dynamique, la publication canari, la rupture de circuit, l'authentification, l'observabilité, etc.

Nous espérons qu'APISIX pourra soutenir davantage d'entreprises blockchain pour entrer dans une nouvelle phase de développement.
Bienvenue pour en savoir plus sur Apache APISIX.
Vous pouvez nous contacter à https://api7.ai/contact.


Comment la licorne de la blockchain, Hyperchain, utilise APISIX, une passerelle API open-source, pour renforcer la plateforme blockchain Hyperchain afin de gérer le trafic blockchain dans le web3, en mentionnant la comparaison entre APISIX, Kong et NGINX.

API Gateway pour Web3 : Comment APISIX renforce Hyperchain

## Aperçu

Depuis mai 2021, [vivo](https://www.vivo.com/en) a introduit [Apache APISIX](https://apisix.apache.org/) comme passerelle API. Après plus d'un an de pratique chez vivo, APISIX a résolu de nombreux points douloureux techniques et commerciaux et est utilisé à grande échelle.

### Points douloureux avant l'utilisation d'APISIX

- **Gestion complexe des scénarios commerciaux et de la maintenance du système**

    En raison de la croissance rapide des activités, il existe divers scénarios et systèmes qui les servent, et vivo a besoin d'une manière unifiée de les gérer.

- **Interaction entre le plan de données et le plan de contrôle**

    Pour les entreprises de taille moyenne et grande comme vivo, il est inattendu qu'un problème mineur survenant dans le plan de données impacte le plan de contrôle.

- **Aucun support pour les ressources multidimensionnelles**

    Les projets divers conduisent à divers noms de domaine et URL. Le département commercial doit effectuer des recherches selon différentes dimensions de ressources.

- **Impact incontrôlable des problèmes**

    Comme les projets de vivo sont complexes, l'effet des problèmes rencontrés est incontrôlable. L'utilisation de certains plugins complexes intensifie cela.

En remplaçant NGINX par APISIX, vivo a finalement réussi à réaliser une série de réalisations comme indiqué ci-dessous.

### Réalisations après l'utilisation d'APISIX

- **Haute disponibilité**

    Aucune panne majeure ne s'est produite depuis le lancement d'APISIX chez vivo, et la disponibilité du système dépasse **99,99%**.

- **Haute performance**

    Prenant en charge un trafic en ligne important et servant un grand nombre de services, le trafic de transfert en ligne actuel atteint près de **un million de QPS** (requêtes par seconde).

- **Fonctionnalités riches**

    Grâce aux [fonctionnalités riches](https://apisix.apache.org/blog/2022/11/02/apache-apisix-v3-preview/) d'APISIX, APISIX peut couvrir presque tous les scénarios de proxy NGINX courants. Environ 50% des projets de vivo ont été migrés de NGINX vers les clusters APISIX.

- **Soutien à la construction et au développement du cloud natif**

    Le bare metal K8s supportant la conteneurisation a atteint une échelle de **10 000**. Environ 40% des projets ont été migrés du bare metal et des machines virtuelles vers la plateforme de conteneurs K8s, soutenant et promouvant les progrès de la conteneurisation chez vivo.

## Conception du système de vivo basée sur APISIX

Ensuite, examinons la conception du système de vivo après l'adoption d'APISIX.

### Affichage de l'architecture personnalisée sur APISIX

![Architecture de la passerelle API de vivo avec APISIX](https://static.api7.ai/2022/11/23/637dc2f51318e.jpg)

À partir du diagramme ci-dessus, nous pouvons analyser que vivo a :

- Terminé la construction des passerelles de trafic **couche 4** et **couche 7**, supportées par APISIX
- Réalisé l'accès au trafic et le déploiement mixte de bare metal, machines virtuelles et conteneurs
- Mis en œuvre la gestion des clusters APISIX
- Connecté la plateforme DevOps interne et les services de déploiement commerciaux pour accéder rapidement et automatiquement au trafic
- Amélioré la construction de la surveillance

### Améliorations de la gestion de la configuration et du lancement

Afin de mieux répondre aux besoins réels du département commercial, vivo a effectué une série d'adaptations sur APISIX. Voici quelques-unes de ces adaptations, y compris la modification du plan de contrôle, la gestion séparée des clusters et le transfert de données.

#### Modification du plan de contrôle

Le processus global peut être le suivant :

Après la configuration des données dans la plateforme de changements A6, les informations seront transmises via RPC notify à ManagerAPI, qui est construit par vivo basé sur le [APISIX Dashboard](https://github.com/apache/apisix-dashboard) open source.

Ensuite, le trafic sera envoyé à `apisix-agent`. APISIX interroge régulièrement apisix-agent via le processus privilégié pour obtenir des tâches de changement par lots. Ensuite, le processus privilégié notifie le `worker` via des files d'attente partagées pour réaliser le changement en mémoire.

En même temps, APISIX informe `apisix-agent` du résultat des tâches et les transmet à ManagerAPI. De plus, la plateforme de changements A6 peut interroger ManagerAPI pour obtenir les résultats des tâches.

![Mode de gestion et de publication de vivo](https://static.api7.ai/2022/11/25/638036da44e7f.jpeg)

[etcd](https://etcd.io/docs/v3.5/learning/why/#comparison-chart "etcd") est un point fort d'APISIX, permettant l'opération indépendante des plans de contrôle et de données. Compte tenu de l'unicité de son architecture, vivo a abandonné etcd dans le processus ci-dessus. Voici quelques raisons.

En raison de la diversité des projets de vivo, il existe divers noms de domaine et URL. De plus, les départements commerciaux doivent interroger différentes dimensions. Grâce à l'adaptabilité d'APISIX non seulement avec etcd mais aussi avec divers types de bases de données, vivo a pu facilement utiliser des bases de données comme MongoDB, pour travailler avec APISIX.

En outre, vivo a apporté les contributions suivantes pour être compatible avec Apache APISIX.

- **Développement du composant Agent**

    Depuis mai 2021, vivo a introduit Apache APISIX. Compte tenu du contexte technique, vivo n'était pas confiant de pouvoir adopter APISIX car vivo n'a aucune expérience avec OpenResty et Lua. De plus, il y a de nombreuses tâches non liées au transfert, comme la collecte de logs et la gestion de la surveillance, ce qui pourrait augmenter la complexité de gestion du plan de données. Par conséquent, vivo a développé le composant agent pour réduire la complexité du développement.

- **Écriture des données sur le disque**

    Pour rendre le système ajustable et permettre au plan de données de fonctionner indépendamment, réduisant ainsi la dépendance au plan de contrôle, vivo a écrit le fichier de configuration sur le disque. Lorsque APISIX est démarré, il supporte le téléchargement complet depuis le centre de configuration et supporte également l'obtention directe des ressources de configuration à partir du répertoire de fichiers du disque local. Cette méthode améliore considérablement l'indépendance des données et la robustesse du système. De plus, il est très intuitif de comprendre les informations de route et d'upstream configurées sur le disque, ce qui est utile pour le dépannage.

- **Rappel du résultat de la tâche de changement**

    En tant que grande entreprise, vivo doit s'assurer que les changements de ressources telles que les routeurs et les upstreams peuvent être garantis comme étant efficaces et réussis, et que le système peut signaler l'erreur même si ces changements échouent. Une telle logique de ACK (Code d'acquittement) garantit que les workers NGINX sur une machine peuvent rappeler. Lorsque les tâches de rappel sont réussies, tous les workers sur APISIX mettront à jour les changements de ressources dans la mémoire concernée.

#### Gestion séparée des clusters

![Gestion de la séparation des clusters](https://static.api7.ai/2022/11/25/6380381595b00.jpeg)

La version open source d'APISIX fournit [etcd](https://apisix.apache.org/docs/apisix/FAQ/#why-does-apache-apisix-use-etcd-for-the-configuration-center) pour que tout le monde puisse partager. Cependant, les projets de l'entreprise sont complexes, et les problèmes rencontrés sont incontrôlables. De plus, il est inévitable d'utiliser des plugins complexes, affectant les performances du système.

Par conséquent, il est géré par la séparation des clusters pour réaliser l'isolation de la configuration des clusters sur APISIX, ce qui peut :

- Contrôler le domaine de défaillance et soutenir efficacement la complexité des projets sans affecter d'autres projets
- Réduire efficacement la charge causée par la couche non liée au transfert d'APISIX lorsque les nœuds de conteneurs changent fréquemment
- Réduire l'impact de charge causé par le contrôle de santé

#### Augmentation du QPS supporté par HTTPS

Selon les exigences pertinentes du ministère de l'Industrie et des Technologies de l'Information en Chine, le trafic du réseau externe doit passer par le protocole HTTPS. En tant que protocole de chiffrement HTTP basé sur TLS, HTTPS impose une lourde charge sur le CPU dans le processus de chiffrement et de déchiffrement.

Lorsque les configurations de routage et autres sont les mêmes, le trafic que HTTPS peut supporter est environ **1/8 - 1/10** de celui de HTTP.

Après avoir appliqué le patch de la carte accélératrice Intel® QAT (QuickAssist Technology), vivo délègue la gestion du déchiffrement à la carte accélératrice QAT, ce qui libère le CPU, augmentant ainsi le QPS supporté par HTTPS sur une seule machine. Comme on peut le voir sur la figure ci-dessous, **la capacité de charge HTTPS d'une seule machine est environ doublée**.

![Données montrant l'amélioration de vivo sur la capacité de charge du trafic](https://static.api7.ai/2022/11/23/637dc306a5fa1.jpg)

## Comment vivo combine-t-il les activités avec APISIX

### Soutien au développement de la conteneurisation

Pour soutenir le développement de la conteneurisation, vivo a auto-développé un contrôleur d'entrée K8s. Voici quelques-unes de ses fonctions.

1. Adaptation au mécanisme de changement de configuration asynchrone modifié par vivo

2. Gestion des notifications d'événements multi-clusters K8s à APISIX

3. Gestion des scénarios de projets complexes tels que :

- Un serveur avec plusieurs ports

- Lorsque d'autres serveurs de framework RPC, comme Dubbo et gRPC, sont connectés à K8s, un ensemble unifié de logiques de traitement est nécessaire pour notifier APISIX ou d'autres frameworks des informations de port selon les caractéristiques de configuration des projets

4. Adaptation aux besoins particuliers des scénarios d'automatisation internes de l'entreprise, comme DevOps, facilitant le déploiement rapide et permettant le trafic

### Aide à la migration des projets de NGINX vers APISIX

Les projets de vivo sont déployés sur le cluster NGINX existant et fonctionnent de manière stable depuis longtemps. Cependant, cela apporte des charges de travail non liées aux activités et de l'instabilité aux projets. Par conséquent, il est difficile de procéder à la migration. Alors, comment promouvoir la migration des projets vers APISIX ?

- Tout d'abord, trouver un projet d'un département coopératif, bien servir le département commercial pour établir une référence, et fournir des conseils techniques et de la formation

- Construire un système de plan de contrôle facile à utiliser pour faciliter l'accès des activités et la gestion multidimensionnelle des départements commerciaux
  
- Fournir une capacité de conversion automatique et une configuration de base pour convertir la configuration NGINX en configuration APISIX

### Mise à niveau d'APISIX et soutien de sa version open source

Basé sur la version 2.4 d'APISIX, vivo a effectué quelques ajustements et a publié la nouvelle version, qui a été mise à niveau vers une version plus récente au deuxième trimestre de cette année.

D'une part, grâce à l'architecture modulaire d'APISIX, il est relativement facile d'intégrer le code Lua modifié par vivo dans la branche de la version supérieure d'APISIX. D'autre part, vivo continue également de mettre à niveau la section OpenResty, avec environ une version par an. Comme vivo utilise beaucoup de PATCH et certaines fonctions utiles comme QAT, la mise à niveau de ce composant est difficile et laborieuse.

La version gratuite de la communauté NGINX est lente à mettre à jour et est inactive. Vivo envisage de construire conjointement avec APISIX. Pour réduire la main-d'œuvre nécessaire pour effectuer les tests de système connexes, vivo a adopté Robot Framework, un framework générique d'automatisation des tests pour les tests d'intégration système. Ils promeuvent les composants pertinents pour la couverture des tests unitaires et le modèle de développement TDD (Test-driven development).

## Planification future de vivo

L'année prochaine, vivo prévoit d'étendre [APISIX](https://apisix.apache.org/blog/2022/09/13/why-is-apache-apisix-the-best-api-gateway/) en tant que passerelle de trafic vers une passerelle API, en utilisant ses avantages de [limitation de débit](https://apisix.apache.org/docs/apisix/plugins/limit-count/#attributes), [authentification](https://apisix.apache.org/docs/ingress-controller/tutorials/mtls/), coupure de circuit, etc. Envisageant de combiner APISIX avec DPDK-NGINX, vivo formera également du personnel technique et rejoindra l'établissement de la communauté. De plus, elle consolidera les compétences de base pour poser une bonne fondation, construisant la gouvernance du trafic et des services.

Bienvenue pour en savoir plus sur Apache APISIX.

Vous pouvez nous contacter à [https://api7.ai/contact](https://api7.ai/contact).


Comment le célèbre fabricant de mobiles vivo adopte-t-il APISIX comme passerelle API et l'adapte-t-il pour répondre à ses besoins commerciaux ?

Comment vivo s'intègre-t-il avec APISIX

## Contexte

Ces dernières années, de nombreux logiciels de conférence en ligne bien connus ont vu le jour avec le développement des réunions en ligne et du travail à distance. L'un des plus typiques, Zoom, est devenu un outil de réunion populaire pour le bureau à domicile, l'enseignement en ligne et les scénarios sociaux. Il compte 350 millions de participants quotidiens aux réunions et près de 470 000 clients professionnels payants utilisant la plateforme. De plus, des données récentes montrent que le nombre de minutes utilisées pour faciliter les réunions a atteint plus de 3,3 billions par an.

Cependant, comme d'autres entreprises SaaS et internet, Zoom a rencontré des défis techniques alors que son activité se développe rapidement.

- **Un nombre important de microservices** : En raison de la croissance rapide des activités et des équipes de Zoom, plus de 100 services backend doivent être livrés. Cependant, il est difficile de gérer efficacement un grand nombre de microservices.

- **Divers environnements de déploiement** : Les entreprises SaaS rencontrent souvent des scénarios où les clients doivent déployer sur des clouds dédiés, des clouds privés et des multi-clouds. Les services commerciaux de Zoom étant répartis dans le monde entier, il existe des défis techniques liés à un grand nombre d'environnements hybrides.

- **Infrastructure complexe** : Les entreprises internet de taille moyenne et grande ont généralement des équipes d'infrastructure dédiées responsables des passerelles API, des centres de configuration, de la gestion des clés, des journaux, des alertes de surveillance, des bases de données, etc.
Comme les équipes de R&D de Zoom sont réparties dans le monde entier, il est très difficile d'intégrer ces middleware et infrastructures complexes dans le pipeline de livraison continue.

**Les défis ci-dessus ne sont pas une simple relation additive mais une relation multiplicative. En d'autres termes, la situation réelle est bien plus complexe.** Cependant, les outils open-source que Zoom utilisait auparavant ne peuvent plus répondre aux exigences actuelles de Zoom. C'est pourquoi un pipeline de livraison continue fiable est si important.

Voici les raisons détaillées pour lesquelles Zoom n'a pas continué à utiliser ces outils open-source précédents.

| Helm/Kustomize  | Terraform/Pulumi  | KubeVela + Crossplane  |
| ------------ | ------------ | ------------ |
| Impossible de connecter des systèmes autres que Kubernetes  | Difficile d'utiliser Terraform dans les couches Kubernetes et middleware sans développer des Providers supplémentaires  | Technologie trop récente avec des mises à jour rapides, pas assez sûre et stable pour être adoptée en environnement de production  |
| Difficile de contrôler centralement la plateforme en mode sous-répertoire Git  | Augmente le coût d'apprentissage d'un autre langage de gestion de configuration : hcl  | La définition de Trait + Cuelang de Kubevela et ses capacités d'expression de programmation ne suffisent pas à couvrir les diverses plateformes middleware non cloud-native en dehors du système Kubernetes  |
| Difficile à maintenir et à déboguer en raison de la logique complexe des modèles Helm Chart  | Le mode de contrôle centralisé Mono Repo ne convient pas aux équipes volumineuses  | /  |
| Système de paramètres peu puissant pour gérer les paramètres dynamiques dans un grand nombre d'environnements  | /  | /  |

En raison des limitations des outils open-source ci-dessus, Zoom a finalement étudié certaines solutions principales pour construire le pipeline de livraison continue sous-jacent.

Après quelques tours de comparaison et de vérification, Zoom a finalement choisi APISIX Ingress Controller pour soutenir son nouveau pipeline de livraison continue.

## Apache APISIX Ingress Controller

### Qu'est-ce que Apache APISIX Ingress Controller ?

[Apache APISIX Ingress Controller](https://github.com/apache/apisix-ingress-controller) est un contrôleur d'entrée cloud-native qui utilise Apache APISIX comme plan de données pour transporter le trafic et étend les fonctionnalités de Kubernetes en utilisant CRD (CustomResourceDefinition). Il est responsable de l'interaction avec le serveur API Kubernetes, de la demande de contrôle d'accès basé sur les rôles (RBAC), de la surveillance des changements, de la mise en œuvre de la conversion d'objets dans le contrôleur Ingress, de la comparaison des changements, puis de la synchronisation avec Apache APISIX. De plus, il peut prendre en charge des ressources personnalisées, y compris APISIX Route, APISIX Upstream et d'autres entrées natives de Kubernetes, pour contrôler le trafic externe accédant aux services déployés dans Kubernetes.

Voici le [Diagramme de séquence d'APISIX Ingress Controller](https://apisix.apache.org/docs/ingress-controller/design/#timing-diagram).

![Diagramme de séquence d'APISIX Ingress](https://static.api7.ai/2022/10/27/635a5613af56a.jpeg)

## Pourquoi Zoom choisit APISIX Ingress Controller ?

Selon le contexte ci-dessus, la question se pose : quel type de pipeline de livraison continue Zoom souhaite-t-il construire, et comment adopte-t-il APISIX Ingress pour établir son pipeline de livraison continue sous-jacent ?

Zoom utilisait auparavant NGINX comme passerelle API. Cependant, avec le développement rapide des activités et l'augmentation des microservices, les limites de la solution NGINX actuelle deviennent de plus en plus apparentes.

Différentes équipes doivent maintenir NGINX séparément, et des milliers de lignes de fichiers de configuration NGINX rendent la maintenance difficile. De plus, NGINX ne peut pas rapidement s'adapter lors du déploiement de nombreuses lignes sur le serveur cloud. Concernant le mode de rechargement de NGINX, vous pouvez consulter [ce blog](https://api7.ai/blog/how-nginx-reload-work). Les activités de Zoom ont commencé à évoluer vers Ingress Controller.

L'équipe de la passerelle API a recherché certaines solutions open-source. Après une simulation de migration et une analyse de la configuration réelle des activités dans NGINX et un grand nombre de tests de référence de performance et de comparaison de l'écosystème des plugins, Zoom a finalement choisi le projet APISIX Ingress Controller de la Apache Software Foundation, explorant une passerelle Cloud-Native plus avancée.

En tenant compte de ses scénarios commerciaux, Zoom a accordé plus d'importance aux deux parties suivantes, qui peuvent être satisfaites par APISIX Ingress.

- **Sécurité des données** : Zoom prend au sérieux la confidentialité des clients et la sécurité des services ; ainsi, l'authentification et la vérification mTLS sont largement utilisées dans les salles de réunion en ligne et les appels téléphoniques. Néanmoins, de nombreuses passerelles API similaires ne peuvent fournir un tel service que dans leur version entreprise, tandis que APISIX Ingress offre une grande faisabilité et commodité pour atteindre cet objectif.

- **Stabilité du service** : Les services backend de Zoom nécessitent des déploiements Multi-AZ (Multi-Availability Zones) pour une haute disponibilité dans différentes régions. Généralement, il place les activités dans d'autres DC. Si une erreur se produit dans le DC d'origine, le trafic client doit être transféré vers un autre, ce que APISIX Ingress peut réussir à satisfaire.

### Fonctionnalités d'Apache APISIX Ingress Controller

En prenant Apache APISIX comme plan de données pour transporter le trafic commercial, Apache APISIX Ingress Controller hérite des avantages suivants d'Apache APISIX.

- **Haute performance et stabilité** : En tant que passerelle API open-source dynamique à haute performance, Apache APISIX est résilient et stable dans ses performances, étant utilisé dans de nombreux [scénarios de trafic à grande échelle d'entreprises](https://apisix.apache.org/blog/tags/case-studies/).

- **Communauté active** : En tant que projet de passerelle API open-source de premier plan et le plus actif, Apache APISIX possède une communauté active et a maintenu un excellent taux de croissance depuis le premier jour.

- **Écosystème riche** : Apache APISIX prend en charge les protocoles L7, y compris HTTP(S), HTTP2, Dubbo, le protocole IoT MQTT, etc. En outre, APISIX prend en charge les protocoles L4 tels que TCP/UDP. De plus, la prise en charge complète d'ARM64 est prise en charge dans Apache APISIX 3.0.

- **Multiples plugins** : Il y a presque 100 plugins publiés par APISIX officiellement que les utilisateurs peuvent utiliser par simple glisser-déposer. Le rechargement à chaud et l'orchestration dynamique des plugins offrent une grande commodité aux utilisateurs.

En outre, l'APISIX Ingress Controller présente également les avantages uniques suivants :

- **Bonne compatibilité** : APISIX Ingress Controller prend en charge plusieurs versions de ressources ingress et peut être compatible avec différentes versions de Kubernetes.

- **Mise à jour dynamique** : Il n'est pas nécessaire de recharger le service lors de la modification des routes, des certificats et d'autres configurations, assurant le bon fonctionnement des activités.

- **Mise à l'échelle flexible** : Comme l'APISIX Ingress Controller adopte une structure qui sépare le plan de contrôle et le plan de données, le cluster de plan de données d'Apache APISIX peut être étendu indépendamment sans mettre à l'échelle l'APISIX Ingress Controller.

![Architecture d'APISIX Ingress Controller](https://static.api7.ai/2022/10/27/635a56148940c.jpeg)

- **Convivial pour les opérations et la maintenance** : Sous l'architecture actuelle, les utilisateurs peuvent choisir de déployer le cluster de plan de données APISIX dans le cluster Kubernetes ou dans l'environnement de machines physiques bare-metal selon la situation réelle. De plus, en raison de la séparation architecturale de l'ingress APISIX, l'APISIX sur le plan de données transporte le trafic tandis que l'APISIX ingress controller est le composant du plan de contrôle. Par conséquent, la défaillance de l'APISIX Ingress Controller n'aura aucun impact sur le trafic commercial.

Après la sélection de la passerelle, l'équipe de la passerelle API a été confrontée à un nouveau défi : comment migrer la configuration originale de la passerelle API de centaines de services vers APISIX Ingress ? L'équipe d'infrastructure de Zoom développait le pipeline de livraison continue, ce qui peut considérablement réduire le coût de migration de la conversion de nginx.conf et d'autres configurations Ingress vers APISIX Ingress.

## Le processus et les fonctions de construction du pipeline de livraison continue

### Le pipeline de livraison continue de Zoom

Le pipeline de livraison continue est un système de livraison d'applications de bout en bout qui met en œuvre un modèle unique pour déclarer toutes les exigences de livraison d'applications et organiser et exécuter toutes les étapes de livraison continue en une seule ligne.

![Pipeline de livraison continue de Zoom](https://static.api7.ai/2022/10/27/635a56149b270.jpg)

Il y a six parties dans le pipeline de livraison continue :

1. **Préparer** : préparer les ressources prédéfinies, y compris l'infrastructure, les middleware, les ressources de services cloud, etc. ;

2. **Configurer** : préparer les fichiers de configuration et les clés nécessaires à l'application ;

3. **Déployer** : utiliser K8s pour le déploiement dans des scénarios cloud-native (y compris les informations sur les conteneurs, les images de conteneurs, les paramètres, les versions et les instances) ;

4. **Accéder** : créer un service Kubernetes et configurer automatiquement les règles de routage de l'Apache APISIX Ingress si le déploiement nécessite un accès externe ;

5. **Observer** : Effectuer des configurations liées à l'observabilité, telles que la surveillance, l'alerte, la journalisation et l'analyse de traçage ;

6. **Mettre à l'échelle** : Déclarer les règles de mise à l'échelle dynamique de KEDA (Kubernetes Event-driven Autoscaling) via des métriques de surveillance.

### Comment adopter APISIX Ingress dans le pipeline

![Aperçu de l'architecture du pipeline de Zoom](https://static.api7.ai/2022/10/27/635a5616254ed.jpg)

**Gestion de projet**

Les chefs de projet accordent plus d'attention aux itérations de R&D et à la manière de mieux gérer la progression des versions itératives et l'efficacité du personnel sur la chronologie correspondant aux itérations. Zoom utilise un workflow GitOps en interne pour intégrer la configuration de la passerelle API dans le modèle de livraison d'applications. Sous ce modèle, la définition des règles de routage APISIX est intégrée avec "Déployer" et d'autres liens, confiant le contrôle des changements à GitHub. Avec la création et la fusion des branches GitHub, le pipeline réalise une synchronisation des chronologies entre la publication et le retour en arrière des configurations d'application et de passerelle.

```yaml
# Extrait de code du pipeline CD de Zoom dans le référentiel Git
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*
```

De cette manière, la gestion des versions est simplifiée en gestion de workflow dans GitHub et résout le problème du décalage temporel entre les systèmes en amont et en aval correspondant aux changements lorsque plusieurs itérations sont traitées simultanément.

**Développement d'applications**

Les développeurs se concentrent principalement sur les capacités de routage et d'authentification des API, qui sont fortement liées aux services commerciaux et doivent être remplies par les développeurs pour obtenir un effet automatique. De plus, ils se concentrent sur le développement et la mise en œuvre des fonctions commerciales et des activités commerciales de niveau supérieur, espérant construire une infrastructure prête à l'emploi.

À partir des codes mentionnés ci-dessus, nous pouvons voir que les développeurs n'ont qu'à définir `Authentication` et `Match` dans ce pipeline de livraison continue. Ils n'ont pas besoin de connaître la logique sous-jacente :

- D'abord, traduire cela en Kubernetes Deployment et Service.
- Ensuite, appeler l'API de la plateforme pour vérifier la justesse du chemin.
- Enfin, traduire cela en objets ApisixRoute.

L'intégration de la configuration d'APISIX et du workflow du pipeline de livraison continue offre aux développeurs une manière plus efficace.

**Gestion de l'environnement**

Des exigences complexes de gestion et de contrôle de l'environnement se produisent souvent dans les scénarios toB, et les problèmes de livraison dans certains scénarios de cloud privé, cloud dédié et cloud hybride doivent être pris en compte.

Certaines configurations d'APISIX ingress ont été mises en œuvre pour répondre à l'exigence de masquer les différences environnementales. De cette manière, les gestionnaires de système peuvent contrôler de manière exhaustive les différences dans certains environnements hétérogènes. Tous les services déployés dans l'environnement sont efficaces, évitant la charge cognitive et les opérations de déploiement spéciales causées par les différences environnementales aux développeurs d'applications et d'opérations. Par exemple, Zoom peut utiliser une configuration personnalisée pour désactiver le traçage pour certains environnements, convertir les objets ApisixRoute en objets Ingress natifs et en annotation NGINX Ingress, et utiliser différentes images pour extraire les secrets.

De plus, l'isolation multi-locataire est nécessaire lorsque plusieurs lignes d'activité utilisent l'environnement APISIX. **APISIX Ingress fournit un sélecteur d'annotation** qui permet à différents objets ApisixRoute d'être récupérés par différentes instances de l'APISIX Ingress Controller.

**Gestion de l'infrastructure**

L'équipe de la passerelle API doit contrôler toutes les instances APISIX, configurer les politiques de sécurité de manière exhaustive, mettre en œuvre des zones de disponibilité multiples, etc.

Chaque plugin du pipeline fournit des éléments de configuration pour les ingénieurs d'infrastructure. Dans le plugin `ingress-apisix`, il y a une propriété `defaultPlugins`.

Après que l'équipe de la passerelle API configure cette propriété, le paramètre prendra effet pour tous les services, ce qui convient à une stratégie unifiée de sécurité et de contrôle des risques.

## Conclusion

APISIX Ingress Controller joue un rôle important dans le pipeline de livraison continue de Zoom, libérant la pression sur la gestion de projet, le développement d'applications, la gestion de l'environnement et la gestion des middleware et de l'infrastructure. Le cas de Zoom mérite d'être étudié par d'autres entreprises, et nous espérons qu'APISIX Ingress Controller contribuera à l'innovation de plus d'entreprises.

De plus, Apache APISIX Ingress a officiellement publié V1.5 en août 2022, qui unifie la proposition de toutes les ressources API Versions et met à niveau toutes les versions d'API CRD à V2. En même temps, il prend en charge la plupart des ressources de l'API Gateway. Apache APISIX Ingress a permis aux ressources Ingress d'utiliser des plugins APISIX arbitraires en ajoutant une nouvelle annotation "k8s.apisix.apache.org/plugin-config-name" aux ressources Ingress. De cette manière, cela augmentera considérablement la facilité d'utilisation de l'APISIX Ingress Controller et réduira le coût pour les utilisateurs de migrer d'autres contrôleurs Ingress vers APISIX Ingress Controller.

Pour plus d'informations, veuillez consulter [Apache APISIX Ingress V1.5](https://apisix.apache.org/blog/2022/08/05/apisix-ingress-1.5rc1-release/).


Zoom intègre APISIX Ingress Controller dans son pipeline de livraison continue pour réaliser la gestion globale des projets, des applications, des environnements et de l'infrastructure.

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway pour Web3 : Comment APISIX renforce Hyperchain

Comment vivo s'intègre-t-il avec APISIX

Comment Zoom utilise-t-il APISIX Ingress dans son pipeline de livraison continue ?

Prêt à gérer vos API ?

Apache APISIX vs NGINX:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}Dynamic Configuration,Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway pour Web3 : Comment APISIX renforce Hyperchain

Comment vivo s'intègre-t-il avec APISIX

Comment Zoom utilise-t-il APISIX Ingress dans son pipeline de livraison continue ?

Prêt à gérer vos API ?

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management