Snowball Finance transformiert seine Active-Active-Architektur mit APISIX

Wenjie Shi, Senior Development Engineer des Infrastrukturteams bei Snowball Finance, hat die Praxis von Snowball Finance mit APISIX auf dem Apache APISIX Summit ASIA 2022 vorgestellt. Dieser Artikel basiert auf dem Vortrag und beschreibt, wie Snowball Finance Apache APISIX nutzt, um die Entwicklung seiner internen Active-Active-Architektur zu erreichen und damit ein flexibleres Dienstemanagement zu ermöglichen.

Herausforderungen

• Komplexe SDK-Authentifizierungsmodule erhöhen die Systemkomplexität und Sicherheitsrisiken, wenn das Benutzerzentrum aufgrund der Active-Active-Architektur, die nur im Marktdienstmodul verfügbar ist, regionsübergreifend aufgerufen wird.
• OpenResty verfügt über kein robustes Überwachungssystem für Beobachtbarkeit und benötigt angepasste Skripte, um Skalierbarkeit zu erreichen, was zu höheren Entwicklungs- und Betriebskosten führt.
• Ein unvollständiges NGINX-Registry-Center ohne Herzschlagmechanismus verringert die Verfügbarkeit und Stabilität, wodurch Systemausfälle nicht rechtzeitig behoben werden können.

Ziele

• Minimierung von Änderungen ohne Einführung zu vieler Variablen bei gleichzeitiger Wahrung der Transparenz für Geschäftsgruppen.
• Einheitliche Problembehandlung auf Infrastrukturebene und Bestreben, Authentifizierungsdienste innerhalb des lokalen Rechenzentrums abzuschließen.

Ergebnisse

• Implementierung der einheitlichen Authentifizierung, Unterbrechungsschutz und Ratenbegrenzung auf der Gateway-Ebene, wodurch die Systemkopplung reduziert und die Dienstqualität in Szenarien mit zwei Rechenzentren verbessert wird.
• Etablierung einer einheitlichen Überwachungslösung vom Gateway bis zur Dienstebene unter Nutzung des APISIX-Überwachungssystems und Bereitstellung einer hervorragenden Unterstützung für die globale Fehlerbehebung.
• Bereitstellung einer eleganten Implementierungsmethode für die gRPC-Protokollumwandlung und Dienstverwaltung.

Hintergrund

Snowball Finance wurde 2010 als Investment-Community gegründet und ist heute eine führende Online-Finanzmanagementplattform in China, die Anlegern verschiedene Dienstleistungen wie hochwertige Inhalte, Echtzeit-Marktdienste, Handelswerkzeuge und Vermögensverwaltung bietet.

Unter diesen Dienstleistungen ist der Echtzeit-Marktdienst mit mehreren Upstream-Datenquellen verbunden und bietet Anlegern stabile Datenleistungen durch Datenstreaming, Speicherung und Verteilung. Daher sind Echtzeit-Marktdienste seit jeher ein großer Ressourcenverbraucher im System von Snowball Finance.

Folglich ist eine wichtige Aufgabe innerhalb von Snowball Finance die kontinuierliche Verbesserung der Stabilität, einschließlich der Leistungsoptimierung der Marktdienste. Dennoch können während der Spitzenverkehrszeiten einige Systeme aufgrund eines Datenanstiegs langsam reagieren oder sogar ausfallen, was die Benutzererfahrung beeinträchtigt.

Vor diesem Hintergrund hat Snowball Finance einen Plan zur Active-Active-Transformation von Diensten gestartet, um Anlegern stabile und hochwertige Dienstleistungen zu bieten, wobei Apache APISIX die Implementierung erheblich vereinfacht. Darüber hinaus bietet APISIX als Cloud-natives API-Gateway eine aktive Community und ein reiches Ökosystem, das mehrere Plugins unterstützt. Diese Vorteile bieten auch eine gute Grundlage für die Entwicklung der Cloud-nativen Architektur von Snowball Finance.

Schmerzpunkte der Active-Active-Transformation

Zu der Zeit, als die Standalone-Architektur verwendet wurde, gelangte der Benutzerverkehr über den Server Load Balancer (SLB) in das System, durchlief das Gateway für einfache gemeinsame Logikverarbeitung und wurde dann an den Backend-Dienst weitergeleitet. Der Backend-Dienst initiierte über ein integriertes Authentifizierungsmodul eine Benutzerauthentifizierung beim Snowball User Center mithilfe eines SDKs und setzte die weitere Verarbeitung nach erfolgreicher Authentifizierung fort.

In praktischen Geschäftsszenarien haben sich einige Schmerzpunkte allmählich herauskristallisiert.

1. Komplexe SDK-Authentifizierungsmodule

Bei der Implementierung der Active-Active-Transformation können Anbieter und Verbraucher von Microservices nicht synchron bereitgestellt und gestartet werden. Als der Marktdienst von Snowball Finance erstmals in der Cloud gestartet wurde, das Benutzerzentrum jedoch noch nicht in der Cloud unterstützt wurde, kam es zu datenzentrumsübergreifenden Aufrufen. Laut Statistiken des Benutzerzentrums erreichte sein RPC-Aufruf täglich rund zehn Milliarden, und das Spitzenvolumen kann 50.000 QPS erreichen, was zu höheren Latenzen führen kann.

Gleichzeitig war die Authentifizierungslogik von Snowball Finance komplex. Neben den OAuth2.0/JWT-Protokollen mussten viele Faktoren berücksichtigt werden, wie z.B. die Client-Versionen und mehrere APPs unter Snowball Finance. Darüber hinaus war das Authentifizierungsmodul in den Dienst eingebettet, was die Aktualisierung erschwerte.

2. Begrenzte Funktionalität von OpenResty

Snowball Finance verwendete zuvor OpenResty als Gateway, aber OpenResty war in einigen Funktionen schwach. Daher müssen Entwickler bei der Integration von OpenResty in das bestehende Überwachungssystem mehr Anpassungen vornehmen. Darüber hinaus mussten DevOps-Ingenieure benutzerdefinierte Skripte hinzufügen, um den Zweitentwicklungsprozess zu implementieren.

3. Abhängigkeit von selbstentwickeltem Registry-Center

Derzeit führt Snowball Finance die HTTP-Dienstregistrierung durch, indem beim Start des Backend-Dienstes eine Anfrage an das Registry-Center gesendet wird, um ihn beim Gateway zu registrieren, und beim Stopp des Dienstes der Dienstknoten entfernt wird. Das Registry-Center führt regelmäßige Gesundheitsprüfungen der Dienstknoten durch. Im Vergleich zu Open-Source-Projekten sind die Wartungskosten für selbstentwickelte Dienste jedoch höher.

API-Gateway-Technologieauswahl

Basierend auf den in Geschäftspraxis-Szenarien allmählich aufgedeckten Schmerzpunkten hat das Infrastrukturteam von Snowball mit der Forschung zu Gateway-Produkten begonnen.

Das Team hofft intern, sowohl die Geschäftstransparenz zu gewährleisten als auch Änderungen zu minimieren, ohne zu viele Variablen einzuführen. Das Team möchte auch Probleme einheitlich auf Infrastrukturebene lösen und Authentifizierungsdienste innerhalb des lokalen Rechenzentrums abschließen. Unter Berücksichtigung der oben genannten Punkte hat sich Snowball Finance entschieden, den Authentifizierungsdienst auf das API-Gateway zu verlagern.

Snowball Finance hofft, dass das neue API-Gateway die folgenden Anforderungen erfüllen kann:

• Hohe Leistung
• Starke Skalierbarkeit
• Unterstützung mehrerer Protokolle
• Geringe Kosten für die Gateway-Authentifizierung

Nachfolgend finden Sie eine detaillierte Liste der API-Gateway-Technologieauswahl unter OpenResty, Spring Gateway, Kong und APISIX.

Gateway	Vorteile	Nachteile	O&M-Kosten	Verfügbarkeit
OpenResty	Hochgradig anpassbar und stabil	Schlechte Beobachtbarkeit	Hoch	Hoch
Spring Gateway	Freundlich für Java-Entwicklung	Das Leistungsniveau entspricht nicht den Anforderungen	Mittel	Mittel
Kong	Leistungsstark und reich an Funktionen	PostgreSQL-Einzelpunkt-Datenbank	Niedrig	Mittel
APISIX	Cloud-nativ, unterstützt mehrere Programmiersprachen und hat eine starke Skalierbarkeit	/	Niedrig	Hoch

Nach der Berücksichtigung interner Anforderungen und dem Vergleich beliebter Gateway-Produkte auf dem Markt hat sich Snowball Finance schließlich für Apache APISIX für die nachfolgende Architektur entschieden.

Praxis basierend auf Apache APISIX

Angepasste Architektur

Wie in der obigen Abbildung dargestellt, wird die aktuelle Active-Active-Architektur der Snowball-Marktdienste auf der linken Seite angezeigt, die der Architektur im ursprünglichen Rechenzentrum mit wenigen Änderungen entspricht. Die rechte Seite zeigt die Active-Active-Architektur basierend auf einem Multi-Region-Design nach der Migration in die Cloud.

Snowball Finance hat basierend auf APISIX hauptsächlich die folgenden Anpassungen vorgenommen:

• Vereinheitlichung des Authentifizierungsmoduls auf die Proxy-Ebene und Verwendung von APISIX für die einheitliche Authentifizierung. Für JWT-Typen kann das jwt-auth-Plugin von APISIX direkt für die lokale Authentifizierung verwendet werden.
• Kompatibilität mit OAuth 2.0 und Nutzung von APISIX, um das Snowball Finance User Center für die Verarbeitung aufzurufen.
• Verbindung mit dem Snowball Finance Backend RPC Service Registry Center, um dessen Backend-Dienste zur Authentifizierung zu verwenden, wenn die JWT-Authentifizierung fehlschlägt.

Anwendungsszenarien

Nachdem der Backend-Dienst mit APISIX verbunden wurde, wurden einige Praktiken hauptsächlich in den Bereichen Gateway-Authentifizierung und Beobachtbarkeit durchgeführt.

Szenario 1: Gateway-Authentifizierung

Wie bereits erwähnt, hatte die vorherige Architektur von Snowball Finance keine einheitliche Authentifizierungsmethode. Eine Methode stützte sich auf die interne Anwendungsseite, die ein SDK verwendete, um das Benutzerzentrum für die Authentifizierung aufzurufen, während die andere JWT-Authentifizierung verwendete. Als diese beiden Authentifizierungsmethoden nebeneinander existierten, führte dies zu Problemen mit der Skalierbarkeit und Wartbarkeit.

1. Nach der Integration von APISIX als Gateway verwendete Snowball Finance die APISIX-Gateway-Ebene, um die Authentifizierung einheitlich zu verwalten. Die ursprüngliche JWT-Authentifizierungsmethode wurde durch das offizielle Plugin jwt-auth ersetzt. Die Konfiguration und Verwendung des jwt-auth-Plugins ist relativ einfach: Nur durch die einfache Konfiguration der relevanten Informationen wie Routen und Upstream im Dashboard wird das Plugin aktiviert.
2. Snowball Finance verwendete das grpc-transcode-Plugin, um die Authentifizierungsdienstaufrufe zu proxen, um die vorherige OAuth 2.0-bezogene Authentifizierungsmethode zu handhaben.

Snowball Finance hat intern die folgenden drei Lösungen in Betracht gezogen, um gRPC für die Implementierung der Authentifizierung aufzurufen:

• Lösung 1: Direkter Aufruf von gRPC mit Lua. Da diese Lösung die Berücksichtigung verwandter Implementierungen wie Lastenausgleich und dynamischer Upstream erfordert, wird der Prozess schwieriger, daher wurde sie verworfen.
• Lösung 2: Verwendung von Lua-Coroutine, um Golang-Logik zurückzurufen. Snowball Finance hat diesen Weg aufgrund mangelnder praktischer Erfahrung verworfen.
• Lösung 3: Verwendung von Lua für HTTP-Aufrufe, und die gRPC-Schnittstelle wird mit dem grpc-transcode-Plugin von APISIX implementiert. Dank der schnellen Plugin-Optimierungsiterationen der APISIX-Community hat sich Snowball Finance schließlich für diese Option entschieden, um gRPC-Aufrufe zu implementieren.

Derzeit ist eine manuelle Synchronisierung der Protobuffer-Dateien während der Ausführung erforderlich. Dies liegt daran, dass, wenn das Benutzerzentrum die Protobuffer-Datei ändert, die nicht mit der von APISIX gespeicherten Version übereinstimmt, dies zu Authentifizierungsproblemen führen kann.

Szenario 2: Mehrdimensionale Überwachung unter Beobachtbarkeit

Es ist notwendig, viele Metriken nach dem Start der Websites in Snowball Finance zu überwachen, wobei der Schwerpunkt hauptsächlich auf den folgenden drei Teilen liegt:

• NGINX-Verbindungsstatus und ein-/ausgehender Datenverkehr
• HTTP-Fehlerstatuscode-Rate (verwendet zur Fehlerbehebung bei Dienst- oder Upstream/Downstream-Problemen)
• APISIX-Anfragelatenz (die Zeit, die für die Logikausführung verbraucht wird, wenn APISIX die Anfrage weiterleitet)

Beispielsweise erscheint in einigen Fällen die Latenz von APISIX hoch (wie in der folgenden Abbildung gezeigt), was mit der Berechnungslogik der Latenz zusammenhängt. Derzeit ist die Logik die Zeit, die für eine einzelne HTTP-Anfrage auf NGINX verbraucht wird, abzüglich der Latenz, die diese Anfrage für das Routing zum Upstream benötigt. Die Differenz zwischen den beiden Zeitverbräuchen ist die APISIX-Latenzmetrik.

Nach der Verwendung von APISIX führt das Hinzufügen oder Ändern einiger Plugins zu einigen Logikänderungen, was zu Abweichungen in den latenzbezogenen Daten führen kann. Um die Authentizität der Daten nicht zu verfälschen, hat Snowball Finance auch ein Latenzüberwachungs-Plugin hinzugefügt. Während die Genauigkeit jeder Datenüberwachung gewährleistet wird, ist es auch bequem, potenzielle Probleme im Voraus zu lokalisieren, um die Fehlerbehebung zu erleichtern.

Es ist auch möglich, die Beobachtbarkeitsfähigkeiten von APISIX zu nutzen, um Access-Logs zu sammeln und sie in einem formatierten und standardisierten Format an das Verkehrs-Dashboard zu liefern, um sie anzuzeigen und zusammenzufassen. Dies erleichtert ein proaktives Verständnis der Gesamttrends aus mehreren Perspektiven, um potenzielle Probleme zu identifizieren und sie rechtzeitig zu beheben.

Szenario 3: Skalierung des ZooKeeper-Registry

In Snowball Finance werden gRPC-Aufrufe basierend auf der Zookeeper-Registry registriert und entdeckt. Bei der Implementierung der Authentifizierung muss das API-Gateway, wenn die lokale JWT-Überprüfung fehlschlägt, auf den gRPC-Dienst im Snowball Finance User Center zugreifen, um die Authentifizierung durchzuführen, was erfordert, dass das API-Gateway die Backend-gRPC-Dienstadressliste aus dem Registry-Center abruft.

Das offizielle APISIX-Plugin apisix-seed kann ZooKeeper für die Dienstentdeckung integrieren. Snowball Finance hat einige Anpassungen vorgenommen, die spezifischer für das eigene Geschäft sind.

Die spezifische Implementierung erfolgt hauptsächlich auf einem Inhaltsknoten von APISIX. Wenn der Worker-Prozess startet, fragt er den ZK-Rest-Cluster wie den in der folgenden Abbildung gezeigten ab und zieht dann regelmäßig die Quelldaten und Informationen des gesamten Dienstes und aktualisiert sie in den lokalen Cache des Worker-Prozesses, um die Dienstlisten zu aktualisieren.

Wie aus der obigen Abbildung ersichtlich ist, greift der ZK-Rest-Cluster in Form von Rest auf ZooKeeper-Daten zu. Nur durch das Hinzufügen einer Instanz davon können Hochverfügbarkeitsfunktionen erreicht werden, wodurch einige komplizierte Operationen entfallen. Diese Operation bringt jedoch auch einen deutlichen Nachteil mit sich. Wenn der ZK-Rest-Cluster regelmäßig abgefragt wird, kann dies zu einer Verzögerung bei der Aktualisierung der Dienstliste führen.

Zusammenfassung und Ausblick

Derzeit läuft Apache APISIX als Gateway-Ebene innerhalb von Snowball Finance gut. Insbesondere:

• Einheitliche Authentifizierung, Unterbrechungsschutz und Ratenbegrenzung werden auf der Gateway-Ebene implementiert, wodurch die Kopplung des Gesamtsystems reduziert und die Dienstqualität unter zwei Rechenzentren verbessert wird.
• Mit Hilfe der APISIX-Überwachung wird eine einheitliche Überwachungslösung vom Gateway bis zum Dienst etabliert, die eine gute Unterstützung für die globale Fehlerbehebung bietet.
• Eine elegante Implementierungsmethode wird für die Umwandlung und Dienstverwaltung des gRPC-Protokolls bereitgestellt.

In der nachfolgenden Nutzung plant Snowball Finance auch:

• Die Anwendung des APISIX Ingress Controller auf den K8s-Cluster.
• Die Verwendung des grpc-transcode-Plugins für die HTTP/gRPC-Protokollumwandlung, um ein einheitliches Backend-Interface zu erreichen.
• Die Verwendung des traffic-split-Plugins für die Verkehrskennzeichnung, die Verbindung zum Nacos-Registry-Center und die Implementierung von Canary-Release und anderen Dienstgovernance-Maßnahmen.

In den nachfolgenden Plänen wird Apache APISIX verwendet, um das bestehende OpenResty zu ersetzen und schließlich das Management des gesamten Lebenszyklus des Nord-Süd-Verkehrs zu erreichen.