Transformation des Fondsmanagement-Giganten mit APISIX

Überblick

Über Invesco Great Wall

Invesco Great Wall Fund Management Co., Ltd. ("IGW") ist ein chinesisch-amerikanisches Fondsmanagementunternehmen mit Multi-Asset-Investmentfähigkeiten und führender Expertise im Bereich Aktien. Die Hauptgeschäfte des Unternehmens umfassen quantitatives Investment, aktives Einkommen und festverzinsliche Anlagen. Das verwaltete Vermögen von IGW beträgt über 850 Milliarden USD, und es bietet Dienstleistungen für mehr als 60 Millionen Anleger.

IGW legt den Schwerpunkt auf das Vermögensmanagement und bietet eine Vielzahl von Investmentstrategien, die mehrere Assetklassen wie Aktien, festverzinsliche Anlagen und quantitative Strategien abdecken.

Herausforderungen

• Das Fehlen standardisierter Gateways zwischen verschiedenen Geschäftssystemen führte zu zahlreichen Diensten, die mit Gateways verbunden waren und unabhängig voneinander betrieben wurden, was zu erhöhten Wartungskosten führte.
• Die bisherigen Gateways von IGW waren in ihrer Kapazität und Funktionalität begrenzt, wie z.B. Lastenausgleich und Canary-Release, die komplex und zeitaufwendig zu implementieren sind und betriebliche Engpässe verursachen können.
• Aufgrund des Fehlens von Authentifizierungsfähigkeiten in der bisherigen Konfiguration konnten verschiedene Systemschnittstellen direkt aufgerufen werden, was ein erhebliches Sicherheitsrisiko für die Geschäftssysteme darstellte.

Ergebnisse

• Durch die Implementierung von APISIX baute IGW sein einheitliches API-Gateway auf, wodurch die Probleme redundanter Entwicklungsbemühungen und inkonsistenter Qualität der Funktionen behoben wurden.
• Die Integration von DevOps und Pipelines verbesserte die Stabilität der Routen- und Dienstbereitstellung erheblich und steigerte die Effizienz der Routing- und Dienstfreigaben.
• Das Hot-Reloading von APISIX reduziert den Bedarf an Dienstneustarts erheblich, wodurch der Druck auf die Systemressourcen verringert und die Ausfallzeiten reduziert werden.

Hintergrund

Zunächst werfen wir einen Blick auf die architektonische Entwicklung des Geschäftssystems von IGW. Anfangs setzte IGW einen monolithischen Dienstansatz ein, bei dem Dienstanwendungen auf physischen Maschinen bereitgestellt wurden. Mit dem Wachstum der Dienste und des Geschäfts stiegen jedoch die Betriebs- und Entwicklungskosten. Dies führte zur Umstellung auf die Virtualisierungsphase.

Während der Virtualisierungsphase gab es keine Einheitlichkeit bei den Gateways, die von verschiedenen Geschäftssystemen verwendet wurden. Jedes Geschäft operierte unabhängig, was zu zahlreichen Diensten führte, die mit Gateways verbunden waren, und hohen Wartungskosten.

Im Fonds- und Wertpapiersektor gibt es regulatorische Anforderungen in Bezug auf Netzwerkzonen. Jede Netzwerkzone muss basierend auf den Informationssicherheitsstufen in verschiedene physisch isolierte Sicherheitszonen oder logische Sicherheitszonen unterteilt werden, wobei eine Firewall eingesetzt wird.

Im Einklang mit der Cloud-Strategie in der Finanztechnologie und der digitalen Transformation startete IGW sein Cloud-Migrationsprojekt.

Warum IGW APISIX gewählt hat

Aufgrund des stärkeren Fokus der Finanzbranche auf Dienststabilität im Vergleich zu anderen Branchen hat Stabilität Vorrang. Da in Virtualisierungs-Umgebungen die Gateway-Dienste stark wuchsen, wurde es unerlässlich, die vielfältigen Geschäftsanforderungen zu erfüllen. Daher wird die Skalierbarkeit des Gateways stark geschätzt. Darüber hinaus spielt Observability eine entscheidende Rolle, mit starken Anforderungen an die Protokollierung, Verfolgung und Überwachung des Geschäftssystems. Schließlich ist auch die Fähigkeit zum Hot-Reloading von Bedeutung.

Aufgrund der Einschränkungen von NGINX bei der dynamischen Aktualisierung von Konfigurationen ist ein Neustart erforderlich, wenn Konfigurationsänderungen vorgenommen werden. Darüber hinaus kann dieser Prozess in Szenarien mit persistenten Verbindungen zu Verkehrsschwankungen im Geschäftssystem führen, was die Benutzererfahrung beeinträchtigt.

Daher führte das technische Team von IGW unter Berücksichtigung dieser vier Schwerpunkte einen umfassenden Vergleich zwischen APISIX und Kong, zwei beliebten und weit verbreiteten API-Gateways auf dem Markt, durch:

• Technisches Framework: APISIX und Kong basieren beide auf OpenResty. In Bezug auf das Konfigurationszentrum verwendet APISIX etcd, während Kong PostgreSQL bevorzugt. APISIX sticht als cloud-natives, verteiltes Gateway hervor, da etcd und APISIX cloud-native Eigenschaften aufweisen. Die Wahl des Konfigurationszentrums durch Kong kann jedoch potenzielle Single-Point-of-Failure-Probleme mit sich bringen, die zusätzliche Infrastrukturunterstützung für Hochverfügbarkeit erfordern.

• Community-Aktivität: Sowohl APISIX als auch Kong haben eine aktive Community mit durchschnittlich 20 Commits pro Tag in ihren Repositories.

• Plugins: APISIX verfügt über 80+ Plugins und nur ein Dokument pro Plugin; Kong hat 30+ Plugins und 4-5 Dokumente pro Plugin; 100+ Codezeilen pro APISIX-Plugin und 300+ für Kong.

• Skalierbarkeit: APISIX unterstützt viele Programmiersprachen und auch WebAssembly. Kong unterstützt nur die Verwendung von Lua für das Schreiben von Plugins.

• Hot-Reloading: Dies ist der Fokus des Teams. APISIX unterstützt Hot-Reloading auf Millisekundenebene beim Aktivieren oder Deaktivieren von Plugins und beim Hinzufügen neuer Plugins (wie benutzerdefinierte Plugins). APISIX unterstützt auch die dynamische Änderung von Gateway-Parametern. Kong unterstützte diese Funktion jedoch nicht, als IGW die Technologieauswahl durchführte.

• Observability: Sowohl APISIX als auch Kong unterstützen OpenTelemetry, aber APISIX kann auch mit Elasticsearch, Prometheus und SkyWalking verbunden werden. Kong bot zum Zeitpunkt der Technologieauswahl durch IGW noch keine SkyWalking-Unterstützung.

Basierend auf den oben genannten Bedenken und Vergleichspunkten entschied sich das technische Team von IGW schließlich für APISIX als API-Gateway.

Nutzungsszenarien und Lösungen für IGW

Einführung in die Systemarchitektur von IGW

Das Geschäftssystem von IGW war grob in drei Teile unterteilt: Transaktionsbereich, Produktionsbereich und Managementbereich, die jeweils unterschiedliche API-Gateways verwendeten. Ursprünglich verwendete IGW NGINX als Webserver und Reverse-Proxy. Geschäfte in derselben Netzwerkklassifizierung verwendeten alle denselben NGINX. Dadurch erforderte jede Dienständerung oder Routing-Aktualisierung eine manuelle Aktualisierung und einen Neustart auf NGINX.

Das obige Diagramm zeigt die Systemarchitektur von IGW. Die Gateway-Sicherheitscluster-Ebene verwendet mehrere Frameworks wie Zuul, Spring Cloud Gateway, Kong und NGINX. Die Architekturverwaltung war nicht einheitlich und die Verwaltung war relativ umständlich.

Lösung

Um diese Herausforderungen zu bewältigen, konzentriert sich IGW darauf, die Gateway-Cluster in APISIX umzuwandeln. Da APISIX auf Kubernetes-Clustern bereitgestellt wird, ermöglicht es die einheitliche Verwaltung von APIs durch YAML in einer deklarativen Weise. Darüber hinaus überwacht der APISIX Ingress Controller automatisch Änderungen in Kubernetes-Ressourcen, wodurch die APISIX-Konfigurationen, einschließlich ApisixRoute, SSL und mehr, in Echtzeit synchronisiert werden.

Unten ist das Sequenzdiagramm der Routensynchronisation von IGW nach der Verwendung von APISIX dargestellt.

Nutzungsszenarien

Nach der Verwendung von APISIX erzielte IGW viele Vorteile, wobei das IGW-Team aus geschäftlicher Sicht besonders an intelligentem Routing, Authentifizierung, Observability und Traffic-Kontrolle interessiert ist.

Effizientes intelligentes Routing

Das intelligente Routing zeigt sich hauptsächlich im Lastenausgleich auf Layer 4 und Layer 7. Wie im Diagramm gezeigt, wird die durch den APISIX Ingress Controller synchronisierte Routing-Information von spezifischen Labels begleitet, was versehentliche Löschvorgänge effektiv verhindert.

Nach Tests in der Umgebung kann Kubernetes, selbst wenn Daten gelöscht werden, schnell und automatisch mit APISIX synchronisieren, wodurch das Problem des Datenverlusts gelöst wird.

Darüber hinaus erreichen die Routing-Updates auf APISIX eine Millisekunden-Reaktionszeit, mit nahezu unmerklicher Konfigurationssynchronisationsverzögerung, was eine hervorragende Benutzererfahrung bietet.

Verbesserte Authentifizierung

Vor der Einführung des einheitlichen Gateways musste jede Geschäftseinheit individuell Authentifizierungskomponenten entwickeln, um die Sicherheit ihrer Datenschnittstellen zu gewährleisten. Auf der Geschäftsseite war jedes System mit der Entwicklung redundanter Authentifizierungsfunktionen belastet, was zu höheren Entwicklungskosten und unterschiedlicher Qualität der implementierten Funktionen führte. Daher führte IGW für die Sicherheitsüberprüfung einheitliche Authentifizierung und HTTPS-Umleitungs-Plugins ein.

Vor der Einführung des einheitlichen Gateways wurden HTTPS-Zertifikate für Dienste am High Availability (HA)-Endpunkt entschlüsselt, was die Komplexität, den Betriebsaufwand und die Sicherheitsrisiken erhöhte.

Angesichts dieser Herausforderungen entwickelte das technische Team von IGW einen Plan, um die Authentifizierungsfunktionalität im Gateway zu zentralisieren und damit die oben genannten Probleme zu lösen. Dieser Ansatz verbessert die Forschungs- und Entwicklungseffizienz der Geschäftssysteme erheblich, sodass sich die Entwickler stärker auf die Kernentwicklung des Geschäfts konzentrieren können.

Durch den Wechsel zu APISIX können diese Nachteile gemildert werden. APISIX kann HTTPS-Terminierung handhaben, SSL-Zertifikate dynamisch laden und bietet eine zentrale und sichere Verwaltung für sicherheitsrelevante Aufgaben, was die Gesamtleistung und Flexibilität des Systems verbessert.

Überwachung hinaus

Zuvor beeinträchtigte die schwache Unterstützung für Observability im ursprünglichen Geschäftssystem von IGW die Systemfehlerbehebung, Leistungsoptimierung, Zuverlässigkeit und proaktive Überwachung.

Daher strebte das technische Team von IGW an, schnell mehrere von APISIX bereitgestellte Plugins wie Protokollüberwachung und Tracing zu integrieren, um die Observability-Fähigkeiten zu verbessern.

Darüber hinaus erforschte und nutzte das Team aktiv Apache SkyWalking für verteilte Tracing-Zwecke, Prometheus für Überwachungszwecke und ELK für eine effiziente Protokollsammlung. Überraschenderweise unterstützt APISIX all diese Plugins und hat sich somit als ideale Lösung erwiesen, die die Erwartungen und Anforderungen des technischen Teams von IGW vollständig erfüllt, was es zur bevorzugten Wahl macht.

Das obige Diagramm zeigt die Service-Topologie von IGW, nachdem das technische Team SkyWalking in die Produktion integriert hat. Dieses umfassende Diagramm bietet eine klare und prägnante Visualisierung der Dienstaufrufbeziehungen, einschließlich wichtiger Informationen wie der Verkehrsrichtung durch das Gateway und der Erfolgsraten. Mit diesem Topologie-Diagramm kann das IGW-Team schnell den genauen Ort von Fehlern oder Problemen in der Dienstkette identifizieren.

Beherrschung der Traffic-Kontrolle

APISIX hat sich als effektive Lösung erwiesen, um vielseitige Traffic-Kontrollmechanismen für IGW zu ermöglichen. Durch die Einführung von APISIX hat das technische Team von IGW nahtlos Traffic-Kontrolle durch Canary-Release und gewichtungsbasierte Strategien erreicht. Diese robuste Fähigkeit ermöglicht eine effiziente Verwaltung der Verkehrsverteilung, sodass das Team problemlos Canary-Releases durchführen und Verkehrsgewichte nach Bedarf anpassen kann.

In einem Szenario basierend auf Canary-Release muss das Gateway eine Downstream-Schnittstelle über eine HTTP-Anfrage aufrufen, um spezifische Daten zu erhalten, und basierend auf den zurückgegebenen Ergebnissen beurteilen, ob die Anfrage an die Canary-Release-Umgebung gesendet werden muss.

Basierend auf der Gewichtungsrichtlinie werden die Dienste von virtuellen Maschinen und Containern parallel nach außen bereitgestellt. Zum Beispiel treffen 90% des Traffics den Dienst der virtuellen Maschine und 10% den Cloud-Dienst, um die Stabilität des Cloud-Dienstes zu überprüfen. Derzeit ist die Produktionsumgebung von IGW mit einem gewichtungsbasierten Canary-Release konfiguriert.

Erfolge nach der Verwendung von APISIX

Aufbau eines einheitlichen API-Gateways

Durch die Implementierung von APISIX hat das technische Team von IGW die Standardisierung des API-Gateway-Frameworks erreicht, das reichhaltige Traffic-Management-Funktionen wie Lastenausgleich, dynamisches Upstream, Canary-Release, Circuit Breaking, Authentifizierung und Observability bietet.

IGW hat eine einheitliche Authentifizierungsfunktionalität im Gateway implementiert, wodurch die Probleme redundanter Entwicklungsbemühungen und inkonsistenter Qualität der Funktionen behoben wurden. Dies ermöglichte es den Entwicklern, sich stärker auf die Entwicklung zu konzentrieren, und verbesserte die Forschungs- und Entwicklungseffizienz der Geschäftssysteme erheblich.

Verbesserte Stabilität der Bereitstellung von Routing und Diensten

Routing-Updates auf APISIX sind in der Lage, Millisekunden-Reaktionszeiten zu liefern, was eine schnelle und effiziente Leistung gewährleistet. Darüber hinaus ist die Synchronisation der Konfigurationen nahezu verzögerungsfrei, was zu einer verbesserten Benutzererfahrung führt.

Darüber hinaus hat die Integration von DevOps und Pipelines die Stabilität der Routen- und Dienstbereitstellung erheblich verbessert. Dieser optimierte Ansatz hat die Effizienz der Routing- und Dienstfreigaben gesteigert und sichert zuverlässigere und konsistentere Ergebnisse.

Hot-Reloading verbessert Leistung und Verfügbarkeit

Das technische Team von IGW schätzt die Leistungsfähigkeit von Hot-Reloading sehr. APISIX bietet einen nahtlosen Hot-Deployment-Prozess für das Aktivieren oder Deaktivieren von Plugins, das Hinzufügen benutzerdefinierter Plugins und die dynamische Aktualisierung der Gateway-Parameter.

Dadurch können Änderungen an Plugin-Konfigurationen und Gateway-Einstellungen sofort angewendet werden, ohne dass ein Systemneustart oder Unterbrechungen erforderlich sind. Diese bemerkenswerte Hot-Reloading-Funktion erhöht die Flexibilität und Agilität der APISIX-Plattform erheblich und ermöglicht es Entwicklern, Echtzeit-Anpassungen an ihren Konfigurationen vorzunehmen und das Gateway an ihre spezifischen Anforderungen anzupassen.

Die Hot-Reloading-Fähigkeit von APISIX hat den Druck von Dienstneustarts erheblich verringert. Diese Funktion ermöglicht es, Updates und Änderungen an Diensten anzuwenden, ohne einen vollständigen Neustart zu benötigen, was die Systemleistung verbessert und die Ausfallzeiten reduziert.

Zusammenfassung

Das technische Team von IGW hat auch Erwartungen an die weitere Verbesserung der Funktionalität, Zuverlässigkeit und Leistung von APISIX für einen nahtlosen Betrieb in der Zukunft geäußert.

Die erfolgreiche Implementierung von APISIX bei Invesco Great Wall hat erhebliche Vorteile und positive Ergebnisse gebracht. Mit APISIX hat das IGW-Team ein einheitliches API-Gateway-Framework erreicht, was zu optimierten Abläufen und reduzierten Kosten führte. Die Integration hat auch eine verbesserte Stabilität im Routing und in den Diensten gebracht, was zu einer verbesserten Leistung und minimierten Unterbrechungen führte.

Angesichts der bemerkenswerten Ergebnisse von Invesco Great Wall erweist sich APISIX als eine äußerst effektive API-Gateway-Lösung, die speziell für die Finanzdienstleistungsbranche, einschließlich des Fonds- und Wertpapiersektors, geeignet ist. Diese erfolgreiche Fallstudie ist ein überzeugendes Zeugnis für die Vorteile der Einführung von APISIX in der Finanzbranche und empfiehlt deren Implementierung nachdrücklich an andere Organisationen in der Branche.