APISIX motive la mise à niveau de la passerelle API dans Tencent BlueKing

Cette étude de cas est partagée par Lei Zhu, Directeur Technique de la plateforme BlueKing PaaS, IEG (Interactive Entertainment Group), Tencent

À propos de BlueKing

BlueKing est un ensemble interne de recherche et d'exploitation intégrés PaaS incubé au sein de Tencent IEG (Interactive Entertainment Group), servant plusieurs unités commerciales et plateformes internes. Son rôle est de fournir des services tout au long du cycle de vie des projets de l'entreprise aux étapes CI (Intégration Continue), CD (Livraison Continue) et CO (Exploitation Continue).

Aperçu

Défis

• Faibles performances : Faibles performances en conditions de haute concurrence et algorithme de routage, entraînant un ralentissement de la correspondance et du transfert des routes
• Pression énorme sur la base de données : Les politiques de routage sont stockées dans MySQL. Par conséquent, la base de données est sollicitée par de nombreuses demandes de récupération
• Coûts élevés : Redis est largement utilisé dans de nombreux scénarios, entraînant des coûts de surcharge élevés
• Isolation insuffisante : Impossible de réaliser une isolation physique ; connexions à long terme instables
• Support d'un seul protocole : Seul le protocole HTTP est supporté
• Pas de routage dynamique : Pas de règles de routage dynamique correspondant à des conditions ; peu convivial pour les lancements en canary et incapable d'encapsuler des scénarios
• Manque de découverte de service : Peu convivial pour l'architecture microservices

Objectifs

• Transformer les capacités de la plateforme en microservices indépendants, et mener une transformation microservices pour former une architecture PaaS
• Utiliser la technologie low-code pour développer efficacement des SaaS afin d'utiliser les capacités microservices de la plateforme PaaS
• Répondre de manière flexible à différents scénarios de service grâce à divers SaaS

Résultats

• Réalisé l'exploitation et l'expansion unifiées de la passerelle en utilisant la ressource personnalisée CRD fournie par K8s
• Fourni des fonctionnalités plus riches intégrant APISIX : gestion des ressources, versions de publication, documents automatiques, gestion des permissions, observabilité, surveillance et protection de la sécurité
• Réduit les coûts pour supporter les scénarios de découverte de service avec des interfaces et régulations unifiées pour les développeurs

La diversité et la complexité des jeux nécessitent la passerelle API BlueKing

Au sein de Tencent, il peut y avoir des milliers de jeux. À l'exception de certains jeux développés en interne, les autres appartiennent à des agences. Les jeux diffèrent par les langages, le stockage dont ils dépendent, et le style architectural détermine que BlueKing a développé sa propre passerelle API.

Face à un scénario commercial aussi complexe impliquant un grand nombre d'architectures hétérogènes, BlueKing, en tant que plateforme interne, doit transformer sa passerelle API pour développer une architecture PaaS, puis utiliser la technologie low-code pour développer efficacement des SaaS et utiliser la capacité microservices de la PaaS, et utiliser divers SaaS pour gérer les scénarios de service.

Pour abstraire l'architecture de BlueKing, nous pouvons obtenir un diagramme API.

• D'une part, BlueKing est une plateforme complexe avec des exigences complexes pour une passerelle unifiée. En plus de servir de proxy pour appeler l'API des plateformes, BlueKing nécessite plus de capacités de passerelle, par exemple, découverte de service, autorisation et authentification, routage dynamique, lancement en canary, et limitation de débit, etc.

• D'autre part, avec le développement de la technologie cloud-native, de nombreux SaaS internes et plateformes sont désormais déployés dans des clusters K8s. Ce scénario pose de nouvelles exigences pour la passerelle, comme le contrôle unifié du trafic des demandes d'appel externes via une passerelle de trafic unifiée ou une passerelle API.

En même temps, certains systèmes commerciaux internes utilisent certaines des capacités d'infrastructure de la plateforme BlueKing, comme la gestion de conteneurs ou la surveillance. Ils ont également besoin d'une passerelle de service unifiée pour gérer tout le trafic d'appel.

Avec le développement des exigences commerciales internes, la passerelle API de BlueKing doit supporter des scénarios de plus en plus diversifiés.

Passerelle API BlueKing 1.0

La passerelle API BlueKing 1.0 visait à permettre à l'appelant des plateformes (y compris divers SaaS et moteurs de processus) d'appeler directement la passerelle API pour effectuer la conversion de protocole et la vérification des autorisations via la passerelle.

L'architecture était également relativement simple, divisée en deux parties : le côté serveur et le côté gestion. Les plateformes doivent accéder au côté gestion, configurer les adresses des ressources API et leurs permissions correspondantes des plateformes, et enfin enregistrer leurs services auprès de la passerelle API.

Après plusieurs années, avec l'augmentation des demandes et des scénarios complexes, les lacunes de la passerelle API BlueKing 1.0 ont commencé à apparaître progressivement. Par exemple :

• Mauvaise performance du framework : Le framework Django a été choisi pour la mise en œuvre. Sa performance est moyenne dans les scénarios à haute concurrence et devient tendue lors du traitement de demandes massives.

• Performance moyenne de la mise en œuvre du routage : La performance de l'algorithme utilisé dans le routage API est faible, affectant la vitesse de correspondance et de transfert des routes.

• Les bases de données sont sollicitées : Toutes les politiques de routage sont stockées dans MySQL. Lorsqu'il y a beaucoup de règles, de nombreuses demandes de récupération doivent être effectuées avec une pression de requête importante.

• Coûts réseau élevés : Redis est largement utilisé dans divers scénarios, entraînant des coûts de surcharge réseau trop élevés.

Passerelle API BlueKing 2.0

Afin de résoudre les problèmes ci-dessus, BlueKing a itéré sur la base de la version 1.0 et a conçu et mis en œuvre la version 2.0. Par rapport à la génération précédente, le changement le plus important de la version 2.0 a été la réimplémentation du framework de passerelle et de la couche de transfert en Golang car Golang présente plus d'avantages que Python pour traiter les demandes concurrentes massives.

D'autres changements d'optimisation ont également été apportés. Par exemple, une implémentation de routage plus efficace a été maintenue en mémoire ; un cache basé sur la mémoire a été introduit dans la couche intermédiaire pour réduire la dépendance à Redis. La nouvelle architecture ajoute également la gestion du cycle de vie des passerelles avec plusieurs versions et environnements et introduit un mécanisme de plugin étendu pour faciliter l'extension des capacités de la passerelle par les développeurs via des plugins.

Dans l'ensemble, la passerelle API BlueKing 2.0 résout les problèmes de performance et la plupart des points douloureux rencontrés dans la version 1.0. Mais avec le temps, de nouveaux problèmes ont commencé à apparaître lentement.

• Isolation insuffisante : Impossible d'atteindre une véritable isolation physique ; le processus de publication entraînera la déconnexion des connexions à long terme

• Support d'un seul protocole : Seul HTTP est supporté, et la demande pour des protocoles non-HTTP augmente dans les scénarios réels

• Pas de règles de routage dynamique : Pas de règles de routage dynamique correspondant à des conditions ; peu convivial pour les scénarios de lancement en canary ; incapable de combinaison et d'encapsulation basées sur des scénarios

• Manque de capacité de découverte de service : Manque de capacité de découverte de service automatique, peu convivial pour l'architecture microservices

APISIX se distingue dans la sélection technologique de la passerelle API BlueKing

Il existe de nombreux systèmes de produits dans l'entreprise qui ont besoin d'utiliser la passerelle API. Il est très difficile d'intégrer toutes les exigences diverses pour la passerelle dans le même ensemble de passerelles.

Par conséquent, nous avons l'idée de concevoir une passerelle distribuée. C'est-à-dire qu'une grande passerelle est divisée en plusieurs micro-passarelles, qui sont utilisées pour équilibrer les différences dans les exigences des différents systèmes pour les passerelles." a déclaré Zhu.

Les composants de l'architecture de passerelle distribuée sont principalement divisés en deux catégories : le côté gestion et les instances de micro-passarelle.

Le côté gestion gère et contrôle uniformément chaque micro-passarelle, et l'administrateur de chaque passerelle configure et gère la passerelle. Les instances de micro-passarelle sont des services de passerelle individuels déployés indépendamment, qui prennent en charge le trafic d'accès de chaque groupe spécifique de services et effectuent le contrôle d'accès associé selon les paramètres du côté gestion. Toutes les instances de micro-passarelle sont contrôlées par le même ensemble de côtés gestion.

"En ce qui concerne la sélection technologique de la micro-passarelle, nous avons examiné plusieurs passerelles open-source populaires sur le marché, comme Kong et Tyk. Après avoir comparé la popularité, la pile technologique, le support des protocoles et d'autres niveaux, nous avons finalement choisi APISIX comme la technologie backend la plus importante de notre micro-passarelle." a déclaré Zhu.

Zhu a déclaré que BlueKing a choisi APISIX car il est implémenté sur la base de NGINX + Lua, donc sa performance globale présente des avantages par rapport à celles basées sur Golang. De plus, APISIX est remarquable en termes d'extensibilité, et il supporte également l'extension des capacités via des plugins multi-langages. De nombreux cas d'utilisation typiques ont été observés.

En outre, grâce à sa grande compatibilité, APISIX peut être personnalisé selon les besoins de BlueKing. Par exemple, sur la base d'APISIX, BlueKing a personnalisé la surface de contrôle d'APISIX selon les exigences internes.

Passerelle API BlueKing 3.0 basée sur APISIX

Dans l'environnement cloud-native, K8s est le composant de base le plus critique qui nécessite une attention. Parce que l'ensemble de la micro-passarelle est conçu pour l'environnement cloud-native, la version 3.0 a une nouvelle conception d'architecture basée sur K8s.

La partie centrale consiste à utiliser la ressource personnalisée CRD fournie par K8s pour réaliser l'ensemble des opérations et de l'expansion de la passerelle API.

Comme le montre la figure ci-dessus, la passerelle introduit un ensemble de ressources CRD K8s, y compris BkGatewayStage (environnement de passerelle), BkGatewayService (service backend), etc. Grâce à ces CRD, BlueKing peut contrôler le comportement spécifique de chaque instance de micro-passarelle.

Plusieurs "Operators" dans la figure sont la partie centrale de cette architecture. Ci-dessus se trouve le service Plugin Operators, qui contient une série d'opérateurs de plugins. Par exemple, l'Operator responsable de la découverte de service écrira l'adresse du service backend enregistré dans le centre de découverte de service dans le cluster K8s.

L'Operator central au milieu surveille toutes les ressources CRD liées à la passerelle. Le réconciliateur de ressources est responsable de convertir la configuration de la passerelle en un format que l'instance de micro-passarelle APISIX peut comprendre, réalisant ainsi la gestion du cycle de vie complet de la micro-passarelle.

Cet ensemble de micro-passarelle est divisé en deux types de déploiement :

• Passerelle partagée : Le type par défaut, qui est déployé sur la plateforme, et l'adresse d'accès API est générée et gérée uniformément par la plateforme.

• Passerelle dédiée : L'utilisateur déploie une instance de "micro-passarelle", qui devient une "passerelle dédiée" après l'accès à la plateforme. L'adresse d'accès API doit être gérée manuellement, et le trafic passe directement de la "passerelle dédiée" au service backend.

Il n'y a qu'un seul côté gestion unifié, dont les capacités, comme la gestion multi-environnements et le contrôle d'accès, sont partagées par toutes les passerelles. Cependant, parmi les différents types d'instances de micro-passarelle qu'il gère, les ensembles de fonctionnalités supportés diffèrent les uns des autres.

Prenons l'exemple de l'instance de passerelle partagée, l'ensemble de fonctionnalités qu'elle supporte est relativement basique, comprenant principalement l'authentification de connexion unifiée, la limitation de débit, et le support multi-protocoles. Mais les instances de passerelle dédiée indépendantes ont leurs propres capacités personnalisées. Parce que la passerelle dédiée et l'entreprise appartiennent au même cluster, elle peut rapidement réaliser le routage dynamique, la découverte de service personnalisée, etc., et utiliser la robuste extensibilité d'APISIX pour personnaliser plus de capacités.

Sur la base de l'architecture et des modes ci-dessus, la passerelle API BlueKing 3.0 fournit des fonctionnalités plus riches avec le support d'APISIX. Par exemple, la gestion des ressources, la publication de versions, les documents automatiques, le SDK, la gestion des permissions, l'observabilité, la surveillance et l'alerte, et la protection de la sécurité.

Scénarios pratiques de la passerelle BlueKing 3.0 utilisant APISIX

Il existe quatre scénarios pratiques typiques au sein de Tencent : découverte de service, authentification unifiée, routage dynamique et gestion des licences du client.

Découverte de service

La découverte de service est une capacité de base requise par l'architecture microservices. En interne, elle peut être implémentée via la ressource personnalisée CRD. Une définition YAML de découverte de service valide est montrée dans le code sur le côté droit de la figure ci-dessous.

Après que les ressources CRD ci-dessus sont écrites dans le cluster K8s, elles déclencheront les actions liées aux contrôleurs de découverte de service. Ensuite, le réconciliateur peut capturer la configuration de découverte de service correspondante et créer des objets de programme liés à la découverte de service.

Ensuite, le réconciliateur lit les informations d'adresse pertinentes du centre de découverte de service via l'interface de découverte de service intégrée comme Watcher et Lister et réécrit l'adresse obtenue dans le cluster K8s via la ressource CRD BkGatewayEndpoints.

Après un traitement complexe par l'Operator central sur la droite, ces points d'extrémité sont finalement synchronisés avec l'amont correspondant à APISIX. Un processus complet de découverte de service est terminé.

Pour faciliter le développement, BlueKing a implémenté un framework de découverte de service général, qui fournit une interface de développement unifiée et une spécification, et peut être utilisé pour supporter d'autres types de scénarios de découverte de service à faible coût.

Authentification unifiée

La partie d'authentification unifiée est relativement simple. Dans la pratique quotidienne, il y a des demandes provenant de trois sources : les navigateurs, les plateformes et les utilisateurs individuels. Sur la base d'APISIX, BlueKing a personnalisé un plugin d'authentification, BK-Auth, pour réaliser l'authentification unifiée.

Le processus de mise en œuvre spécifique est montré dans la figure ci-dessus. Après la demande, le plugin lira les informations d'identification pertinentes de l'en-tête, puis appellera uniformément le service d'authentification BK-Auth pour vérifier l'identification et lire les informations SaaS correspondantes. Ensuite, le plugin utilisera la clé privée convenue avec le backend pour émettre un jeton JWT et l'écrire dans l'en-tête de la demande, et enfin, l'écrire dans la variable APISIX.

En plus de l'authentification unifiée, il existe également des scénarios d'authentification complexes dans les projets internes. Sa fonction principale est de juger si le SaaS a la permission lorsque le SaaS appelle une certaine ressource d'une plateforme. L'authentification unifiée des ressources est également implémentée par Golang via le plugin APISIX, comme le montre la figure ci-dessous.

Les demandes du client peuvent d'abord récupérer les informations de l'application SaaS via le lien d'authentification, puis interagir avec le plugin d'authentification basé sur RPC lors du passage de l'ext-plugin. À ce moment, le plugin d'authentification interrogera directement les données d'authentification dans le cache, synchronisées par le côté gestion via le mécanisme complet et incrémental, puis complétera l'authentification.

Routage dynamique

Un scénario d'application typique de routage dynamique provient de la plateforme de gestion de conteneurs de BlueKing. La plateforme de conteneurs de BlueKing gère beaucoup de clusters K8s, dont certains sont des clusters de service et d'autres des clusters de données.

En tant qu'utilisateur, vous devez souvent demander les APIServers de ces clusters. Lorsqu'une demande d'utilisateur entre dans la micro-passarelle, la passerelle détermine à quel APIServer de cluster la transférer en fonction du chemin de la demande.

Après l'entrée de la demande, le plugin de routage dynamique extrait d'abord les informations d'identification du cluster, puis réécrit la route, puis détermine si le cluster est directement connecté.

Pour les clusters non directement connectés, un gestionnaire de cluster BCS en amont est d'abord généré, puis interagit avec l'Agent BCS à travers lui, et enfin transmet la demande à l'APIServer du cluster.

Pour les clusters directement connectés, le processus est similaire au plugin d'authentification unifiée ci-dessus, et le plugin synchronisera périodiquement certaines informations de base liées au cluster. Après avoir trouvé les informations du cluster, générer l'amont pertinent, redéfinir la logique de connexion via le plugin APISIX, et enfin envoyer la demande à l'APIServer du cluster.

Gestion des certificats clients

Dans les scénarios pratiques de BlueKing, il existe une classe de systèmes qui utilisent un mode de vérification de certificat client plus complexe lors de l'enregistrement des ressources à la passerelle. Par conséquent, si un utilisateur souhaite demander ses ressources, il doit fournir un certificat client valide.

La mise en œuvre spécifique est montrée dans la figure ci-dessus. Le gestionnaire de passerelle doit configurer le certificat client utilisé par la passerelle pour différents environnements sur le côté gestion. Après la configuration, le certificat sera publié dans le cluster K8s, où se trouve la micro-passarelle correspondante.

Ce processus utilise certaines ressources CRD et les ressources officielles Secret de K8s et sera continuellement réconcilié par le service Operator central, comme trouver le certificat correspondant selon le domaine. La configuration effective du certificat client sera finalement reflétée dans la configuration pertinente du service APISIX. (Comme montré dans la boîte rouge en haut à droite de la figure ci-dessus)

Résumé

Apache APISIX est une passerelle API cloud-native open-source, dynamique, extensible et haute performance pour toutes vos API et microservices. Étant donné à la Fondation Apache Software par API7.ai, APISIX est devenu un projet open-source de premier niveau Apache.

Avec le développement de l'architecture microservices et des projets commerciaux internes, la passerelle API précédente ne peut plus répondre aux besoins. Tencent BlueKing a non seulement résolu le problème, mais a également fourni des fonctionnalités plus riches en tirant parti d'APISIX.