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

Aperçu

Depuis mai 2021, vivo a introduit Apache APISIX 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 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

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

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

La version open source d'APISIX fournit etcd 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.

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 en tant que passerelle de trafic vers une passerelle API, en utilisant ses avantages de limitation de débit, authentification, 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.