Architekturpraxis von APISIX auf der nativen Junrun Human Cloud-Plattform

Dozent: Yuan Peng, Onepage Technology Architect

Zusammenfassung: Junrun Human Resources verwendet mehrere Sätze von Apache APISIX-Clustern, um die funktionalen Anforderungen der selbst entwickelten Serviceplattform zu erfüllen.

Junrun Human Resources wurde 2019 gegründet und ist ein technologieorientierter Dienstleister für Personallösungen, der sich auf branchenführende Technologie- und Servicekapazitäten stützt und sich darauf konzentriert, Kunden Personaldienstleistungen aus einer Hand anzubieten. Dutzende von Personaldienstleistungsplattformen selbst entwickelt, B-End-Unternehmen und C-Endbenutzer eng miteinander verbunden und ein digitales Ökosystem für Personaldienstleistung aufgebaut.

Dieser Artikel beginnt vor dem Hintergrund der rasanten Expansion des Personalgeschäfts von Junrun und konzentriert sich auf die Unterstützung des Open-Source-API-Gateways Apache APISIX für seine selbst entwickelte Plattformsystemarchitektur in einer Vielzahl von Anwendungsszenarien, die Unternehmen oder Benutzern hilfreich sind.

Überblick über die vom Menschen selbst entwickelte Systemarchitektur von Junrun

Wenn Junrun Human Resources eine selbst entwickelte Serviceplattform-Architektur aufbaut, lautet das erste Prinzip **„Open, Open Source, Cloud Native“**. Die Plattform baut ein Cloud-System basierend auf der Kubernetes-Microservice-Architektur auf, und die Gesamtarchitektur bezieht sich auf die folgende Abbildung.

Auf der rechten Seite ist die selbst entwickelte Dienstplattform von Junrun zu sehen. Der DevOps-Prozess stützt sich auf Git-Webhook, Codierung und Kubernetes-Cluster, um eine vollständige Automatisierung und eine nicht-induktive Freigabe zu erreichen. Das Geschäftssystem wird iterativ auf der Grundlage der PaaS-Plattform entwickelt, um die F&E-Spezifikationen sicherzustellen und einen einheitlichen Technologie-Stack zu erreichen. Die obere Seite stellt die Überwachungsmethode dar. Das System integriert sky-agent und arthas, was den multidimensionalen Anforderungen der Online-Service-Beobachtung gerecht wird. Gleichzeitig wird die Kombination aus Tencent Log Cloud und Kubernetes verwendet, um Dienstprotokolle in der Cloud zu speichern, dateilose Dienste im Kubernetes-Cluster zu realisieren und die Akkumulation von Festplattenkapazität zu vermeiden, die den Zustand eines einzelnen Knotens des Kubernetes-Clusters beeinträchtigt .

Auf der linken Seite befindet sich das wichtigste Glied im Geschäftssystem - das Verkehrsmanagement. Der gesamte Datenverkehr gelangt über WAF (WAF, Web Application Firewall, zuständig für die Netzwerksicherheit) in die erste Schicht CLB des dreistufigen Netzwerks, die hauptsächlich für die Weiterleitung des Datenverkehrs zuständig ist; die zweite Schicht ist das Cloud-native Gateway APISIX, das dies übernimmt internes Dienstmanagement des Geschäftssystems Die dritte Schicht ist das interne Gateway der Gateway-Anwendung des Geschäftssystems, das für die Einzelsystemauthentifizierung und das Routing verantwortlich ist.

Unter ihnen sind besonders der CLB der ersten Schicht und der APISIX der zweiten Schicht wichtig, sie stellen die Eingänge aller Systeme dar. Sobald ein Problem auftritt, sind alle Systeme nicht mehr erreichbar. CLB verwendet Tencent Cloud Service, der eine hohe Stabilität, Skalierbarkeit und Anti-Parallelitätsleistung aufweist.Die Geschäftsarchitektur muss das Cloud-native Gateway APISIX der zweiten Ebene lösen, um seine hohe Verfügbarkeit sicherzustellen.

Der APISIX-Service wird innerhalb des Kubernetes-Clusters bereitgestellt. Der Kubernetes-Cluster nutzt die von Tencent Cloud bereitgestellten Dienste. Um eine schnelle Wiederherstellung nach Auftreten eines Problems zu gewährleisten, verfügt das System über einen etcd-Cluster, der außerhalb des Systems installiert ist, um Daten zu erhalten. Dies ist eine Manifestation der Hochverfügbarkeit des APISIX-Clusters. .

Wie kann man also die hohe Parallelität und hohe Leistung von APISIX sicherstellen? Das System verwendet hier den Mechanismus von Kubernetes. Wenn APISIX das Routing und die Weiterleitung durchführt, verwendet es den Dienstnamen + den Dienstport von Kubernetes, um in dasselbe Netzwerksegment zu springen, da der Gateway-Dienst innerhalb von Kubernetes bereitgestellt wird und sich auf die Eigenschaften von stützt Kubernetes kann ein fortlaufendes Upgrade durchführen und dann die Non-Sensing-Version des APISIX-Gateway-Upgrades erreichen.

Aus diesem Architekturdiagramm ist es nicht schwer zu erkennen, dass die zweite Ebene der Eingang für den gesamten Datenverkehr ist. Die Wahl eines Cloud-nativen Gateways, das die Anforderungen der Geschäftserweiterung erfüllt, ist für die Systemarchitektur sehr wichtig. Lassen Sie uns über die wichtigsten Überlegungen sprechen, wann Gateway-Technologie auswählen.

Schmerzpunkte bei der Auswahl von Technologie-Gateways

Eine große Anzahl von Geschäftssystemen. Derzeit gibt es im Bereich Human Resources mehr als 15 Serviceplattformen mit diversifizierten ökologischen Geschäften und vielen Problemen: Serviceanfragen müssen häufig geändert werden, was zu vielen Routen führt, die bedient und konfiguriert werden müssen. Das ursprüngliche System basierte auf CLB für die Verkehrsweiterleitung.Im Laufe der Zeit musste das Betriebs- und Wartungspersonal viele Orte konfigurieren und betreiben, was viel Arbeitskraft und Zeit in Anspruch nahm.
Häufige hohe Parallelität und großer Datenverkehr. Kunden zahlen beispielsweise Gehälter oder heben große Geldbeträge am selben Tag ab. Wenn die Anzahl der Benutzer Hunderttausende erreicht, bestimmte Verhaltensweisen, die intensiv ausgeführt werden, wie z. B. Einchecken, Unterzeichnen von Verträgen, Empfangen von Aufgaben oder Löhnen usw., ist der gleichzeitige Datenverkehr des Systems zu diesem Zeitpunkt sehr groß und kurz -Begriffsverdopplungsfälle gibt es zuhauf.
Der Expansionsdruck der individuellen Nachfrage. APISIX wird auf Basis von OpenResty, Nginx und Lua entwickelt, aber wenn Lua zur Entwicklung von Plug-Ins verwendet wird, fallen bestimmte Investitions- und Wartungskosten für Forschung und Entwicklung an.
Für die Plug-in-Unterstützung hat APISIX bereits im Vorfeld Vorbereitungen getroffen. Die offizielle Website von APISIX bietet benutzerdefinierte Plug-Ins ext-pluginzur Unterstützung der Java-Entwicklung, und das Problem des Technologie-Stacks lässt sich leicht lösen. Darüber hinaus ist die Ökologie von APISIX sehr gut. Als heimisches Gateway-Produkt ist die Community äußerst aktiv, und es gibt viele Praktiken in der Branche. Auf der Ebene der Cloud-nativen Gateways ist es auch auf höchster Ebene präsent die Branche.

Unser Team ist sehr offen und nach Abschluss der Technologieauswahl werden wir diese schnell implementieren. Von der Online-Bereitstellung bis zum Batch-Zugriff auf die Dienste dauerte es weniger als einen Monat. Derzeit erfolgt der Zugriff auf 99 % der Dienste über APISIX, seit mehr als einem Jahr gab es keine Unfälle mehr, und die Stabilität ist sehr gut. Im Bild unten sehen Sie einige Funktionen von APISIX, und der rote Teil ist das, was wir am meisten schätzen.

APISIX Vier Praxisszenarien

Lassen Sie uns die vier praktischen Szenarien von APISIX nacheinander vorstellen.

Routing-Richtlinie

Basierend auf Radixtree und etcd bietet Apache APISIX die Möglichkeit eines extrem schnellen Routing-Abgleichs und einer schnellen Synchronisierung der Konfiguration. Das Design und die Implementierung von Routing und Plug-Ins erfüllen die Anforderungen an extrem schnelle Leistung und extrem niedrige Latenz. Beispielsweise haben die folgenden zwei Szenarien eine gute Leistung gezeigt:

API-Notstopp während der Stoßzeiten. Wenn das Geschäftssystem auf Hochtouren läuft, exportiert der Benutzer Millionen von Berichtsdaten, was direkt zu einem Ausfall der MySQL-Datenbank führt. Zu diesem Zeitpunkt kann das Problem durch einen Neustart des Dienstes nicht behoben werden. Wenn der Benutzer den Vorgang weiterhin exportiert, wird die Fehler wird fortgesetzt. Wir mussten zuvor eine Version herausgeben, um dieses Problem zu lösen; Aber jetzt ist nur noch eine einfache Konfiguration durch das Betriebs- und Wartungspersonal erforderlich, die API kann im Notfall deaktiviert werden, durch die Routing-Prioritätsstrategie und die Invalidierungsstrategie (in Abhängigkeit von das Serverless-Plug-in), kooperieren, um die API-Schnittstelle auf Minutenebene offline zu schalten, um den Dienst zu stabilisieren.
Es gibt viele Geschäftssysteme. Unter anderem muss das SaaS-System den Zugriff auf kundendefinierte Domänennamen unterstützen.Wir verwenden einen domänenübergreifenden Namensabgleich, um eine einmalige Konfiguration und eine globale Verwendung zu erreichen.

Das Bild unten ist das Trenddiagramm des Routing-Wachstums 2022 von Junrun Human Resources. Es ist ersichtlich, dass sich die Anzahl unabhängig vom Front-End- oder Back-End-Routing nach der Einführung von APISIX um das Dreifache oder mehr erhöht hat .

sicher kontrollieren

Wir haben eine zweistufige Gateway-Architektur basierend auf APISIX aufgebaut und ein logisches Gateway auf APISIX isoliert.Benutzer, die auf CLB zugreifen, geben APISIX ein und leiten es dann an das Geschäftssystem weiter. Wenn die vom Benutzer verwendete Funktion PaaS verwenden muss, erfolgt der Zugriff über das PaaS-Service-Gateway.Zu diesem Zeitpunkt ist das PaaS-Service-Gateway ein logisches Gateway.

Wir haben einen Bereich innerhalb von Kubernetes geschlossen, nämlich die PaaS-Plattform, die eine Vielzahl von Basisdiensten enthält. Unter Verwendung der Merkmale des APISIX-Gateways: Sicherung, Sicherheit und Identitätserkennung muss das übergeordnete Geschäftssystem das PaaS-Gateway passieren, um auf PaaS-Dienste zuzugreifen.

Verkehrsregelung

Aufgrund der großen Anzahl von Geschäftssystemen und Hochverfügbarkeitsanforderungen für Kerndienste (SSO, PaaS-Dienste und Gehaltsabrechnungsdienste) muss sich die Verkehrssteuerung dieser Dienste auf die von APISIX bereitgestellte Graustufenstrategie für das Verkehrsmanagement stützen.

Zu diesem Zweck verwendet das System zwei Methoden. Eines basiert auf Label-Graustufen. Bevor der Kerndienst in die Produktionsumgebung hochgeladen wird, verifizieren ihn die Tester zunächst in der Graustufenumgebung. Wir leiten den Datenverkehr der Testbenutzer an den Graustufendienst weiter, um die Produktionsumgebung zu überprüfen. Nach bestandener Überprüfung werden wir den Datenverkehr basierend auf der Gewichtung reduzieren, eine Zeit lang beobachten und dann den gesamten Datenverkehr auf die neue Version umstellen Wenn es kein Problem gibt, befindet sich das zweite in der Produktionsumgebung. Mehrere Versionen desselben Dienstes koexistieren, und wenn verschiedene Geschäftssysteme auf verschiedene Versionen zugreifen, werden Routing und Weiterleitung basierend auf Labels durchgeführt.

Protokollverwaltung

Wie aus dem Architekturmuster in der folgenden Abbildung ersichtlich, basieren sowohl APISIX- als auch Pod-Dienste auf der Kubernetes-Architektur, und alle Back-End-Routen sind an denselben Dienst gebunden. Das auf dem APISIX-Dienst konfigurierte Kafka-Plug-In wird verwendet zum Sammeln von Protokolldaten, und Skywalking wird gleichzeitig zur Überwachung der Programmleistung konfiguriert. Gemäß RequestId und TraceId in Skywalking und Log Cloud können Sie den gesamten Anruflink beobachten und die Protokollaufzeichnungen und den Zeitverbrauch der API-Anforderungen für jeden Link anzeigen.

Den derzeit beobachteten Daten nach zu urteilen, hat das System jeden Tag zig Millionen API-Anfragen, die durchschnittlich täglich generierten Protokolldaten erreichen 30 GB und die Gesamtmenge der Protokolle erreicht das TB-Niveau.

Erfahrung und Aussicht auf die Verwendung von APISIX

Im Prozess der Nutzung von APISIX haben wir einige Erfahrungen zusammengefasst und teilen diese hier mit Freunden, die sich für APISIX interessieren.

Um ein grundlegendes Image aufzubauen, müssen ausländische Ressourcen herangezogen werden. APISIX muss innerhalb von Kubernetes bereitgestellt werden, und bestimmte Sekundärentwicklungen und Quellcodekompilierungen werden intern durchgeführt. Derzeit müssen Ressourcen von GitHub abgerufen werden. Derzeit muss ein Teil des offiziellen Docker-Images fremde Ressourcen abrufen. Lokale Entwicklung und online Bei der Bereitstellung ist das Debuggen der Umgebung relativ mühsam.

Es gibt Anforderungen für die Bereitstellung der Debugging-Umgebung. Das benutzerdefinierte Plug-in java-plugin-runnermuss die RPC-Kommunikation basierend auf runner.sock durchführen. Es gibt nur wenige Fälle und es ist schwierig zu debuggen. Es muss sich im selben Image wie APISIX-Service befinden.

** Jeden Tag wird eine große Anzahl von Protokolldatensätzen lokal generiert. **Als die Produktion gerade freigegeben wurde, stellten wir fest, dass die Anzahl der täglichen Zuwächse sehr groß war, selbst wenn nur Protokolle auf Fehlerebene aktiviert waren, was zu einem Node-Disk-Alarm im Kubernetes-Cluster führte. Später, wenn das Bild gepackt wird, wird das Protokoll von der Dateiaufzeichnung zur Ausgabe an die Konsole geändert und zur Speicherung und Datensatzanalyse im Cloud-Protokolldienst CLS gesammelt, um eine lokale dateilose Speicherung zu realisieren.

All dies stellt natürlich die einzige Möglichkeit in der Vorbereitungsarbeit dar. APISIX hat uns nach der offiziellen Inbetriebnahme weitaus mehr Vorteile gebracht als erwartet. Generell gibt es drei Punkte:

Starke Unterstützung für die Geschäftsentwicklung. Nach der Verwendung von APISIX verfügt das System über umfangreichere Funktionen und eine stärkere Leistung. APISIX bietet eine Vielzahl von Beobachtbarkeits- und Sicherheitsschutzmethoden für API-Dienste, die unseren täglichen Zugriff auf zig Millionen Datenverkehr unterstützen können.
Steigern Sie die Effizienz der F&E-Lieferung. Zum Beispiel dauerte es 10 Minuten, bis die DNS-Auflösung wirksam wurde, aber jetzt dauert es ein paar Sekunden, bis sie durch die domänenübergreifende Namenskonfiguration wirksam wird, da die ursprüngliche Konfiguration in CLB und Nginx manuell geändert werden muss, aber wir haben es getan mehr als 10 Systeme und mehr als 100 Es gibt viele Punkte, die für Dienste konfiguriert werden müssen.Nach der Anwendung der domänenübergreifenden Namenskonfiguration von APISIX muss sie nur noch im Control Panel geändert werden, was die Arbeitslast von DevOps erheblich reduziert.
Kosten drastisch senken. Änderungen der LB-Kosten (Load Balancing). Die Anzahl der LB-Dienste wurde von über 200 auf über 10 reduziert, wodurch die Systemwartungskosten erheblich gesenkt werden.
In der späteren Phase werden wir eine Reihe funktionaler Entwicklungen haben, die mit Hilfe von Cloud-nativen Gateways von APISIX erreicht werden müssen, einschließlich, aber nicht beschränkt auf: Integration von Sentinel, damit Dienste Hot-Swap-fähige dynamische Strombegrenzungsfunktionen haben, Entwicklung mehrdimensionale Verkehrskontrolle, Upgrade von Risikokontroll-Identifikationsfunktionen, mehrschichtige Governance und vollständige Link-Log-Analyse usw. Zu diesem Zeitpunkt werden mehrere Sätze von APISIX-Clustern verwendet, um die funktionalen Anforderungen der selbst entwickelten Serviceplattform zu erfüllen.

Zusammenfassend lässt sich sagen, dass die Verwendung des cloudnativen APISIX-Gateways der Junrun-Personaldienstleistungsplattform eine große Hilfe gebracht hat, sodass wir problemlos mit vielfältigen und komplexen Szenarien umgehen und ein perfektes digitales Personaldienstleistungsökosystem schaffen können.

Dieser Artikel wird von OpenWrite veröffentlicht, einer Multi-Post-Plattform zum Bloggen !