Snowball Finance transforme son architecture active-active avec APISIX

Wenjie Shi, Ingénieur principal de développement de l'équipe Infrastructure chez Snowball Finance, a partagé les pratiques de Snowball Finance avec APISIX lors du Apache APISIX Summit ASIA 2022. Cet article est basé sur cette présentation, qui explique comment Snowball Finance utilise Apache APISIX pour réaliser l'évolution de son architecture interne active-active, permettant ainsi une gestion plus flexible des services.

Défis

• Les modules d'authentification complexes du SDK augmentent la complexité du système et les risques de sécurité lorsque le centre utilisateur est accessible à travers les régions, en raison de l'architecture active-active uniquement disponible dans le module de service de marché.
• OpenResty manque d'un système de surveillance robuste pour l'observabilité et nécessite des scripts personnalisés pour atteindre l'évolutivité, entraînant des coûts de développement et d'exploitation plus élevés.
• Un centre de registre NGINX incomplet sans mécanisme de battement de cœur réduit la disponibilité et la stabilité, empêchant une gestion rapide des défaillances du système.

Objectifs

• Minimiser les changements sans introduire trop de variables tout en maintenant la transparence pour les groupes métier.
• Gérer les problèmes de manière uniforme au niveau de l'infrastructure et s'efforcer de compléter les services d'authentification au sein du centre de données local.

Résultats

• Mise en œuvre de l'authentification unifiée, de la coupure de circuit et de la limitation de débit au niveau de la passerelle, réduisant le couplage du système et améliorant la qualité du service dans les scénarios de double centre de données.
• Établissement d'une solution de surveillance unifiée de la passerelle à la couche de service en exploitant le système de surveillance d'APISIX, fournissant un excellent support pour le dépannage global.
• Fourniture d'une approche d'implémentation élégante pour la conversion de protocole gRPC et la gestion des services.

Contexte

Fondée en 2010, Snowball Finance a commencé comme une communauté d'investissement et est devenue une plateforme de gestion de finances en ligne leader en Chine, offrant divers services, y compris du contenu de haute qualité, des services de marché en temps réel, des outils de trading et de gestion de patrimoine aux investisseurs.

Parmi ces services, le service de marché en temps réel est connecté à plusieurs sources de données en amont et fournit des services de données stables aux investisseurs via le streaming, le stockage et la distribution de données. Par conséquent, les services de marché en temps réel ont toujours été un grand consommateur de ressources dans le système de Snowball Finance.

Par conséquent, une tâche importante au sein de Snowball Finance est d'améliorer continuellement la stabilité, y compris l'optimisation des performances des services de marché. Malgré cela, pendant les périodes de pic de trafic, certains systèmes peuvent encore connaître des ralentissements de réponse ou même devenir indisponibles en raison d'une augmentation des données, affectant l'expérience utilisateur.

Dans ce contexte, Snowball Finance a lancé un plan de transformation active-active des services pour fournir des services stables et de haute qualité aux investisseurs, où Apache APISIX simplifie grandement la mise en œuvre. De plus, en tant que passerelle API cloud-native, APISIX dispose d'une communauté active et d'un écosystème riche, supportant de multiples plugins. Ces avantages fournissent également une bonne base pour l'évolution de l'architecture cloud-native de Snowball Finance.

Points douloureux de la transformation active-active

À l'époque où elle appliquait l'architecture standalone, le trafic utilisateur entrait via l'équilibrage de charge (SLB), passait par la passerelle pour un traitement logique commun simple, puis était transféré au service backend. Le service backend, via un module d'authentification intégré, initiait l'authentification utilisateur avec le centre utilisateur de Snowball en utilisant un SDK et poursuivait le traitement ultérieur après une authentification réussie.

Dans les scénarios pratiques, certains points douloureux ont progressivement émergé.

1. Modules d'authentification SDK complexes

Lors de la mise en œuvre de la transformation active-active, le fournisseur et le consommateur de microservices ne peuvent pas être déployés et lancés de manière synchrone. Lorsque le service de marché de Snowball Finance a été lancé sur le cloud, mais que le centre utilisateur n'était pas encore supporté sur le cloud, des appels inter-centres de données se sont produits. Selon les statistiques du centre utilisateur, ses appels RPC atteignaient environ des dizaines de milliards par jour, et le volume de pointe pouvait atteindre 50 000 QPS, ce qui peut entraîner une latence plus élevée.

En même temps, la logique d'authentification de Snowball Finance était complexe. En plus des protocoles OAuth2.0/JWT, de nombreux facteurs devaient être pris en compte, tels que les versions clientes et les multiples applications sous Snowball Finance. De plus, le module d'authentification était intégré dans le service, rendant les mises à niveau plus difficiles.

2. Fonctionnalités limitées d'OpenResty

Snowball Finance utilisait OpenResty comme passerelle auparavant, mais OpenResty était faible dans certaines fonctions. Par conséquent, les développeurs doivent faire plus de personnalisation lors de l'intégration d'OpenResty avec son système de surveillance existant. De plus, les ingénieurs DevOps devaient ajouter des scripts personnalisés pour implémenter le processus de deuxième développement.

3. Dépendance au centre de registre auto-développé

Actuellement, Snowball Finance effectue l'enregistrement des services HTTP en demandant au centre de registre de l'enregistrer à la passerelle lorsque le service backend démarre et de supprimer le nœud de service lorsque le service s'arrête. Le centre de registre interrogera périodiquement les nœuds de service pour des vérifications de santé. Cependant, comparé aux projets open-source, le coût de maintenance des services auto-développés est plus élevé.

Sélection de la technologie de passerelle API

Sur la base des points douloureux révélés progressivement dans les scénarios pratiques, l'équipe Infrastructure de Snowball a commencé des recherches sur les produits de passerelle.

L'équipe espère à la fois assurer la transparence métier et minimiser les changements tout en n'introduisant pas trop de variables. L'équipe souhaite également résoudre les problèmes de manière uniforme au niveau de l'infrastructure et compléter les services d'authentification au sein du centre de données local. Compte tenu de ce qui précède, Snowball Finance a décidé de déplacer le service d'authentification vers la passerelle API.

Snowball Finance espère que la nouvelle passerelle API pourra répondre aux exigences suivantes :

• Haute performance
• Forte évolutivité
• Support de multiples protocoles
• Coût faible pour l'authentification de la passerelle

Voici une liste détaillée de sélection de technologie de passerelle API parmi OpenResty, Spring Gateway, Kong et APISIX.

Passerelle	Avantages	Inconvénients	Coût O&M	Disponibilité
OpenResty	Hautement personnalisable et stable	Faible observabilité	Élevé	Élevé
Spring Gateway	Convivial pour le développement Java	le niveau de performance ne répond pas aux exigences	Moyen	Moyen
Kong	Puissant et riche en fonctions	Base de données PostgreSQL à point unique	Faible	Moyen
APISIX	Cloud-native supporte plusieurs langages de programmation et a une forte évolutivité	/	Faible	Élevé

Après avoir considéré les demandes internes et comparé les produits de passerelle populaires sur le marché, Snowball Finance a finalement choisi Apache APISIX pour l'architecture ultérieure.

Pratique basée sur Apache APISIX

Architecture ajustée

Comme le montre la figure ci-dessus, l'architecture active-active actuelle des services de marché de Snowball est affichée à gauche, ce qui correspond à l'architecture dans le centre de données d'origine avec peu de modifications. Le côté droit montre l'architecture active-active basée sur une conception multi-région après la migration vers le cloud.

Snowball Finance a principalement effectué les ajustements suivants basés sur APISIX :

• Unification du module d'authentification à la couche proxy et utilisation d'APISIX pour l'authentification unifiée. Pour les types JWT, le plugin jwt-auth d'APISIX peut être utilisé pour l'authentification locale directement.
• Compatibilité avec OAuth 2.0, et utilisation d'APISIX pour appeler le centre utilisateur de Snowball Finance pour le traitement.
• Connexion avec le centre de registre de service RPC backend de Snowball Finance pour utiliser ses services backend pour l'authentification lorsque l'authentification JWT échoue.

Scénarios d'application

Après la connexion du service backend à APISIX, certaines pratiques ont été principalement menées dans les aspects de l'authentification de la passerelle et de l'observabilité.

Scénario 1 : Authentification de la passerelle

Comme mentionné précédemment, l'architecture précédente de Snowball Finance n'avait pas de méthode d'authentification unifiée. Une méthode reposait sur le côté application interne, qui utilisait un SDK pour appeler le centre utilisateur pour l'authentification, tandis que l'autre utilisait l'authentification JWT. Lorsque ces deux méthodes d'authentification coexistaient, cela causait des problèmes d'évolutivité et de maintenabilité.

1. Après l'intégration d'APISIX comme passerelle, Snowball Finance a utilisé la couche de passerelle d'APISIX pour gérer uniformément l'authentification. La méthode d'authentification JWT originale a été remplacée par le plugin officiel jwt-auth. La configuration et l'utilisation du plugin jwt-auth sont relativement simples : il suffit de configurer les informations pertinentes telles que les routes et les upstream dans le Dashboard, et le plugin sera activé.
2. Snowball Finance a utilisé le plugin grpc-transcode pour proxifier les appels de service d'authentification pour gérer la méthode d'authentification précédente liée à OAuth 2.0.

Snowball Finance a envisagé les trois solutions suivantes pour appeler gRPC pour implémenter l'authentification :

• Solution 1 : Utiliser Lua pour appeler gRPC directement. Comme cette solution nécessite de considérer des implémentations liées telles que l'équilibrage de charge et l'upstream dynamique, le processus sera plus compliqué, donc elle a été abandonnée.
• Solution 2 : Utiliser la coroutine Lua pour rappeler la logique Golang. Snowball Finance a abandonné cette méthode car elle manquait d'expérience pratique correspondante.
• Solution 3 : Utiliser Lua pour effectuer des appels HTTP, et l'interface gRPC est implémentée en utilisant le plugin grpc-transcode d'APISIX. Grâce aux itérations rapides d'optimisation des plugins de la communauté APISIX, Snowball Finance a finalement choisi cette option pour implémenter les appels gRPC.

Actuellement, une synchronisation manuelle des fichiers de protocole buffer est nécessaire lors de l'exécution. En effet, si le centre utilisateur modifie le fichier de protocole buffer, qui ne correspond pas à la version enregistrée par APISIX, cela peut entraîner des problèmes d'authentification.

Scénario 2 : Surveillance multi-dimensionnelle sous l'observabilité

Il est nécessaire de surveiller de nombreuses métriques après le lancement des sites web de Snowball Finance, en se concentrant principalement sur les trois parties suivantes :

• État de la connexion NGINX et trafic entrant/sortant
• Taux de code d'état d'erreur HTTP (utilisé pour le dépannage des problèmes de service ou d'upstream/downstream)
• Latence des requêtes APISIX (le temps consommé par l'exécution de la logique lorsque APISIX transfère la requête)

Par exemple, dans certains cas, la latence d'APISIX semble élevée (comme le montre la figure ci-dessous), ce qui est lié à la logique de calcul de la latence. Actuellement, la logique est le temps consommé par une seule requête HTTP sur NGINX moins la latence de cette requête acheminée vers l'upstream. La différence entre les deux temps consommés est la métrique de latence d'APISIX.

Après avoir utilisé APISIX, l'ajout ou la modification de certains plugins entraînera des changements de logique, ce qui peut entraîner des écarts dans les données liées à la latence. Afin d'éviter de confondre l'authenticité des données, Snowball Finance a également ajouté un plugin de surveillance de la latence. Tout en assurant l'exactitude de chaque surveillance de données, il est également pratique pour localiser les problèmes à l'avance, afin de faciliter le dépannage.

Il est également possible d'utiliser les capacités d'observabilité d'APISIX pour collecter les logs d'accès et les livrer au tableau de bord de trafic de manière formatée et standardisée pour la visualisation et la synthèse. Cela facilite une compréhension proactive des tendances globales sous plusieurs angles, identifiant les problèmes potentiels et les résolvant rapidement.

Scénario 3 : Mise à l'échelle du registre ZooKeeper

Dans Snowball Finance, les appels gRPC sont enregistrés et découverts basés sur le registre Zookeeper. Dans le processus d'implémentation de l'authentification, lorsque la vérification JWT locale échoue, la passerelle API doit accéder au service gRPC dans le centre utilisateur de Snowball Finance pour l'authentification, ce qui nécessite que la passerelle API obtienne la liste des adresses de service gRPC backend à partir du centre de registre.

Le plugin officiel d'APISIX apisix-seed peut intégrer ZooKeeper pour la découverte de services. Snowball Finance a effectué certaines personnalisations plus spécifiques à son propre métier.

L'implémentation spécifique est principalement sur un nœud de contenu d'APISIX. Lorsque le processus Worker démarre, il interroge le cluster ZK-Rest comme celui de la figure ci-dessous, puis tire régulièrement les données sources et les informations de l'ensemble du service, et les met à jour dans le cache local du processus Worker pour mettre à jour les listes de services.

On peut également voir dans la figure ci-dessus que le cluster ZK-Rest accède aux données de ZooKeeper sous forme de Rest. En ajoutant une instance de celui-ci, on peut atteindre des fonctionnalités de haute disponibilité, éliminant certaines opérations compliquées. Mais cette opération apporte également un inconvénient plus évident. Lors de l'interrogation périodique du cluster ZK-Rest, cela peut entraîner un retard dans la mise à jour de la liste des services.

Résumé et perspectives

Actuellement, Apache APISIX fonctionne bien en tant que couche de passerelle au sein de Snowball Finance. Plus précisément :

• L'authentification unifiée, la coupure de circuit et la limitation de débit sont implémentées au niveau de la passerelle, réduisant le couplage du système global et améliorant la qualité du service sous les doubles centres de données.
• Avec l'aide de la surveillance d'APISIX, une solution de surveillance unifiée de la passerelle au service est établie, fournissant un bon support pour le dépannage global.
• Une approche d'implémentation élégante est fournie pour la conversion et la gestion des services du protocole gRPC.

Dans l'utilisation ultérieure, Snowball Finance prévoit également de :

• Appliquer le contrôleur APISIX Ingress au cluster K8s.
• Utiliser le plugin grpc-transcode pour la conversion de protocole HTTP/gRPC pour atteindre une interface backend unifiée.
• Utiliser le plugin traffic-split pour l'étiquetage du trafic, la connexion au centre de registre Nacos, et la mise en œuvre de la publication canari et d'autres gouvernances de service.

Dans les plans ultérieurs, Apache APISIX sera utilisé pour remplacer l'OpenResty existant et finalement atteindre la gestion du trafic nord-sud à cycle de vie complet.