Open-Source Project

Community-Driven

High Availability, Stability

Ultimate Performance,

Developer Friendly

Go for Apache APISIX

Looking for the best API Gateway?

Companies choose Apache APISIX as their API gateway after comparing it with Kong. Not only is Apache APISIX is faster, but the experience is also excellent.

Apache APISIX vs Kong:

## 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.

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

## Aperçu

### Défis

1. Un trafic important entraîne des tonnes d'alertes quotidiennes de CPU IDLE trop faible.
2. Trop de composants dépendent de l'architecture du système.
3. Coût élevé d'exploitation et de maintenance (O&M).

### Objectifs

1. Choisir une passerelle API performante pour répondre aux exigences d'iQIYI.
2. Minimiser les coûts de migration.
3. Trouver une passerelle API avec une communauté active et un écosystème sain.
4. Construire une nouvelle passerelle API pour s'adapter à la tendance cloud-native.

### Résultats

1. Les performances se sont améliorées **10 fois** par rapport à avant, supportant **des millions de QPS quotidiennement**.
2. Support facile de **plus de 9 000 projets commerciaux en ligne d'API**.
3. Réalisation réussie de la reprise après sinistre des données pour **plusieurs sites et niveaux à travers la Chine**.

## Ce qui s'est passé derrière iQIYI ?

Cong He, ingénieur R&D senior chez [iQIYI](https://en.wikipedia.org/wiki/IQIYI), a partagé un discours lors de l'Apache APISIX Meetup à Shanghai récemment. Il travaille dans l'équipe cloud computing du département infrastructure IIG et est responsable du développement de la passerelle et des travaux d'exploitation chez iQIYI. Plongeons dans son discours et l'histoire de la passerelle API d'iQIYI pour mieux comprendre Apache APISIX.

Fondée le 22 avril 2010 par Baidu, la société derrière le plus grand moteur de recherche en ligne de Chine, [**iQIYI**](https://www.iq.com/?lang=en_us) est actuellement l'un des plus grands sites de vidéo en ligne au monde, avec près de 6 milliards d'heures passées sur son service chaque mois et plus de 500 millions d'utilisateurs actifs mensuels.

iQIYI avait développé sa propre passerelle API appelée Skywalker, un développement personnalisé basé sur Kong. Skywalker doit aujourd'hui gérer un trafic massif, et **son pic quotidien de service de passerelle peut atteindre un million de QPS et des milliers de routes d'API**. Cependant, les lacunes de ce produit ont commencé à apparaître progressivement.

1. Les performances de la passerelle ne satisfont plus les exigences d'iQIYI, et elle reçoit des tonnes d'alertes de CPU IDLE trop faible quotidiennement en raison du trafic massif.
2. Il y a trop de dépendances de composants sur l'architecture du système.
3. Le coût d'exploitation et de maintenance (O&M) est trop élevé.

Après avoir repris ce projet cette année, Cong a commencé à enquêter sur des produits de passerelle similaires pour résoudre les problèmes et difficultés mentionnés ci-dessus et a finalement trouvé Apache APISIX.

## Comment Apache APISIX surpasse Kong

Avant de choisir Apache APISIX, iQIYI avait déjà commencé à utiliser Kong, mais ils l'ont abandonné par la suite.

### Pourquoi abandonner Kong ?

Après une pratique réelle avec Kong, Cong explique pourquoi son équipe a abandonné Kong. Voici plusieurs des inconvénients majeurs de Kong.

1. Les routes de Kong utilisent des requêtes de parcours, qui ne sont pas rapides.
2. La base de données Postgres de Kong entraîne un déploiement encombrant, une synchronisation peu efficace et une faible disponibilité.
3. Le code est fortement couplé.

### Pourquoi choisir APISIX ?

> "Nous avons comparé les performances entre Apache APISIX et Kong lors de l'enquête, et avons été surpris de constater que **Apache APISIX était 10 fois meilleur que Kong en termes d'optimisation des performances**. Nous avons également comparé Apache APISIX à d'autres produits de passerelle majeurs, et **la latence de réponse d'Apache APISIX est toujours plus de 50 % inférieure à celle des autres produits**. De plus, Apache APISIX peut toujours fonctionner de manière stable même si l'utilisation du CPU atteint plus de 70 %. APISIX est vraiment impressionnant !" a déclaré Cong.

Apache APISIX et Kong ont tous deux été développés techniquement sur OpenRestry, ce qui entraîne un coût de migration relativement faible. En outre, Apache APISIX a une excellente adaptabilité et peut être facilement déployé sur de nombreux environnements différents, y compris les plateformes de cloud computing.

> "Parallèlement, nous avons également constaté qu'Apache APISIX est un projet open-source très actif qui résout les problèmes très rapidement. Son cadre cloud-native correspond également aux plans de suivi de notre entreprise. Ainsi, nous avons choisi Apache APISIX comme notre passerelle API."

## Innovation de l'architecture de la passerelle API d'iQIYI après l'utilisation d'APISIX

Après avoir choisi la grande passerelle API, iQIYI a commencé à établir sa nouvelle architecture de passerelle API, qui est présentée ci-dessous, incluant le domaine, la passerelle, les instances de service et la surveillance des alarmes.

![Diagramme de l'architecture de la passerelle API d'iQIYI](https://static.api7.ai/2022/12/02/6389647220deb.jpeg)

DPVS est un projet open-source développé par iQIYI basé sur LVS. La surveillance des alarmes Hubble est également un développement personnalisé basé sur un projet open-source, et des optimisations ont été apportées aux performances et à la haute disponibilité de Consul.

### Réalisation 1 : Amélioration des plans de données et de contrôle pour la gestion des clusters et des services

Le plan de données est principalement orienté vers les utilisateurs frontaux, et toute l'architecture du LB à la passerelle a des déploiements multi-sites et multi-liens pour la reprise après sinistre, permettant ainsi aux **utilisateurs d'accéder à leur centre de données le plus proche**.

Pour le plan de contrôle, il existe une plateforme de microservices pour **gérer plusieurs clusters et services**. La plateforme de microservices permet aux utilisateurs de bénéficier d'un service unique sans soumettre de tickets, **économisant ainsi un temps considérable**. À l'arrière-plan, le contrôleur de passerelle contrôle principalement la configuration de toutes les API, comme la création d'API et les plugins, tandis que le contrôleur de service **gère l'enregistrement, la suppression et la vérification de l'état de santé**.

![microservice-gateway.webp](https://static.api7.ai/2022/11/21/637b4c61c02c0.webp)

### Réalisation 2 : Ajout de fonctionnalités supplémentaires : contrôle de sécurité, limitation de débit et surveillance

iQIYI a mis en œuvre certaines fonctionnalités de base dans l'architecture API comme la limitation de débit, l'authentification, l'alarme, la surveillance, etc., après s'être adapté à [Apache APISIX](https://github.com/apache/apisix).

La première partie concerne HTTPS. Pour le contrôle de sécurité, iQIYI ne stocke aucun certificat ou clé sur les serveurs de passerelle, mais sur un serveur distant dédié. Cependant, cela était difficile à réaliser avec Kong ; à la place, iQIYI utilisait le préfixe NGINX pour décharger HTTPS. Après la migration vers Apache APISIX, iQIYI a réussi à implémenter cette fonctionnalité sur Apache APISIX, ce qui **économise un niveau de transfert supplémentaire sur le lien**.

En termes de [limitation de débit](https://apisix.apache.org/docs/apisix/plugins/limit-count/), en plus des fonctionnalités de base de limitation de débit, **une limitation de débit précise et une limitation de débit par granularité utilisateur ont également été mises en œuvre**. Pour l'authentification, **des services spécialisés pour l'authentification du passeport** ont été fournis. De plus, iQIYI peut accéder au cloud de sécurité WAF de l'entreprise pour filtrer l'industrie souterraine.

**La fonctionnalité de surveillance des alarmes est réalisée en utilisant le plugin intégré d'Apache APISIX - [Prometheus](https://apisix.apache.org/docs/apisix/next/plugins/prometheus/)**, et les données d'indicateurs seront directement envoyées au système de surveillance de l'entreprise. Apache APISIX fournit également à iQIYI des **services de journalisation et d'analyse de traces**.

### Réalisation 3 : Établissement d'un processus de mise à jour dynamique de la découverte de services

Concernant la découverte de services mentionnée ci-dessus, elle enregistre principalement les services dans les clusters Consul via le centre de services, puis utilise la découverte de services DNS pour les mettre à jour dynamiquement. QAE dans le graphique est une plateforme de microservices utilisée en interne dans notre entreprise. **Utilisons un exemple pour démontrer brièvement le processus de mise à jour des instances.**

Lors de la mise à jour des instances, nous déconnecterons d'abord les nœuds correspondants de Consul et enverrons des demandes de mise à jour du cache DNS à la passerelle via le contrôleur de la passerelle API. Une fois le cache mis à jour avec succès, le contrôleur renverra des demandes à la plateforme QAE pour arrêter tous les nœuds d'application backend associés afin d'éviter de rediriger le trafic vers des nœuds hors ligne.

![Processus de mise à jour dynamique de la découverte de services d'iQIYI](https://static.api7.ai/2022/12/02/63897fa31ff83.jpeg)

### Réalisation 4 : Amélioration de la capacité de routage directionnel

La passerelle a des déploiements multi-sites, et un ensemble complet de liens de sauvegarde multi-sites a été construit à l'avance. En plus de cela, Cong suggère également aux utilisateurs d'avoir des déploiements d'accès le plus proche multi-sites pour leur service backend. Ainsi, les utilisateurs pourraient créer un service API dans la plateforme de passerelle Skywalker, et le contrôleur déploierait les routes d'API à tous les clusters de passerelle DC. Parallèlement, le CNAME par défaut du domaine de service sera acheminé vers un nom de domaine de passerelle unifié.

**Apache APISIX pourrait directement fournir un service avec des déploiements multi-sites d'accès le plus proche et une capacité de basculement pour la reprise après sinistre, et prend en charge la résolution de routes personnalisées définies par les utilisateurs.** De plus, les utilisateurs pourraient personnaliser la configuration de la résolution de routes via le nom de domaine UUID s'ils ont besoin de basculement, de déploiement bleu-vert et de version canari. En outre, **Apache APISIX prend également en charge la planification personnalisée de la récupération des services backend**.

![Diagramme de routage directionnel d'iQIYI](https://static.api7.ai/2022/12/02/63898546bd508.jpeg)

### Réalisation 5 : Amélioration de la tolérance aux sinistres multi-sites et multi-niveaux

Afin de gérer des situations comme un trafic important, des tonnes de clusters et un large public de clients, iQIYI nécessite un accès au service le plus proche et une reprise après sinistre au niveau opérationnel.

**En plus des sauvegardes multi-sites et multi-liens pour la reprise après sinistre, iQIYI doit encore considérer les problèmes liés aux situations multi-niveaux et multi-nœuds. APISIX aide à cela.** Plus les clients sont proches des nœuds morts, plus les impacts sur les affaires et le trafic sont importants.

1. Si le nœud de service backend le plus éloigné est en panne, iQIYI pourrait réaliser la coupure d'un seul nœud ou le basculement du DC mort via le centre de services et le mécanisme de vérification de l'état de santé de la passerelle. Ainsi, l'impact serait limité à des services spécifiques, n'affectant aucun utilisateur.
2. Si la passerelle est en panne, alors iQIYI pourrait utiliser le mécanisme de vérification de l'état de santé de L4 DPVS pour couper les nœuds de passerelle défaillants, et l'impact est relativement faible, n'affectant aucun utilisateur.
3. Si les mesures de disjonction ci-dessus ne peuvent pas réparer le nœud mort, alors iQIYI pourrait réaliser un basculement automatique dans DNS via le test de disponibilité multi-nœuds de granularité de nom de domaine sur l'extranet. Cependant, cette méthode est relativement lente et pourrait impacter de nombreux autres services, et les utilisateurs pourraient en être conscients.

## Plan futur d'iQIYI

Dans l'intégration avec APISIX, iQIYI essaie d'optimiser certains problèmes pour mieux s'adapter à ses activités.

1. Considérant les éventuels goulots d'étranglement de certains composants dépendants, comme etcd, la surveillance Prometheus et le service de journalisation, **iQIYI prévoit d'utiliser une méthode de déploiement hybride. C'est-à-dire : partager les informations à l'intérieur des grands clusters et garder les petits clusters indépendants.** Par exemple, les services vitaux seront déployés avec les petits clusters.

2. Plus de **réduction et d'optimisation correspondantes pour les métriques de surveillance Prometheus** seront effectuées, en particulier pour la découverte de services DNS.

> Cong a déclaré : "Nous espérons qu'Apache APISIX pourra supporter plus de fonctionnalités et maintenir une excellente efficacité de performance ainsi qu'une stabilité dans les développements et mises à jour futurs."

## Vous cherchez un support APISIX ?

Vous souhaitez accélérer votre développement avec confiance comme iQIYI ? Pour maximiser le support APISIX, vous avez besoin d'API7. Nous fournissons un support approfondi pour APISIX et des solutions de gestion d'API basées sur vos besoins !

Contactez-nous à tout moment : [https://api7.ai/contact](https://api7.ai/contact).


L'équipe technique d'iQIYI a comparé APISIX à Kong, mis à jour et intégré l'infrastructure pour construire une nouvelle passerelle API performante.

iQIYI stimule l'innovation des passerelles API avec Apache APISIX

## 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.

Apache APISIX vs Kong:
93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

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

iQIYI stimule l'innovation des passerelles API avec Apache APISIX

API Gateway pour Web3 : Comment APISIX renforce Hyperchain

Prêt à gérer vos API ?

Apache APISIX vs Kong:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

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

iQIYI stimule l'innovation des passerelles API avec Apache APISIX

API Gateway pour Web3 : Comment APISIX renforce Hyperchain

Prêt à gérer vos API ?

Apache APISIX vs Kong:
93x Faster & 200% QPS