iQIYI stimule l'innovation des passerelles API avec Apache APISIX

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

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

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.

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

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.

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.