Abandon de Spring Cloud Gateway : comment Huanbei adopte Apache APISIX

Amour et haine pour Java

Pourquoi les systèmes financiers préfèrent-ils Java

Java est toujours populaire et privilégié par de nombreux développeurs depuis sa sortie en raison de ses avantages linguistiques et de son énorme écosystème.

Au cours des 15 à 20 dernières années, de nombreux systèmes financiers ont choisi Java comme pile technologique principale. Après quelques investigations, nous avons conclu les avantages suivants de Java :

En raison des raisons ci-dessus, Java gagne la faveur des systèmes logiciels financiers.

Le statu quo de Java à l'ère du cloud-native

Avec le développement rapide de la technologie, l'industrie abandonnera bientôt l'architecture monolithique, et les microservices et le cloud-native deviendront la norme. Cependant, dans l'environnement technologique des dernières années, Java a commencé à perdre son rôle dominant dans certains scénarios commerciaux.

Premièrement, Java a une faible performance ; vous comprendrez pourquoi je dis cela en comparant Java avec la pile technologique liée à C.

Deuxièmement, Java fonctionne sur des machines virtuelles, et les machines virtuelles gèrent la gestion de la mémoire de Java. Par conséquent, Java devient moins compétitif lorsque des performances élevées ou des changements dynamiques sont nécessaires.

En plus de cela, Java nécessite beaucoup plus de ressources. Un framework est facile à construire sans se soucier du coût. Cependant, puisque les calculs sont devenus beaucoup plus détaillés et granulaires à l'ère du cloud-native, les ressources sont devenues plus précieuses que jamais. De plus, Java coûterait d'énormes ressources à exécuter car il est lourd et nécessite des redémarrages de temps en temps. En conséquence, Java aurait des problèmes avec une forte demande de QPS et de continuité des activités.

Enfin et surtout, la question des pointeurs mérite également d'être discutée. Le pointeur est une bonne ressource pour les développeurs familiers avec C/C++. Cependant, Java fonctionne sur une machine virtuelle, ce qui signifie que la gestion de la mémoire est gérée par le GC (Garbage Collection) au lieu des développeurs. Dans ce cas, les performances de Java pourraient ne pas être suffisantes dans certaines circonstances lorsqu'il y a une demande stricte de haute concurrence, de trafic et de performances.

Pourquoi HuanBei a choisi APISIX

Shuhe Group est une plateforme de technologie financière qui fournit des services efficaces et intelligents aux entreprises et aux particuliers dans les affaires ; elle a des produits comme HuanBei, EnjoyPay, etc. HuanBei est une plateforme qui offre un service de paiement en plusieurs fois qui sert plusieurs scènes de consommation. En collaborant avec des institutions financières agréées, HuanBei fournit également des services de prêt personnel et offre des fonds de prêt pour les startups. HuanBei utilise toujours une pile technologique Java pour développer ses produits dans les affaires.

Spring Cloud Gateway est une passerelle visant à mieux gérer les microservices sous l'écosystème Spring Cloud. Spring Cloud Gateway est une passerelle API décente pour les entreprises utilisant Java comme langage de développement principal. Cependant, lors de la récente mise à niveau de la passerelle API, HuanBei a abandonné la passerelle Spring Cloud Gateway utilisée depuis longtemps et a commencé à utiliser Apache APISIX.

Différences d'architecture entre Spring Cloud Gateway et APISIX

HuanBei a utilisé trois systèmes de passerelle API différents avant d'adapter APISIX. HuanBei utilisait Spring Cloud Gateway comme passerelle pour ses systèmes d'exploitation et de sortie, et OpenResty comme passerelle pour son système commercial.

HuanBei utilise Spring Cloud Gateway comme passerelle pour ses systèmes d'exploitation et de sortie initialement en raison du fait que Spring Cloud Gateway a un énorme écosystème et un système de développement distribué facile à déployer et à maintenir. Afin de construire rapidement des modèles commerciaux, HuanBei a utilisé tous les services fournis par Spring Cloud lorsque la base commerciale a été construite.

Avec le développement des affaires, la passerelle a commencé à avoir des problèmes de stabilité dans l'architecture d'origine, comme des débordements de mémoire, une utilisation élevée du CPU, etc. Par conséquent, HuanBei utilise Apache APISIX comme seule passerelle dans l'architecture pour améliorer les performances de la passerelle et gérer uniformément plusieurs passerelles.

Dans le nouveau cadre de la passerelle, la passerelle transférerait directement le trafic des demandes au système commercial via la découverte de services. Cependant, si l'application backend ne supporte pas la découverte de services ou n'a pas de Pod sain dans le Consul, le système redirigera le trafic vers l'ancien intranet K8s Ingress.

L'application pratique d'APISIX

Huanbei doit modifier la configuration d'APISIX dans des scénarios commerciaux réels car il ne peut pas utiliser directement Apache APISIX en raison de ses multiples cadres de passerelle internes.

Construction et déploiement d'APISIX

Pendant le développement interne, HuanBei a placé les codes sources de la passerelle APISIX et les codes personnalisés dans différents chemins de route et les a laissés coopérer et itérer indépendamment. HuanBei a utilisé une image Docker pour déployer la passerelle. Tout d'abord, il créerait une image par défaut basée sur une version spécifique d'APISIX, puis il a utilisé des codes personnalisés pour l'envelopper dans une nouvelle image.

L'enveloppe des codes personnalisés n'a pas utilisé lua_package_path pour spécifier le répertoire des codes ; au lieu de cela, elle a directement couvert l'image par défaut apisix sous le répertoire des codes sources s'il existait un fichier du même nom. Dockerfile est montré ci-dessous :

FROM registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz

RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \
cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \
cp /tmp/deploy/bin/apisix /usr/bin/apisix && \
cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \
cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \
set -x && \
bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \
sed -i "1s@.*@$bin@" /usr/bin/apisix && \
rm -rf /tmp/*

Le journal d'APISIX est stocké localement (il pourrait être collecté par Syslog ou d'autres plugins) ; nous pourrions modifier le modèle de configuration de NGINX et vérifier le profil utilisé pour décider si nous voulons stocker les journaux localement ou les stocker dans FLUENTD via Syslog. Nous devons également remplacer la variable FLUENTD_HOST lors de la construction des images montrées ci-dessous :

{% **if** gw_profile and **string**.find( gw_profile,'local') then %}
access_log logs/access.**log** main;error_log logs/
**error**.**log** warn;
{%else%}
access_log syslog:server=${FLUENTD_HOST}:5141 json_format;
error_log syslog:server=${FLUENTD_HOST}:5142 warn;
{%end%}

Dans le modèle de configuration de NGINX, HuanBei a non seulement modifié le stockage des journaux, mais a également ajouté des variables d'environnement ENV et des configurations lua_shared_dicts dans des boucles et a corrigé certains paramètres d'optimisation de NGINX.

HuanBei sépare le trafic en fonction des différents besoins commerciaux et crée plusieurs passerelles avec des fonctionnalités similaires. Par conséquent, HuanBei utilise un plan "source unique mais plusieurs applications de passerelle" en interne. Tout d'abord, HuanBei configure le fichier config-xxx.yaml de chaque passerelle en utilisant la fonction de profil, puis il pourrait construire les images Docker des différentes passerelles en fonction du nom de l'application lors de la construction des images via la plateforme DevOps.

Plugins personnalisés de niveau entreprise

Lors de la visite du système d'exploitation en interne, le système appellerait de nombreuses API backend pour récupérer des données, et ces API doivent être incluses dans la liste blanche de la configuration de la passerelle API. Le système de permissions devrait maintenir une liste d'API associée puisque la page offrirait différentes plages d'API en fonction du rôle de chaque utilisateur connecté dans le système d'exploitation. Chaque fois qu'il y a un nouvel appel d'API depuis la page, les développeurs doivent ajouter la configuration deux fois dans la passerelle et le système de permissions, ce qui est redondant et répétitif.

Pour y parvenir, HuanBei supprime la barrière entre la configuration de la passerelle et la configuration du système de permissions, et ne garde que l'entrée du système de permissions. Le système de gestion de configuration de la passerelle récupérerait périodiquement l'API de permissions, puis la convertirait en configuration de liste blanche d'API de la passerelle. Ce comportement omettrait une action de configuration utilisateur inutile et aiderait le système de permissions à effectuer le contrôle des permissions. De plus, il garantit que l'API backend appelée dans la page d'exploitation existe dans la configuration du système de permissions.

Dans les scénarios commerciaux, il y a toujours des besoins que les plugins natifs ne peuvent pas satisfaire, ce qui nécessite un développement personnalisé. APISIX fournit de nombreux outils qui pourraient aider à personnaliser facilement les plugins natifs. Le tableau suivant répertorie certains plugins personnalisés développés sur la base d'APISIX à l'intérieur de HuanBei :

Déploiement canari de la passerelle

Auparavant, HuanBei utilisait OpenShift comme conteneurs K8s (il a été mis à niveau vers le cluster ACK actuellement), et l'Ingress est construit avec Haproxy.

En raison du fait que l'Ingress K8s du réseau public Haproxy ne pouvait pas diviser le trafic d'un seul domaine en deux chemins de route différents de Namespace, nous devons envisager de déployer la nouvelle passerelle dans le même Namespace au lieu de l'ancienne passerelle. En d'autres termes, chaque chemin de route de domaine aurait plusieurs services, et nous pourrions contrôler le trafic des nouvelles et anciennes passerelles en attribuant différentes portions du trafic total.

Le flux de mise en œuvre réel est montré ci-dessous, il ajouterait les groupes c et d pour déployer une nouvelle passerelle sous le Namespace de l'ancienne passerelle, et il pourrait contrôler la proportion de trafic des nouvelles et anciennes passerelles.

Facteurs de la passerelle liés à Java

De nombreux développeurs Java choisiraient Spring Cloud dans l'architecture de microservices puisque Spring Cloud pourrait supporter Java de manière transparente, et il intègre des bibliothèques de classes dans les codes sources. Cependant, des situations difficiles de mise à niveau apparaissent dans la pratique. Par exemple, si l'équipe doit maintenir plusieurs bibliothèques de classes, et qu'il y a 10 langages différents avec 10 versions différentes, alors cette équipe doit maintenir 100 bibliothèques de classes différentes.

Actuellement, nous pourrions facilement utiliser un proxy (passerelle API) pour résoudre les problèmes de multi-version et de multi-langages. Alors, quels sont les avantages pour les entreprises qui utilisent une pile technologique Java et choisissent APISIX comme passerelle API ? Nous concluons sur deux aspects basés sur l'expérience pratique de HuanBei.

Pour l'entreprise

1. Grande fonctionnalité et performance

Le QPS d'APISIX pourrait atteindre 80k si HuanBei utilise des machines virtuelles à 4 cœurs sans aucun plugin pour tester en charge APISIX. De plus, APISIX résout parfaitement le problème de performance de Spring Cloud Gateway lors de la réception du trafic des consommateurs, et sa performance s'améliore de 30% dans l'environnement de production par rapport aux passerelles précédentes.

En plus de cela, APISIX pourrait répondre à toutes les exigences de l'entreprise lors des tests réels, comme l'authentification et l'identification, l'observabilité, la découverte de services, la limitation de taux, et le transfert de trafic de couche quatre et sept. Concernant l'extension des fonctionnalités, APISIX supporte plus de 70 plugins, et la plupart des entreprises peuvent utiliser ses plugins natifs, ce qui réduit une quantité énorme de travail de développement.

2. Réduire les coûts commerciaux

Avant d'utiliser APISIX, les entreprises devaient augmenter le nombre de serveurs pour résoudre les problèmes de performance, ce qui augmentait considérablement les coûts matériels.

HuanBei a calculé le coût, et il a constaté que le coût des serveurs a diminué d'environ 60% après l'utilisation d'APISIX. De plus, après avoir uni la pile technologique, l'entreprise pourrait étendre rapidement différentes fonctionnalités basées sur l'architecture native d'APISIX, réduire les dépenses de développement et accélérer le temps de sortie des produits.

Pour les développeurs

1. Répondre aux besoins commerciaux

Tous les logiciels ou technologies utilisés dans les affaires devraient servir les besoins. Cependant, d'après les résultats des tests pratiques et des recherches, APISIX a une meilleure stabilité, observabilité et extensibilité.

Le logiciel vise à servir les affaires. Par conséquent, si une exigence commerciale pourrait aider l'entreprise à économiser des ressources, quelle que soit la pile technologique utilisée par cette entreprise, elle devrait également utiliser les composants qui correspondent à l'entreprise.

2. Réduire les frais de maintenance

Par rapport à OpenResty précédemment utilisé, APISIX a un coût d'apprentissage plus faible et est plus facile à maintenir. Parallèlement, les riches plugins d'APISIX simplifient le déploiement et le développement de certaines fonctionnalités standard, réduisant le temps de sortie des produits.

Parallèlement, les puissants journaux et la fonction de débogage dynamique d'APISIX aident à détecter les points de défaillance dans les affaires afin que nous puissions localiser rapidement l'erreur et gagner du temps.

Conclusion : Tendances du développement de l'industrie financière

Au stade de croissance brutale, la seule chose qui compte est l'efficacité. Ainsi, le directeur préférera son langage familier pour construire le système et choisira différentes piles technologiques lors des sélections de cadre de bas niveau pour lancer les modèles commerciaux plus rapidement. Différents directeurs choisiront d'autres piles technologiques, ce qui causera de nombreux problèmes futurs. Cependant, la plupart des entreprises financières actives et des sociétés de services financiers feront face au même problème technique : le problème des multi-piles technologiques. Lorsque ce problème se produit, ils doivent combiner leurs piles technologiques en une seule.

Lorsque l'entreprise fonctionne sur la bonne voie, il est temps pour l'entreprise de diviser son système verticalement. L'entreprise doit transformer son architecture en silo d'information en une architecture à trois couches composée d'un front-end, d'un middle-end et d'un back-end. Ensuite, lorsque le système fonctionne de manière stable, il est temps pour les entreprises de mettre en œuvre elles-mêmes les composants de bas niveau.

L'objectif final de la construction d'un système est de partager. Le système a des frais de maintenance plus faibles s'il a une meilleure répétabilité. Par conséquent, lorsque l'exploitation commerciale se stabilise, de nombreuses entreprises commencent à diviser verticalement ou à mettre en œuvre les composants fondamentaux de bas niveau pour contrôler les frais de maintenance.

Pour les entreprises, la dépense est toujours le principe le plus important à considérer. Au stade de croissance brutale, les entreprises ont seulement besoin de lancer et de faire fonctionner les affaires le plus rapidement possible. Cependant, la dépense devrait avoir la plus haute priorité sous le budget dans cet environnement large. Dans ce cas, nous devons choisir entre l'efficacité et le coût. Par conséquent, les entreprises n'utiliseraient pas la technologie de pointe si le budget est limité. De même, le personnel technique ne considérerait pas les questions suivantes lorsqu'il choisit la pile technologique : Comment cette nouvelle technologie affecterait-elle l'équipe ? Combien d'avantages cette nouvelle technologie pourrait-elle apporter à l'infrastructure actuelle ?

Le personnel technique ne considérerait que la dépense de cette nouvelle technologie.