Pratique de la passerelle API chez Tencent avec Apache APISIX

Qu'est-ce qu'une API Gateway ?

Architecture traditionnelle

Avant d'intégrer une API Gateway, nous avons peu de moyens de réutiliser certaines fonctionnalités générales, telles que :

• Sécurité : authentification, autorisation, anti-rejeu, anti-altération, anti-DDoS, etc.
• Fiabilité : dégradation de service, fusion, limitation de trafic, etc.

Dans l'architecture traditionnelle, la manière la plus courante de gérer ce cas est de les intégrer dans un framework de service et de les implémenter via AOP, comme illustré dans le diagramme d'architecture suivant :

Le diagramme d'architecture traditionnelle comprend les modules suivants.

• Backend : Services backend
• AOP : Couche AOP portée par le framework ;
• SD : Centre de services, utilisé pour la découverte de services internes. Dans les technologies cloud-native, nous utilisons souvent Service pour remplacer ce composant ;
• LB : Équilibreur de charge, utilisé à la frontière du réseau comme point d'entrée du trafic externe.

Ce type d'architecture était très répandu dans les conceptions des premières années, ce qui a donné naissance à de nombreux frameworks de service complets et étendus, tels que Dubbo, SpringCloud, etc. Nous constaterons que la plupart d'entre eux ont de nombreuses fonctionnalités similaires.

L'avantage de cette architecture est que les relations entre les flux amont et aval sont plus faciles et plus claires, et elle réduit une étape de transfert dans le réseau. Mais ses inconvénients sont également évidents :

• Les fonctionnalités standard forcent les mises à jour des services métier : puisque des références de code sont utilisées, nous devons recompiler les services métier pour que les fonctionnalités soient efficaces. Certaines équipes qui ne réalisent pas de déploiement continu doivent publier pendant les périodes creuses de l'activité.
• Difficile de gérer les versions : Comme nous ne pouvons pas mettre à jour tous les services à la dernière version à chaque publication, après un certain temps, les performances des différents services seront incohérentes.

Pourquoi ne pas placer ces mêmes fonctionnalités dans un service autonome, qui peut être mis à jour ou maintenu séparément ?

Mode Gateway

Par rapport à l'architecture traditionnelle, nous pouvons voir un composant supplémentaire entre les services backend et le LB : la Gateway.

Une gateway contient généralement de nombreuses fonctionnalités standard et réutilisables, telles que l'authentification, la gestion du trafic, etc. Voici les avantages que nous pourrions en tirer :

• La Gateway est un composant dépendant des systèmes, et nous pourrions avoir une meilleure expérience de maintenance.
• La Gateway est indépendante du langage.

Cependant, le mode gateway présente également des inconvénients :

• Comme nous acheminons d'abord le trafic vers la gateway, nous avons une étape de transfert supplémentaire et une latence plus élevée. Cela entraînera une complexité accrue pour résoudre les problèmes.
• Si la gateway ne fonctionne pas correctement, elle peut devenir un goulot d'étranglement pour l'ensemble du système.

Comment équilibrer les avantages et les inconvénients du modèle de gateway est un défi pour l'équipe technique. Voyons comment le Tencent OTeam travaille avec Apache APISIX.

Introduction

OTeam

Le OTeam de Tencent est un groupe d'équipes, et chaque équipe maintient un ou plusieurs produits techniques. Leur objectif est de construire une plateforme intermédiaire stable mais robuste pour les systèmes internes. L'un des OTeam prend en charge la distribution personnalisée interne de Tencent pour Apache APISIX.

Afin d'intégrer les roues redondantes au sein de l'entreprise et de consolider le terrain technique intermédiaire. Tencent a regroupé plusieurs produits techniques de même nature dans le même Oteam, intégrant le personnel de maintenance et les fusionnant tous ensemble, afin qu'ils puissent progressivement se fondre en un seul grand produit complet, qui est Oteam.

Certains Oteams ont une douzaine de produits sous leur responsabilité, tandis que d'autres n'en ont qu'un seul. Par exemple, l'Oteam où se trouve Apache APISIX n'a qu'un seul produit, Apache APISIX. L'objectif initial de cet Oteam est de maintenir les fonctionnalités personnalisées d'Apache APISIX au sein de Tencent.

Apache APISIX

Apache APISIX est un projet de niveau supérieur de la Apache Software Foundation, et voici quelques points clés :

• Apache APISIX est une API Gateway cloud-native et dynamique basée sur OpenResty, avec une performance de routage supérieure à Kong.
• Apache APISIX fournit des fonctionnalités riches de gestion du trafic telles que l'équilibrage de charge, l'amont dynamique, la publication canari, la rupture de circuit, l'authentification, l'observabilité, et plus encore.
• Apache APISIX est efficace pour gérer le trafic traditionnel nord-sud, ainsi que le trafic est-ouest entre les services. Il peut également être utilisé comme contrôleur ingress k8s.
• Apache APISIX utilise par défaut ETCD comme centre de configuration, ce qui permet de mettre à jour la configuration en quelques secondes.
• Apache APISIX est diplômé de la Apache Software Foundation et n'a pris que quelques mois.

Stratégie opérationnelle du Tencent OTeam

Le diagramme ci-dessus montre comment le OTeam travaille avec la communauté d'Apache APISIX :

• Les utilisateurs donnent des retours ou des exigences via GitHub Issue.
• Les membres du OTeam discutent des solutions lors de réunions hebdomadaires ou répondent directement dans l'Issue.
• Implémentent des fonctionnalités ou corrigent des bugs selon la discussion.
• Revue de code et vérification CI, puis publication si nécessaire.

Ce processus est similaire à celui d'autres projets Open Source. Voici quelques points clés :

• Après avoir résolu l'Issue, les ingénieurs de Tencent déterminent si le problème est également un problème commun pour la communauté. Si c'est le cas, ils soumettent une PR à la communauté.
• Le OTeam de Tencent examine régulièrement les nouvelles fonctionnalités d'Apache APISIX pour déterminer si elles sont stables et si elles répondent également à un point douloureux pour Tencent. Si la réponse est oui, ils sélectionnent les codes pertinents.

Au début, le OTeam synchronisait les codes avec Apache APISIX toutes les 12 heures afin de pouvoir suivre rapidement Apache APISIX, mais cette approche a posé quelques problèmes :

• Après avoir synchronisé les codes avec Apache APISIX, nous pouvions nous assurer que les régulations étaient correctes mais pas que les codes étaient stables. Des erreurs occasionnelles se produisaient dans des cas de concurrence.
• Les codes fusionnés provoquaient parfois des conflits logiques avec plusieurs PR en amont, mais ni Apache APISIX ni le CI du OTeam ne pouvaient détecter ce cas. Ce n'est qu'en fusionnant les PRs dans la branche master que nous découvrions que quelque chose n'allait pas.

Pour ces raisons, le OTeam passe maintenant à la sélection des codes pour les fonctionnalités requises après des revues internes.

Tendance du OTeam

En mai 2021, le OTeam a déployé Apache APISIX pour plus de dix équipes au sein de Tencent, avec un trafic quotidien de requêtes métier dépassant le milliard. Parallèlement, le OTeam a également développé plus de dix fonctionnalités pour Apache APISIX, y compris la découverte de services, la conversion de protocole RPC, et la connexion avec la plateforme de surveillance.

En même temps, le OTeam a également contribué à certaines fonctionnalités standard à la communauté d'Apache APISIX. Actuellement, deux membres de l'équipe OTeam sont également PMCs d'Apache APISIX, et le OTeam a contribué à plus de 50 PRs à la communauté. Nous croyons que le OTeam continuera à coopérer avec la communauté d'Apache APISIX à l'avenir.

Fonctionnalités internes du OTeam

Points douloureux internes

La principale responsabilité du OTeam est de maintenir les fonctionnalités d'Apache APISIX pour Tencent. Voyons quels points douloureux le OTeam a rencontrés.

• Le framework RPC n'est pas convivial pour le frontend : il y a de nombreux projets hérités au sein de Tencent qui utilisent le framework TARS, il ne supporte pas directement le protocole HTTP comme TRPC, il ne supporte que le protocole TCP le plus traditionnel du framework RPC, et le contenu transporté utilise un protocole binaire spécifique. Nous devons maintenir un service intermédiaire pour convertir ces interfaces en une forme conviviale HTTP + JSON pour le frontend.
• Diversité des centres de services : Il existe de nombreux centres de services dans les services internes de Tencent, tels que CL5, L5, Polaris, etc. Bien que nous utiliserons progressivement le même centre de services, nous utiliserons simultanément plusieurs centres de services pendant cette période étendue. L'Apache APISIX initial ne supporte pas cela.
• Alarme : En tant que gateway, l'alarme n'est pas une direction à laquelle elle devrait prêter attention, mais en tant que composant fondamental, l'alarme doit être un composant requis pour l'équipe. Comment résoudre le problème de l'alarme est également un point douloureux.
• Sécurité : Tencent a un volume de trafic important et des exigences de sécurité. Beaucoup de produits toC utilisent le OTeam, et ils doivent faire face à un grand nombre d'abus d'utilisateurs et d'attaques du réseau. Les cas les plus typiques sont les DDos, les rejeux, les altérations de requêtes, etc. Pouvons-nous résoudre ces problèmes au niveau de la gateway ?

Résolution des problèmes

Le diagramme ci-dessus provient d'une simplification d'un cas de déploiement au sein de Tencent. Nous pouvons voir que plusieurs problèmes soulevés ont été résolus dans le OTeam :

• Conversion de protocole : basée sur Apache APISIX, le OTeam réalise la conversion de protocole TRPC et TARS. Ceux qui n'utilisent pas les services hérités HTTP peuvent directement utiliser le plugin de conversion dans la gateway pour répondre aux besoins de transfert HTTP et RPC sans écrire de services intermédiaires.
• Plusieurs centres de services : Nous avons contribué cette fonctionnalité à la communauté. Rapport à la plateforme de surveillance : Le OTeam de Tencent utilise des plugins pour se connecter aux plateformes de surveillance. Les utilisateurs n'ont qu'à faire quelques configurations, et le système rapportera automatiquement les métriques, les journaux. Au passage, les utilisateurs peuvent configurer des politiques d'alarme sur la plateforme de surveillance.
• Anti-rejeu et anti-altération : Le OTeam implémente des plugins anti-rejeu et anti-altération, permettant aux entreprises externes qui ont besoin de ces capacités de les utiliser directement pour protéger la sécurité de leurs APIs.

Nous espérons que ces exemples vous aideront à explorer davantage les scénarios d'utilisation d'Apache APISIX et à mieux l'utiliser comme une plateforme utile. Par exemple, quelqu'un a utilisé la gateway pour implémenter certaines spécifications d'API obligatoires selon les politiques de Tencent Cloud.

Résumé

Le OTeam a aidé l'équipe métier à résoudre ses points douloureux et a continuellement amélioré les fonctionnalités d'Apache APISIX au sein de Tencent, tout en avançant avec le développement de la communauté.

Si votre équipe n'a pas de gateway, vous pouvez rechercher et en apprendre davantage sur Apache APISIX et êtes invités à participer à la communauté d'Apache APISIX.