Verabschiede dich von Spring Cloud Gateway! Wie die Fintech-App Huanbei Apache APISIX nutzt

Liebe und Hass für Java

Warum bevorzugen Finanzsysteme Java?

Java ist seit seiner Veröffentlichung aufgrund seiner Sprachvorteile und des enormen Ökosystems beliebt und wird von vielen Entwicklern bevorzugt.

In den letzten 15 bis 20 Jahren haben viele Finanzsysteme Java als ihre primäre Technologie-Stack gewählt. Nach einigen Untersuchungen haben wir die folgenden Vorteile von Java zusammengefasst:

Aufgrund der oben genannten Gründe gewinnt Java die Gunst von Finanzsoftware-Systemen.

Der Status Quo von Java in der Cloud-Native-Ära

Mit der rasanten Entwicklung der Technologie wird die Branche die monolithische Architektur bald aufgeben, und Microservices sowie Cloud-Native werden zum Mainstream. In den letzten Jahren hat Java jedoch in einigen Geschäftsszenarien begonnen, seine dominante Rolle zu verlieren.

Erstens hat Java eine schwache Leistung; dies wird deutlich, wenn man Java mit dem C-basierten Tech-Stack vergleicht.

Zweitens läuft Java auf virtuellen Maschinen, und die virtuellen Maschinen übernehmen die Speicherverwaltung von Java. Daher wird Java weniger wettbewerbsfähig, wenn hohe Leistung oder dynamische Änderungen erforderlich sind.

Darüber hinaus benötigt Java viel mehr Ressourcen. Ein Framework ist einfach zu erstellen, ohne sich um die Kosten zu kümmern. Da jedoch die Berechnungen in der Cloud-Native-Ära viel detaillierter und granularer geworden sind, sind Ressourcen wertvoller denn je. Java würde enorme Ressourcen benötigen, um zu laufen, da es schwergewichtig ist und von Zeit zu Zeit neu gestartet werden muss. Infolgedessen würde Java Probleme mit einer hohen Nachfrage nach QPS und Geschäftskontinuität haben.

Last but not least ist auch das Pointer-Problem erwähnenswert. Pointer sind eine gute Ressource für Entwickler, die mit C/C++ vertraut sind. Da Java jedoch auf einer virtuellen Maschine läuft, wird die Speicherverwaltung vom GC (Garbage Collection) und nicht von den Entwicklern übernommen. In diesem Fall könnte die Leistung von Java in einigen Situationen, in denen eine strikte Anforderung an hohe Parallelität, Verkehr und Leistung besteht, nicht ausreichen.

Warum hat HuanBei APISIX gewählt?

Shuhe Group ist eine Finanztechnologieplattform, die Unternehmen und Einzelpersonen effiziente, intelligente Dienstleistungen im Geschäftsbereich bietet; sie hat Produkte wie HuanBei, EnjoyPay usw. HuanBei ist eine Plattform, die einen Ratenzahlungsservice anbietet, der mehrere Verbrauchsszenarien bedient. Durch die Zusammenarbeit mit lizenzierten Finanzinstituten bietet HuanBei auch persönliche Darlehensdienste an und stellt Startkapital für Darlehen bereit. HuanBei verwendet immer einen Java-Tech-Stack, um seine Produkte im Geschäftsbereich zu entwickeln.

Spring Cloud Gateway ist ein Gateway, das darauf abzielt, Microservices im Spring Cloud-Ökosystem besser zu verwalten. Spring Cloud Gateway ist ein anständiges API-Gateway für Unternehmen, die Java als ihre primäre Entwicklungssprache verwenden. Bei der jüngsten API-Gateway-Aktualisierung hat HuanBei jedoch das langjährig verwendete Spring Cloud Gateway aufgegeben und begonnen, Apache APISIX zu verwenden.

Architekturunterschiede zwischen Spring Cloud Gateway & APISIX

HuanBei verwendete vor der Anpassung von APISIX drei verschiedene API-Gateway-Systeme. HuanBei verwendete Spring Cloud Gateway als Gateway für seine Betriebs- und Ausstiegssysteme und OpenResty als Gateway für sein Geschäftssystem.

HuanBei verwendete Spring Cloud Gateway zunächst als Gateway für seine Betriebs- und Ausstiegssysteme, da Spring Cloud Gateway ein enormes Ökosystem und ein einfach zu implementierendes und zu wartendes verteiltes Entwicklungssystem bietet. Um Geschäftsmodelle schnell aufzubauen, verwendete HuanBei alle von Spring Cloud bereitgestellten Dienste, als die Geschäftsgrundlage geschaffen wurde.

Mit der Entwicklung des Geschäfts begann das Gateway in der ursprünglichen Architektur einige Stabilitätsprobleme zu haben, wie Speicherüberlauf, hohe CPU-Auslastung usw. Daher verwendet HuanBei Apache APISIX als das einzige Gateway in der Architektur, um die Gateway-Leistung zu verbessern und mehrere Gateways einheitlich zu verwalten.

Im neuen Gateway-Framework würde das Gateway den Anforderungsverkehr direkt über die Dienstermittlung an das Geschäftssystem weiterleiten. Wenn jedoch die Backend-Anwendung die Dienstermittlung nicht unterstützt oder kein gesunder Pod im Consul vorhanden ist, wird der Verkehr an das vorherige interne K8s Ingress weitergeleitet.

Die praktische Anwendung von APISIX

HuanBei muss die APISIX-Konfiguration in realen Geschäftsszenarien anpassen, da es Apache APISIX aufgrund seiner mehreren internen Gateway-Frameworks nicht direkt verwenden konnte.

APISIX-Build & -Bereitstellung

Während der internen Entwicklung hat HuanBei die Quellcodes des APISIX-Gateways und benutzerdefinierte Codes in verschiedenen Routenpfaden platziert und sie unabhängig voneinander kooperieren und iterieren lassen. HuanBei verwendete ein Docker-Image, um das Gateway bereitzustellen. Zuerst wurde ein Standard-Image basierend auf einer bestimmten Version von APISIX erstellt, und dann wurden benutzerdefinierte Codes verwendet, um es in ein neues Image zu verpacken.

Die Verpackung der benutzerdefinierten Codes verwendete nicht lua_package_path, um das Code-Verzeichnis anzugeben; stattdessen wurde das Standard-Image apisix im Quellcode-Verzeichnis direkt überschrieben, wenn eine Datei mit demselben Namen vorhanden war. Das Dockerfile ist unten dargestellt:

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/*

APISIX-Protokolle werden lokal gespeichert (können von Syslog oder anderen Plugins gesammelt werden); wir können die NGINX-Konfigurationsvorlage ändern und das verwendete Profil überprüfen, um zu entscheiden, ob wir die Protokolle lokal speichern oder sie über Syslog in FLUENTD speichern möchten. Wir müssen auch die FLUENTD_HOST-Variable beim Erstellen der Images ersetzen, wie unten gezeigt:

{% **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%}

In der NGINX-Konfigurationsvorlage hat HuanBei nicht nur die Protokollspeicherung geändert, sondern auch ENV-Umgebungsvariablen und lua_shared_dicts-Konfigurationen in Schleifen hinzugefügt und einige NGINX-Optimierungsparameter festgelegt.

HuanBei trennt den Verkehr basierend auf verschiedenen Geschäftsanforderungen und erstellt mehrere Gateways mit ähnlichen Funktionen. Daher verwendet HuanBei intern einen „Single-Source-Code, aber mehrere Gateway-Anwendungen“-Plan. Zuerst konfiguriert HuanBei die config-xxx.yaml-Datei jedes Gateways mithilfe der Profilfunktion, und dann kann es die Docker-Images der verschiedenen Gateways basierend auf dem Anwendungsnamen erstellen, während die Images über die DevOps-Plattform erstellt werden.

Unternehmensspezifische benutzerdefinierte Plugins

Beim internen Besuch des Betriebssystems ruft das System viele Backend-APIs auf, um Daten abzurufen, und diese APIs müssen in der Whitelist der API-Gateway-Konfiguration enthalten sein. Das Berechtigungssystem sollte eine entsprechende API-Liste pflegen, da die Seite basierend auf der Rolle jedes angemeldeten Benutzers im Betriebssystem unterschiedliche API-Bereiche anbietet. Immer wenn ein neuer API-Aufruf von der Seite kommt, müssen Entwickler die Konfiguration zweimal im Gateway und im Berechtigungssystem hinzufügen, was redundant und repetitiv ist.

Um dies zu erreichen, entfernt HuanBei die Barriere zwischen der Gateway-Konfiguration und der Konfiguration des Berechtigungssystems und behält nur den Eingang des Berechtigungssystems bei. Das Gateway-Konfigurationsmanagementsystem ruft die Berechtigungs-API periodisch ab und schaltet sie dann auf die Whitelist-Konfiguration des Gateways um. Dieses Verhalten lässt eine unnötige Benutzerkonfigurationsaktion weg und hilft dem Berechtigungssystem, die Berechtigungskontrolle durchzuführen. Darüber hinaus stellt es sicher, dass die im Betriebssystem aufgerufene Backend-API in der Konfiguration des Berechtigungssystems vorhanden ist.

In Geschäftsszenarien gibt es immer einige Anforderungen, die native Plugins nicht erfüllen können, was eine benutzerdefinierte Entwicklung erfordert. APISIX bietet viele Tools, die die Anpassung der nativen Plugins erleichtern. Die folgende Tabelle listet einige der in HuanBei basierend auf APISIX entwickelten benutzerdefinierten Plugins auf:

Canary-Release des Gateways

Zuvor verwendete HuanBei OpenShift als seine K8s-Container (es wurde derzeit auf den ACK-Cluster aktualisiert), und das Ingress wurde mit Haproxy erstellt.

Da der öffentliche Netzwerk-K8s-Ingress-Haproxy den Verkehr einer einzelnen Domain nicht in zwei verschiedene Namespace-Routenpfade aufteilen konnte, müssen wir die Bereitstellung des neuen Gateways im selben Namespace wie das alte Gateway in Betracht ziehen. Mit anderen Worten, jeder Domain-Routenpfad hätte mehrere Dienste, und wir könnten den Verkehr des neuen und alten Gateways steuern, indem wir unterschiedliche Anteile des Gesamtverkehrs zuweisen.

Der tatsächliche Implementierungsfluss ist unten dargestellt, es würde Gruppen c und d hinzufügen, um ein neues Gateway unter dem Namespace des alten Gateways bereitzustellen, und es könnte den Verkehrsanteil des neuen und alten Gateways steuern.

Gateway-Faktoren im Zusammenhang mit Java

Viele Java-Entwickler würden Spring Cloud in der Microservice-Architektur wählen, da Spring Cloud Java nahtlos unterstützt und Klassenbibliotheken in den Quellcode einbettet. In der Praxis treten jedoch schwierige Upgradesituationen auf. Zum Beispiel, wenn das Team mehrere Klassenbibliotheken pflegen muss und es 10 verschiedene Sprachen mit 10 verschiedenen Versionen gibt, dann muss dieses Team 100 verschiedene Klassenbibliotheken pflegen.

Jetzt können wir leicht einen Proxy (API-Gateway) verwenden, um Multi-Version- und Multi-Sprachen-Probleme zu lösen. Was sind also die Vorteile für Unternehmen, die einen Java-Tech-Stack verwenden und APISIX als ihr API-Gateway wählen? Wir schließen basierend auf zwei Aspekten aus der praktischen Erfahrung von HuanBei.

Für das Unternehmen

1. Große Funktionalität & Leistung

APISIXs QPS könnte 80k erreichen, wenn HuanBei 4-Kern-VMs ohne Plugins verwendet, um APISIX zu stressen. Darüber hinaus löst APISIX das Leistungsproblem von Spring Cloud Gateway perfekt, wenn es den Verbraucherverkehr empfängt, und seine Leistung verbessert sich in der Produktionsumgebung um 30% im Vergleich zu vorherigen Gateways.

Abgesehen davon kann APISIX alle Unternehmensanforderungen unter den tatsächlichen Tests erfüllen, wie Authentifizierung und Identifikation, Beobachtbarkeit, Dienstermittlung, Ratenbegrenzung und vier- und siebenschichtigen Verkehrstransfer. In Bezug auf die Funktionserweiterung unterstützt APISIX mehr als 70 Plugins, und die meisten Unternehmen können seine nativen Plugins verwenden, was eine enorme Menge an Entwicklungsarbeit reduziert.

2. Reduzierung der Geschäftskosten

Vor der Verwendung von APISIX mussten Unternehmen die Anzahl der Server erhöhen, um Leistungsprobleme zu lösen, was die Hardwarekosten erheblich erhöhte.

HuanBei hat die Kosten berechnet und festgestellt, dass die Serverkosten nach der Verwendung von APISIX um etwa 60% gesunken sind. Darüber hinaus kann das Geschäft nach der Vereinheitlichung des Tech-Stacks verschiedene Funktionen schnell basierend auf der nativen Architektur von APISIX erweitern, die Entwicklungskosten reduzieren und die Produktveröffentlichungszeit beschleunigen.

Für Entwickler

1. Erfüllung der Geschäftsanforderungen

Alle im Geschäft verwendeten Software oder Technologie sollten den Anforderungen dienen. Aus den praktischen Test- und Forschungsergebnissen hat APISIX jedoch eine bessere Stabilität, Beobachtbarkeit und Erweiterbarkeit.

Die Software soll dem Geschäft dienen. Daher, wenn eine Geschäftsanforderung dem Unternehmen helfen kann, Ressourcen zu sparen, sollte das Unternehmen unabhängig vom verwendeten Tech-Stack auch die Komponenten verwenden, die dem Unternehmen entsprechen.

2. Reduzierung der Wartungskosten

Im Vergleich zu dem zuvor verwendeten OpenResty hat APISIX geringere Lernkosten und ist einfacher zu warten. Gleichzeitig vereinfachen die reichhaltigen Plugins von APISIX die Bereitstellung und Entwicklung einiger Standardfunktionen, was die Produktveröffentlichungszeit reduziert.

Gleichzeitig helfen die leistungsstarken Protokolle und die dynamische Debugging-Funktion von APISIX, die Fehlerpunkte im Geschäft zu erkennen, so dass wir den Fehler schnell lokalisieren und Zeit sparen können.

Fazit: Trends der Finanzbranchenentwicklung

In der brutalen Wachstumsphase ist Effizienz das Einzige, was zählt. Daher bevorzugen Direktoren ihre vertraute Sprache, um das System aufzubauen, und wählen während der Auswahl des Low-Level-Frameworks verschiedene Tech-Stacks, um die Geschäftsmodelle schneller zu starten. Unterschiedliche Direktoren würden unterschiedliche Tech-Stacks wählen, was viele zukünftige Probleme verursachen würde. Die meisten aktiven Finanzunternehmen und Finanzdienstleistungsunternehmen würden jedoch dasselbe technische Problem haben: das Multi-Tech-Stacks-Problem. Wenn dieses Problem auftritt, müssen sie ihre Tech-Stacks in einen kombinieren.

Wenn das Unternehmensgeschäft auf dem richtigen Weg läuft, ist es an der Zeit, dass das Unternehmen sein System vertikal aufteilt. Das Unternehmen muss seine Informationssilo-Architektur in eine dreischichtige Architektur bestehend aus Frontend, Middle-End und Backend umwandeln. Wenn das System dann stabil läuft, ist es an der Zeit, dass Unternehmen Low-Level-Komponenten selbst implementieren.

Das ultimative Ziel des Systemaufbaus ist die gemeinsame Nutzung. Das System hat geringere Wartungskosten, wenn es eine bessere Wiederholbarkeit hat. Daher beginnen viele Unternehmen, wenn sich der Geschäftsbetrieb stabilisiert, mit der vertikalen Aufteilung oder der Implementierung der Low-Level-Grundkomponenten, um die Wartungskosten zu kontrollieren.

Für Unternehmen sind die Kosten immer das wichtigste Prinzip, das zu berücksichtigen ist. In der brutalen Wachstumsphase müssen Unternehmen nur starten und das Geschäft so schnell wie möglich betreiben lassen. Unter dem Budget in dieser großen Umgebung sollten die Kosten jedoch die höchste Priorität haben. In diesem Fall müssen wir zwischen Effizienz und Kosten wählen. Daher würden Unternehmen keine Spitzentechnologie verwenden, wenn das Budget begrenzt ist. Ebenso würden technische Mitarbeiter bei der Auswahl des Tech-Stacks nicht die folgenden Fragen berücksichtigen: Wie würde diese neue Technologie das Team beeinflussen? Wie viele Vorteile könnte diese neue Technologie der aktuellen Infrastruktur bringen?

Technische Mitarbeiter würden nur die Kosten dieser neuen Technologie berücksichtigen.