Transformer un géant de la gestion de fonds avec APISIX

Aperçu

À propos d'Invesco Great Wall

Invesco Great Wall Fund Management Co., Ltd. ("IGW") est une société de gestion de fonds sino-américaine, dotée de capacités d'investissement multi-actifs et d'une expertise de premier plan en actions. Les principales activités de l'entreprise incluent l'investissement quantitatif, le revenu actif et le revenu fixe. Les actifs gérés par IGW dépassent 850 milliards de dollars américains, offrant des services à plus de 60 millions d'investisseurs.

IGW met l'accent sur la gestion d'actifs, proposant une gamme variée de stratégies d'investissement couvrant plusieurs classes d'actifs telles que les actions, les revenus fixes et les stratégies quantitatives.

Défis

• L'absence de passerelles standardisées entre les différents systèmes métier a entraîné de nombreux services associés aux passerelles et des opérations indépendantes, augmentant ainsi les coûts de maintenance.
• Les passerelles précédentes d'IGW avaient une capacité et des fonctionnalités limitées, telles que l'équilibrage de charge et les déploiements canaris, qui sont complexes et chronophages à mettre en œuvre, pouvant causer des goulots d'étranglement opérationnels.
• En raison de l'absence de capacités d'authentification dans la configuration précédente, diverses interfaces système pouvaient être accédées directement, posant un risque de sécurité important pour les systèmes métier.

Résultats

• En mettant en œuvre APISIX, IGW a construit sa passerelle API unifiée, résolvant les problèmes de redondance des efforts de développement et d'incohérence de la qualité des fonctionnalités.
• L'intégration de DevOps et des pipelines a considérablement amélioré la stabilité du déploiement des routes et des services, augmentant l'efficacité des mises à jour des routes et des services.
• Le rechargement à chaud d'APISIX réduit considérablement le besoin de redémarrages de services, soulageant ainsi la pression sur les ressources système et réduisant les temps d'arrêt.

Contexte

Tout d'abord, explorons l'évolution architecturale du système métier d'IGW. Initialement, IGW a adopté une approche de service monolithique, avec des applications de service déployées sur des machines physiques. Cependant, à mesure que les services et les activités se développaient, les coûts d'exploitation et de développement ont commencé à augmenter. Cela a conduit à la transition vers la phase des machines virtuelles.

Pendant la phase des machines virtuelles, il y avait un manque d'uniformité dans les passerelles utilisées par les différents systèmes métier. Chaque activité fonctionnait indépendamment, entraînant de nombreux services associés aux passerelles et des coûts de maintenance élevés.

Dans les secteurs des fonds et des valeurs mobilières, il existe des exigences réglementaires concernant les zones réseau. Chaque zone réseau doit être divisée en différentes zones sécurisées physiquement isolées ou en zones sécurisées logiques en fonction des niveaux de sécurité de l'information, pendant lesquels le pare-feu est utilisé.

Aligné avec la stratégie cloud dans la technologie financière et la transformation numérique, IGW a lancé son projet de migration vers le cloud.

Pourquoi IGW a choisi APISIX

En raison de l'accent accru du secteur financier sur la stabilité des services par rapport à d'autres industries, la stabilité est primordiale. Alors que les environnements de machines virtuelles connaissaient une croissance effrénée des services de passerelle, il est devenu impératif de répondre à la diversité des exigences métier. Par conséquent, l'évolutivité de la passerelle est très appréciée. De plus, l'observabilité joue un rôle crucial, avec de fortes demandes pour la journalisation, le traçage et la surveillance du système métier. Enfin, la capacité de rechargement à chaud est également essentielle.

En raison des limitations de NGINX dans la mise à jour dynamique des configurations, un rechargement est nécessaire lors des changements de configuration. De plus, dans les scénarios de connexion persistante, ce processus peut entraîner des fluctuations de trafic dans le système métier, affectant l'expérience utilisateur.

Par conséquent, en tenant compte de ces quatre points focaux, l'équipe technique d'IGW a effectué une comparaison approfondie entre APISIX et Kong, deux passerelles API populaires et largement reconnues sur le marché :

• Cadre technique : APISIX et Kong sont tous deux développés sur la base d'OpenResty. Concernant le centre de configuration, APISIX adopte etcd, tandis que Kong opte pour PostgreSQL. APISIX se distingue comme une passerelle distribuée cloud-native en raison de la nature cloud-native d'etcd et des caractéristiques d'état d'APISIX. Cependant, le choix du centre de configuration par Kong peut introduire des problèmes potentiels de point de défaillance unique, nécessitant un support d'infrastructure supplémentaire pour la haute disponibilité.

• Activité de la communauté : APISIX et Kong ont tous deux une communauté active avec une moyenne de 20 commits par jour dans leurs dépôts.

• Plugins : APISIX dispose de plus de 80 plugins et un seul document pour chaque plugin ; Kong a plus de 30 plugins et 4-5 documents pour chaque plugin ; 100+ lignes de code pour chaque plugin APISIX et 300+ pour Kong.

• Évolutivité : APISIX prend en charge de nombreux langages de programmation et prend également en charge WebAssembly. Kong ne prend en charge que Lua pour écrire des plugins.

• Rechargement à chaud : C'est ce sur quoi l'équipe se concentre. APISIX prend en charge le rechargement à chaud au niveau de la milliseconde lors de l'activation ou de la désactivation de plugins, et lors de l'ajout de nouveaux plugins (tels que des plugins personnalisés). APISIX prend également en charge la modification dynamique des paramètres de la passerelle. Cependant, Kong ne prenait pas en charge cette fonctionnalité lors de la sélection technologique d'IGW.

• Observabilité : APISIX et Kong prennent tous deux en charge OpenTelemetry, mais APISIX peut également être connecté à Elasticsearch, Prometheus, et SkyWalking. Kong ne fournissait pas encore de support pour SkyWalking lors de la sélection technologique d'IGW.

Sur la base des préoccupations et des points de comparaison ci-dessus, l'équipe technique d'IGW a finalement choisi APISIX comme passerelle API.

Scénarios utilisateurs et solutions pour IGW

Introduction à l'architecture système d'IGW

Le système métier d'IGW était grossièrement divisé en trois parties : la zone de transaction, la zone de production et la zone de gestion, chacune utilisant des passerelles API différentes. À l'origine, IGW utilisait NGINX comme serveur web et proxy inverse. Les activités dans la même classification réseau utilisaient toutes le même NGINX. Par conséquent, chaque changement de service ou mise à jour de routage nécessitait une mise à jour manuelle et un rechargement sur NGINX.

Le diagramme ci-dessus illustre l'architecture système d'IGW. La couche de cluster de sécurité de la passerelle utilise plusieurs frameworks tels que Zuul, Spring Cloud Gateway, Kong et NGINX. La gestion architecturale n'était pas unifiée et la gestion était relativement fastidieuse.

Solution

Afin de résoudre ces défis, IGW met l'accent sur la transformation des clusters de passerelles en APISIX. Comme APISIX est déployé sur des clusters Kubernetes, il permet une gestion unifiée des API via YAML de manière déclarative. De plus, le contrôleur APISIX Ingress surveille automatiquement les changements dans les ressources Kubernetes, permettant une synchronisation en temps réel des configurations APISIX, y compris ApisixRoute, SSL, et plus encore.

Ci-dessous se trouve le diagramme de séquence de synchronisation des routes d'IGW après l'utilisation d'APISIX.

Scénarios utilisateurs

Après avoir utilisé APISIX, IGW a obtenu de nombreux avantages, parmi lesquels l'équipe d'IGW est plus préoccupée par le point de vue métier, y compris le routage intelligent, l'authentification, l'observabilité et le contrôle du trafic.

Routage intelligent efficace

Le routage intelligent se manifeste principalement dans l'équilibrage de charge aux niveaux 4 et 7. Comme le montre le diagramme, les informations de routage synchronisées via le contrôleur APISIX Ingress sont accompagnées d'étiquettes spécifiques, empêchant efficacement les opérations de suppression accidentelles.

Après des tests dans l'environnement, même si les données sont supprimées, Kubernetes est capable de synchroniser rapidement et automatiquement avec APISIX, résolvant ainsi le problème de perte de données.

De plus, les mises à jour de routage sur APISIX atteignent une réactivité au niveau de la milliseconde, avec un délai de synchronisation des configurations presque imperceptible, offrant une excellente expérience utilisateur.

Authentification renforcée

Avant l'introduction de la passerelle unifiée, chaque unité métier devait développer individuellement des composants liés à l'authentification pour assurer la sécurité de leurs interfaces de données. Du côté métier, chaque système était chargé de développer des fonctionnalités d'authentification redondantes, entraînant des coûts de développement plus élevés et une qualité variable des fonctionnalités implémentées. Par conséquent, pour la vérification de sécurité, IGW a introduit des plugins d'authentification unifiée et de redirection HTTPS.

Avant l'introduction de la passerelle unifiée, les certificats HTTPS pour les services étaient décryptés au point de terminaison de haute disponibilité (HA), ce qui augmentait la complexité, la charge opérationnelle et les risques de sécurité.

Reconnaissant ces défis, l'équipe technique d'IGW a élaboré un plan pour centraliser la fonctionnalité d'authentification dans la passerelle, résolvant ainsi les problèmes mentionnés. Cette approche améliore considérablement l'efficacité de la recherche et du développement des systèmes métier, permettant aux développeurs de se concentrer davantage sur le développement des activités principales.

En passant à APISIX, ces inconvénients peuvent être atténués. APISIX peut gérer la terminaison HTTPS, charger dynamiquement les certificats SSL et fournir une gestion centralisée et sécurisée pour les tâches liées à la sécurité, améliorant ainsi les performances globales du système et la flexibilité.

Au-delà de la surveillance

Auparavant, le faible support pour l'observabilité dans le système métier original d'IGW affectait négativement le dépannage du système, l'optimisation des performances, la fiabilité et la surveillance proactive.

Par conséquent, l'équipe technique d'IGW visait à intégrer rapidement plusieurs plugins fournis par APISIX, tels que la surveillance des logs et le traçage, afin d'améliorer les capacités d'observabilité.

De plus, l'équipe recherchait activement et exploitait Apache SkyWalking pour le traçage distribué, Prometheus à des fins de surveillance et ELK pour une collecte efficace des logs. Étonnamment, APISIX prend en charge tous ces plugins et s'est donc avéré être une solution idéale répondant pleinement aux attentes et aux exigences de l'équipe technique d'IGW, en faisant le choix préféré.

Le diagramme ci-dessus illustre la topologie des services d'IGW après que l'équipe technique a intégré SkyWalking en production. Ce diagramme complet offre une visualisation claire et concise des relations d'appel inter-services, englobant des informations cruciales comme la direction du trafic à travers la passerelle et les taux de réussite. En exploitant ce diagramme de topologie, l'équipe d'IGW peut rapidement identifier l'emplacement exact de toute erreur ou problème dans la chaîne de services.

Maîtrise du contrôle du trafic

APISIX s'est avéré être une solution efficace pour faciliter des mécanismes de contrôle du trafic polyvalents pour IGW. En adoptant APISIX, l'équipe technique d'IGW a réalisé de manière transparente le contrôle du trafic grâce à des stratégies de déploiement canari et basées sur le poids. Cette capacité robuste permet une gestion efficace de la distribution du trafic, permettant à l'équipe de mettre en œuvre facilement des déploiements canaris et d'ajuster les poids du trafic selon les besoins.

Dans un scénario basé sur le déploiement canari, la passerelle doit appeler une interface en aval via une requête HTTP pour obtenir des données spécifiques, et juger en fonction des résultats retournés pour déterminer si la requête doit être envoyée à l'environnement de déploiement canari.

Sur la base de la politique de poids, les services des machines virtuelles et des conteneurs sont fournis à l'extérieur en parallèle. Par exemple, 90 % du trafic atteint le service de machine virtuelle et 10 % du trafic atteint le service cloud pour vérifier la stabilité du service cloud. Actuellement, l'environnement de production d'IGW a été configuré avec un déploiement canari basé sur le poids.

Réalisations après l'utilisation d'APISIX

Construction d'une passerelle API unifiée

En mettant en œuvre APISIX, l'équipe technique d'IGW a atteint la standardisation du cadre de la passerelle API qui fournit des fonctions riches de gestion du trafic telles que l'équilibrage de charge, l'amont dynamique, le déploiement canari, la coupure de circuit, l'authentification et l'observabilité.

IGW a mis en œuvre une fonctionnalité d'authentification unifiée sur la passerelle, résolvant les problèmes de redondance des efforts de développement et d'incohérence de la qualité des fonctionnalités. Cela a permis aux développeurs de se concentrer davantage sur le développement, et a grandement amélioré l'efficacité de la recherche et du développement des systèmes métier.

Amélioration de la stabilité du déploiement des routes et des services

Les mises à jour de routage sur APISIX sont capables de fournir des réponses au niveau de la milliseconde, garantissant des performances rapides et efficaces. De plus, la synchronisation des configurations est presque instantanée, résultant en une expérience utilisateur améliorée.

En outre, l'intégration de DevOps et des pipelines a considérablement amélioré la stabilité du déploiement des routes et des services. Cette approche rationalisée a amélioré l'efficacité des mises à jour des routes et des services, assurant des résultats plus fiables et cohérents.

Le rechargement à chaud améliore les performances et la disponibilité

L'équipe technique d'IGW attache une grande importance à la puissance du rechargement à chaud. APISIX offre un processus de déploiement à chaud transparent pour l'activation ou la désactivation des plugins, facilitant l'ajout de plugins personnalisés et permettant des mises à jour dynamiques des paramètres de la passerelle.

En conséquence, les modifications des configurations des plugins et des paramètres de la passerelle peuvent être appliquées instantanément sans nécessiter de redémarrages ou d'interruptions du système. Cette remarquable fonctionnalité de rechargement à chaud améliore grandement la flexibilité et l'agilité de la plateforme APISIX, permettant aux développeurs d'effectuer des ajustements en temps réel à leurs configurations et de personnaliser la passerelle pour répondre à leurs exigences spécifiques.

La capacité de rechargement à chaud d'APISIX a grandement soulagé la pression des redémarrages de services. Cette fonctionnalité permet d'appliquer des mises à jour et des modifications aux services sans nécessiter un redémarrage complet, améliorant ainsi les performances du système et réduisant les temps d'arrêt.

Résumé

L'équipe technique d'IGW a également exprimé des attentes pour améliorer davantage la fonctionnalité, la fiabilité et les performances d'APISIX pour une opération fluide à l'avenir.

La mise en œuvre réussie d'APISIX chez Invesco Great Wall a apporté des avantages significatifs et des résultats positifs. Avec APISIX, l'équipe d'IGW a atteint un cadre de passerelle API unifié, résultant en des opérations rationalisées et des coûts réduits. L'intégration a également apporté une stabilité améliorée dans le routage et les services, conduisant à des performances améliorées et à des perturbations minimisées.

À la lumière des résultats remarquables d'Invesco Great Wall, APISIX s'avère être une solution de passerelle API hautement efficace adaptée à l'industrie des services financiers, y compris le secteur des fonds et des valeurs mobilières. Cette étude de cas réussie témoigne des avantages de l'adoption d'APISIX dans la finance et recommande fortement sa mise en œuvre à d'autres organisations du secteur.