Pourquoi Beike, la plateforme immobilière populaire, choisit Apache APISIX

Bonjour, je suis Hui Wang, responsable du développement du système de passerelle API chez Ke Holdings (Beike), une plateforme intégrée en ligne et hors ligne leader pour les transactions et services immobiliers en Chine. Beike utilise Apache APISIX comme passerelle API sur le système de production. En tant qu'entreprise axée sur les données, des millions de trafics de production passent quotidiennement par la passerelle API, et Apache APISIX offre une performance stable et exceptionnelle. Récemment, Apache APISIX a rejoint l'incubateur Apache, et je profite de cette occasion pour partager les raisons pour lesquelles nous avons choisi Apache APISIX dès le début ainsi que certaines expériences lors de son utilisation.

Kong ou Apache APISIX

Pour les exigences techniques de la passerelle, celle-ci doit avant tout offrir une excellente performance et la capacité de supporter un trafic important. De plus, elle doit également être stable, avec un taux d'erreur nul.

Le principe de sélection du fournisseur est de reconstruire une version plus stable basée sur ou inspirée d'autres projets open source pour gérer un trafic plus important. Après avoir évalué les avantages et les inconvénients, j'ai discuté de cette idée avec mon superviseur, et nous avons décidé de lancer ce projet. Le premier choix qui m'est venu à l'esprit était Kong, une autre passerelle open source célèbre.

Après avoir parcouru le site officiel de Kong et lu quelques articles connexes, j'ai pensé que Kong était une option appropriée car il pouvait répondre à la plupart des besoins des utilisateurs, et la performance était également très stable. J'ai immédiatement cloné le code et commencé à le lire. Cependant, je me suis senti assez confus même après plusieurs jours d'investigation. Je suppose que j'ai compris la raison pour laquelle Kong a une base de code si importante, c'est qu'il doit fournir une multitude de fonctionnalités.

Soudain, plusieurs questions ont tourné dans mon esprit. Combien de temps me faudra-t-il pour comprendre complètement Kong ? Combien de temps cela prendra-t-il pour construire un projet qui répond à toutes les exigences ? Ai-je besoin de toutes ces fonctionnalités que Kong propose ?

Quelques jours auparavant, la version 0.5 de la passerelle API Apache APISIX avait été publiée. Avec une attitude d'apprentissage, j'ai rapidement jeté un œil à ce projet open source et j'ai été surpris de découvrir qu'il avait été développé par Yuansheng Wang et Ming Wen, deux experts dans le domaine des API. Je ne pouvais pas refuser ce produit basé sur l'approbation de ces experts.

Comme le projet open source était né il n'y a pas longtemps, les fonctionnalités supportées par Apache APISIX étaient également assez limitées. Cependant, toutes les fonctions essentielles, telles que l'équilibrage de charge dynamique, le disjoncteur, l'authentification et la limitation de débit, avaient déjà été implémentées. Par ailleurs, une base de code relativement petite réduit également le coût d'apprentissage. Comparé à Kong, je pouvais annoncer la victoire d'Apache APISIX. Apache APISIX est plus adapté à ma situation actuelle car il peut répondre à mon plan de fonctionnalités initial sans aucun souci de fonctionnalités inutiles.

Cependant, le problème le plus critique est que la performance d'Apache APISIX pourrait être un point faible en raison de son temps limité en open source. Comparé aux résultats des tests de stress avec Kong dans le même environnement de test, Apache APISIX a finalement battu Kong. Cependant, ce n'est pas juste pour Kong car Kong est beaucoup plus lourd et complexe. D'un autre côté, il n'y a aucune différence dans mon cas d'utilisation car toutes les fonctionnalités nécessaires sont fournies dans Apache APISIX. Selon le rapport de performance d'Apache APISIX, un seul cœur de CPU peut atteindre 24k QPS, tandis que la latence n'est que de 0,7 millisecondes.

En résumé, j'ai choisi Apache APISIX pour les raisons suivantes :

• À condition qu'il puisse répondre à tous les besoins du projet, le coût d'apprentissage d'Apache APISIX est faible
• Kong a une base de code importante, ce qui rend difficile la maintenance du code
• Les auteurs d'Apache APISIX sont plus actifs dans la communauté OpenResty, ce qui peut fournir une meilleure qualité de code
• La chose la plus importante est de résoudre rapidement toute question en communiquant directement avec les auteurs

Les raisons pour APISIX fournies par le site officiel sont illustrées dans la figure suivante :

Quelles capacités Apache APISIX peut-il fournir

• Mises à jour à chaud et plugins à chaud
• Équilibrage de charge dynamique
• Vérification de santé active et passive
• Disjoncteur
• Authentification
• Limiteur de débit
• Conversion de protocole gRPC
• Dynamic TCP/UDP, gRPC, WebSocket, MQTT broker
• Tableau de bord
• Liste interdite et autorisée
• Serverless

Apache APISIX a été publié en près de dix versions, supportant bien plus de fonctionnalités que celles listées ici. Le diagramme d'architecture est dessiné selon la situation commerciale, comme suit :

L'histoire de notre intégration d'APISIX

Après quelques jours de lecture de code, j'ai une compréhension de base d'Apache APISIX, mais une question s'est posée : je n'ai jamais développé de projets open source. Comment pourrais-je y parvenir ? J'ai créé trois branches différentes localement, une branche Apache APISIX pointant vers le dépôt open source en amont, une autre branche dev utilisée pour l'itération régulière des affaires, et la dernière branche principale utilisée pour les mises à niveau en ligne.

Après deux semaines de travail acharné, mon projet a enfin une structure fondamentale. Il est temps d'examiner le résultat ; c'est ainsi que nous avons commencé la phase de test de stress. Le service est déployé sur Tencent Cloud avec des serveurs de 8 cœurs et 32 Go de mémoire, et l'amont est un environnement de production cloud régulier, donc il ne peut pas être testé trop fort. Le rapport de performance est le suivant :

Résumé du rapport de performance : Le temps de consommation de l'interface est réduit de 47%, aucune erreur n'est levée, et la stabilité est améliorée. La valeur de pointe TPS est augmentée de 82%, aucune erreur n'est levée, et la stabilité est améliorée.

L'environnement de développement est prêt, et nous avons commencé à étudier le déploiement cloud. Apache APISIX supporte de nombreuses méthodes d'installation : Docker, RPM Package, Luarocks, et les codes sources. La mauvaise nouvelle est que rien n'est autorisé à être installé dans l'environnement cloud, et le code source ne peut être placé que dans un chemin de route fixe. Par conséquent, de nombreuses fonctionnalités d'Apache APISIX ne seraient pas supportées car elles sont développées sur OpenResty 1.15.8. Que pourrais-je faire ? Les fichiers compilés sont générés dans le dépôt de code, il doit être compilé sous un répertoire spécifié, et vous ne pouvez pas utiliser la liaison statique de PCRE, ce qui nous a coûté 1-2 jours. Enfin, nous avons ajusté la sortie grise ; le trafic est passé de 2% au volume total en quelques semaines. Heureusement, tout s'est bien passé à la fin.

Après plusieurs semaines de surveillance, le service en ligne est relativement stable. De nombreuses fonctionnalités d'Apache APISIX 0.5 doivent être implémentées via des appels d'interface API. Les paramètres de requête sont sujets à des erreurs de syntaxe, et il n'y a pas de page intuitive et pratique. En dehors de cela, notre scénario commercial nécessite la fonctionnalité de sondage des services en amont. C'est une coïncidence qu'Apache APISIX version 0.7 vient d'être publiée, et la version 0.7 supporte la console et l'exploration des services en amont, ce dont nous avons besoin actuellement. Quelle bonne nouvelle ! Nous devons mettre à niveau !

La branche Apache APISIX est facile à mettre à niveau vers 0.7, mais comment pourrions-nous fusionner le code ? Les changements de code entre ces deux versions sont énormes. J'essaie de les fusionner d'abord, mais il y a trop de conflits, et nous sommes à un rythme dangereux. La méthode standard de résolution des conflits est irréaliste, ce qui pourrait causer des tonnes de bugs cachés. Y a-t-il une solution efficace ? J'ai cherché en ligne et trouvé les méthodes raccourcies : git checkout –ours et git checkout –theirs (veuillez le rechercher si vous ne l'avez pas utilisé), et j'ai terminé la mise à niveau d'APISIX 0.5 à 0.7 en quelques minutes. Bien sûr, il faut également remercier la robustesse du code APISIX, qui me permet de n'ajouter que des plugins commerciaux sans aucun couplage.

Depuis que la version 0.7 d'Apache APISIX fournit une console, il n'est plus nécessaire de taper du JSON. J'ai rapidement examiné la vérification de santé, et il n'y avait aucun problème initialement, et je pouvais percevoir l'état du service en amont. Cependant, lorsque j'ai vérifié les logs du service en amont, j'ai constaté qu'après plusieurs redémarrages, la fréquence de la vérification de santé augmentait. Je suppose qu'il pourrait y avoir un bug dans la vérification de santé. Après avoir lu le code source, j'ai découvert que le vérificateur pour chaque routeur n'est pas globalement unique. Au lieu de cela, chaque travail a un vérificateur. Nous pourrions résoudre ce problème en utilisant le même nom pour tous les travaux créés. Même s'il s'agit d'une correction mineure, un PR de correction à chaud est nécessaire.

J'ai mis à niveau l'APISIX commercial en ligne à 0.7 et surveillé l'utilisation des ressources du service. Après tout, c'était un changement de version important, et je n'ai rien ressenti pendant les premières heures, similaire au dernier changement 0.5. Je vais jeter un deuxième coup d'œil lorsque je quitterai le travail. Il semble que l'utilisation de la mémoire ne soit pas correcte. La version 0.5 a été relativement stable, mais la version 0.7 semble avoir des fuites de mémoire. Comme l'utilisation de la mémoire augmente très lentement, j'ai décidé de la surveiller toute la nuit. Le lendemain, j'ai comparé les données surveillées, déterminé qu'il y avait une fuite de mémoire, et rapidement rétrogradé à la version précédente. Après avoir tout terminé, j'ai fourni un retour à Yuan Sheng sur ce problème. Selon le scénario que j'ai décrit, j'ai trouvé le problème grâce à des tests de stress. C'était un problème avec l'arbre radix. Le même problème ne s'est jamais reproduit après avoir mis à niveau les dépendances depuis que Yuan Sheng a publié la nouvelle version de l'arbre radix.

Après avoir relancé le projet, la version 0.7 d'Apache APISIX pouvait encore me surprendre de temps en temps. La dépendance de routage utilisée dans Apache APISIX 0.5 était libr3, tandis qu'Apache APISIX 0.7 utilisait l'arbre radix, qui offre de meilleures performances. Les pourcentages d'utilisation du CPU et de la mémoire ont tous deux diminué. Dans Apache APISIX 0.5, l'utilisation du CPU est de 1-10%, et la mémoire est de 0.1%. Dans Apache APISIX 0.7, l'utilisation du CPU est réduite à 1-2%, et la mémoire est inférieure à 0.1%, ce qui est excellent.

Plan futur

Apache APISIX a été lancé depuis deux mois, et il n'y a eu ni échecs ni erreurs. Ce n'est que le début, et nous pouvons faire beaucoup plus à l'avenir pour montrer plus de capacités aux fournisseurs de services. La passerelle fournit un proxy inverse et aide certaines équipes qui n'ont pas le temps de développer des fonctions à assurer la stabilité du service, y compris des services tels que la limitation de débit, le disjoncteur, la surveillance et les plateformes d'accès.

Enfin, je tiens à remercier Yuan Sheng et Wen Ming pour avoir fourni un produit aussi excellent et la communauté Apache APISIX pour les fonctionnalités itératives contribuées. Maintenant, le trafic quotidien de la passerelle a dépassé 100 millions, et il n'y a aucun problème de performance. Merci pour votre temps et votre attention !