Der gemeinsame Gast Jian Haiqing ist die Person, die für den Betrieb und die Wartung von CVTE verantwortlich ist.
Mit der rasanten Entwicklung der Technologie im Bereich der menschlichen Interaktionsintelligenz stellen die Geschäftsanforderungen auch höhere Anforderungen an die Architekturiteration. Wie geht seewo auf Gateway-Ebene vor, um mit der immer ausgereifteren und schnell wachsenden Geschäftslage zurechtzukommen?
Gateway vorbei an Iterationen und Schwachstellen
Die Entwicklung des seewo Gateways hat vier Iterationen durchlaufen. Im Jahr 2013 begann das Unternehmen, das Internetgeschäft auszuprobieren. Damals wurde das erste Gateway mithilfe der statischen Konfiguration OpenResty + NGINX erstellt und die Entwickler veröffentlichten es über SCP (Secure Copy). Gleichzeitig besteht ein schwerwiegenderes Problem darin, dass jede Veröffentlichung die Unterstützung von Betriebs- und Wartungspersonal erfordert, um einen reibungslosen Start zu gewährleisten.
Mit der Geschäftsentwicklung und dem Ausbau des Personals haben wir 2016 das Release-System der zweiten Generation und zugehörige iterative Gateways entwickelt. Dieses Mal integriert es das auf OpenResty basierende Upsync-Modul und arbeitet mit Consul bei der Serviceerkennung zusammen. Das System der zweiten Generation löst das Problem, dass die vorherige Generation von Entwicklern nicht unabhängig veröffentlichen und online gehen konnte, aber dennoch die Unterstützung von Betrieb und Wartung benötigt, um die Kapazität zu erweitern.
Danach begann sich das Geschäft des Unternehmens rasch zu entwickeln und es wurden höhere Anforderungen an die elastische Skalierbarkeit von Gateways und Produkten gestellt. Im Jahr 2018 haben wir das System der dritten Generation auf Basis von K8s entwickelt. In Anbetracht der Tatsache, dass einige Anwendungen noch auf dem Array-Computer verbleiben, verwendet die gesamte Gateway-Architektur Ingress NGINX auf K8s als Gateway der zweiten Ebene, und das Gateway der ersten Ebene ist immer noch eine Gateway-Architektur mit zwei Ebenen und OpenResty. In diesem Fall wurden zwar Selbsthilfeprobleme wie die Veröffentlichung und Erweiterung der vorherigen Generation gelöst, es wurden jedoch neue Probleme eingeführt.
Die rasante Geschäftsausweitung führt zu immer höheren Anforderungen an die Gesamtstabilität. Nach der Einführung dieser zweischichtigen Gateway-Architektur führt das Neuladen von NGINX auf der ersten Schicht und Routing-Änderungen auf dem Gateway der zweiten Schicht dazu, dass langfristige Verbindungen getrennt werden. Dies hat größere Auswirkungen auf einige langfristige Verbindungsnutzungsszenarien. Wenn die Software beispielsweise den Unterrichtsstatus des Lehrers abrufen muss, wird die Verbindung plötzlich getrennt und die Statuserfassung unterbrochen, was sich auf den Unterricht auswirkt.
Die zweistufige Struktur selbst wird zu einer gewissen Kostensteigerung führen. Gleichzeitig können wir aus dem Diagramm der Gateway-Verkehrstopologie oben erkennen, dass es zusätzlich zu den oben genannten Altproblemen auch einige architektonische Schwachstellen gibt:
Unter der zweistufigen Gateway-Architektur muss NGINX neu geladen werden, unabhängig davon, ob es um das Hinzufügen eines Domänennamens, das Ändern der Konfiguration oder das Hinzufügen einiger Sonderregeln für das Gateway der ersten Stufe geht.
Gleichzeitig ist die Koordination der Komponenten aus Sicht der Gesamtarchitektur für die Flusskontrollebene relativ schlecht. Insbesondere derzeit hat das Volumen unserer Geschäftsbenutzer Dutzende Millionen erreicht. Sobald auf der Clientseite eine unvermeidbare Anomalie auftritt, kann der Server erodiert werden. Wenn zu diesem Zeitpunkt keine bestimmte Flusskontrollfunktion auf Gateway-Ebene vorhanden ist, wird die Backend Es wird eine sehr schwere Lawine verursachen.
Basierend auf den oben genannten iterativen Legacy-Problemen und architektonischen Schwachstellen haben wir daher im Jahr 2022 APISIX eingeführt, um die oben genannten Probleme zu lösen. Gleichzeitig wird mit Hilfe von APISIX auch die Fähigkeit gestärkt, den Verkehr auf Gateway-Ebene zu steuern.
Es gibt jedoch einige bekannte Herausforderungen bei der Migration von APISIX. Zum Beispiel:
In der ersten Ebene gibt es viele NGINX-Domänennamen und die Anpassungsregeln sind kompliziert. Derzeit gibt es in unserem Unternehmen über 700 Domainnamen und es gibt immer noch viele benutzerdefinierte Konfigurationen wie Umleitung, Black- und Whitelists usw., die alle an APISIX-Plug-Ins angepasst werden müssen.
Aufgrund historischer Probleme ist die Beziehung zwischen dem NGINX der ersten Ebene und dem Ingress-Gateway der zweiten Ebene immer noch eine Eins-zu-Viele-Beziehung. Ob die anschließende Verkehrsumschaltung sehr kompliziert sein wird, ist ebenfalls ein zu lösendes Problem.
Die interne zweistufige DNS-Architektur. Derzeit wird die DNS-Auflösung hauptsächlich für die interne Auflösung des öffentlichen Netzwerks und des Servers verwendet. Daher hoffen wir, dass die Folgelösung das Rollback erleichtern und die Leistung von Intranetaufrufen optimieren kann.
Architekturanpassung nach APISIX-Migration
Angesichts der oben genannten bekannten Herausforderungen wurden während des Migrationsprozesses hauptsächlich Operationen aus den folgenden drei Blickwinkeln durchgeführt. Da der gesamte Migrationsprozess keine Forschungs- und Entwicklungsinhalte umfasst, wird er vollständig vom Betriebs- und Wartungspersonal umgesetzt.
Während des Migrationsprozesses müssen zunächst APISIX-Routen generiert werden. Basierend auf der ursprünglichen Architektur haben wir eine Ebene mit Sonderfunktionen wie Rewrite, Set-Header usw. entfernt. Schwächen Sie die Weiterleitung des Gateways der ersten Ebene, konzentrieren Sie alle Funktionen auf den Ingress der zweiten Ebene und generieren Sie dann APISIX-Routen basierend auf dem Ingress. Gleichzeitig werden APISIX-Plugins basierend auf der NGINX-Konfiguration angepasst.
Nachdem die Route generiert wurde, muss überprüft werden, ob der gesamte Weiterleitungsprozess korrekt ist. Wir überprüfen die Richtigkeit der Weiterleitung und Weiterleitung anhand der Goreplay-Aufzeichnung und -Wiedergabe und überprüfen gleichzeitig durch automatisierte Skripte, ob die Plug-in-Funktionen normal sind. Im Falle des Bestehens der Funktionsprüfung prüfen wir weiterhin, ob APISIX die internen Anforderungen hinsichtlich der Leistung erfüllt. Daher haben wir während des Leistungsstresstests das Elastic-APM-Plug-In entwickelt und die Leistung einiger Plug-Ins optimiert, die sich auf QPS auswirken.
Nach der Lösung von Funktions- und Leistungsproblemen ist die Verkehrsumschaltung die größte Herausforderung, da sich die Verkehrsumschaltung direkt auf die Produktionsqualität auswirkt.
Obwohl wir Goreplay für die Verkehrsaufzeichnung und -wiedergabe verwendet haben, benötigen wir immer noch eine zuverlässigere Rollback-Lösung. Unter der Annahme, dass die Verkehrsumschaltung Anomalien wie Weiterleitungsausnahmen oder APISIX-Abstürze verursacht, können schnelle Rollback-Vorgänge durchgeführt werden. Auf dieser Grundlage haben wir zunächst den Verkehr im öffentlichen Netzwerk umgeschaltet, da der Verkehr im öffentlichen Netzwerk von der WAF zurück zur Quelle und zum SLB umgeschaltet wird. Wenn wir zu diesem Zeitpunkt zu APISIX wechseln, können wir die Rückseite leicht ändern -Zur Quelladresse wird der gesamte Datenverkehr zurückgesetzt, wie in der obigen Abbildung mit der Bezeichnung „Switch“ dargestellt. Der Verkehrsumschaltprozess in dieser ungewöhnlichen Situation erfolgt grundsätzlich auf der zweiten Ebene und der gesamte Verkehr kann innerhalb von 10 Sekunden zurückgeschaltet werden.
Nachdem wir die Umschaltung des öffentlichen Netzwerkverkehrs abgeschlossen hatten, änderten wir nach einigen Tagen reibungslosen Betriebs den internen Netzwerkverkehr über APISIX und dann war die gesamte Produktionsumschaltung abgeschlossen. Bei diesem Online-Vorgang sind jedoch tatsächlich einige Probleme aufgetreten.
Probleme und Lösungen während der Migration
Verzögerung bei der Weiterleitung des Prometheus-Plugins
Dies ist ein Problem, das in unserer Intranet-Testumgebung aufgetreten ist. Da es sich bei unserem Intranet um eine All-in-One-Testumgebung handelt, verwenden alle Abteilungen denselben APISIX-Eintrag, sodass es viele Routing-Regeln gibt, die über 4000 erreichen. Dies führt dazu, dass die Größe der Metriken jedes Mal, wenn das Prometheus-Plug-in abgerufen wird, 80 Millionen+ erreicht, was dazu führt, dass ein einzelner Worker-Prozess voll ausgeführt wird, was zu Verzögerungen bei der Worker-Weiterleitung führt.
Bei diesem Problem handelt es sich um ein Phänomen, das in der aktuellen Open-Source-Version von APISIX auftritt, hauptsächlich weil sich der Geschäftsverkehr und der interne API-Verkehr (z. B. Prometheus-Metriken und Admin-API) die Arbeitskräfte teilen. Wir haben zuvor Änderungen am Prometheus-Plug-In vorgenommen und die verzögerungsbezogenen Metriken machten mehr als 90 % aus (wie in der Abbildung oben gezeigt). Daher haben wir diesen Teil der Sammlung entfernt. Nach dem Entfernen dieses Teils erfüllt die Geschäftsebene immer noch unsere Anforderungen an die Überwachungsnutzung und hat keine Auswirkungen verursacht.
Allerdings haben wir seit Kurzem eine neue Lösung für dieses Problem, die sich noch im Demostadium befindet. Diese neue Lösung besteht darin, den Quellcode von NGINX zu ändern, indem ein oder mehrere Arbeitsprozesse (Isolationsprozess) gestartet werden, um Anforderungen an bestimmte Ports (wie Prometheus, Admin-API, Steuerungs-API usw.) gezielt zu überwachen und nicht um zu überwachen und Verarbeiten Sie normale Geschäftsanschlüsse. Fragen Sie. Andere Worker-Prozesse brechen die Überwachung der oben genannten Ports ab und verarbeiten nur normale Business-Port-Anfragen, um sicherzustellen, dass sich interne APISIX-Anfragen und normale Business-Anfragen nicht gegenseitig beeinflussen.
Ausnahme für Standardroutenübereinstimmung
Nach dem Start von APISIX stellten wir fest, dass der Domänenname nicht den exakten Übereinstimmungsmodus, sondern einen Wildcard-Abgleich verwendete, was nicht mit der längsten Übereinstimmung des Domänennamens in NGINX übereinstimmt. Daher haben wir das Problem gelöst, indem wir die Routing-Strategie und die URL-Methode in die Host+URL-Methode geändert haben.
Wenn Sie jedoch die URL-basierte Routing-Strategie von APISIX als Standardroute betrachten, können Sie Drucktests in Ihrer eigenen Produktionsumgebung durchführen, bevor Sie entscheiden, ob Sie diese beibehalten möchten.
Wenn Ihr Produktionsszenario über viele URLs und wenige Domänennamen verfügt, ist die Standard-Routing-Strategie von APISIX völlig in Ordnung. In unserem Geschäftsszenario gibt es jedoch nicht so viele URLs, sodass die Methode Host + URL besser für unsere Leistungsanforderungen geeignet ist.
Standardmäßiges Problem mit der automatischen Kernbindung
Im Kontext von Cloud Native entscheiden sich die meisten Benutzer für die Bereitstellung von APISIX in Containern. APISIX bindet jedoch automatisch Kerne unter der Standardkonfiguration, was dazu führt, dass in Containerszenarien nur die ersten paar Kerne verwendet werden, wodurch die ersten paar Kerne voll laufen und die letzten paar Kerne im Leerlauf bleiben. Obwohl die CPU-Auslastung nicht hoch ist, verzögert sich dadurch die APISIX-Weiterleitung.
Die APISIX-Community hat jedoch kürzlich damit begonnen, diese Konfiguration anzupassen und den Standardwert der worker_cpu_affinity-Konfiguration von true in false zu ändern. Daher ist dieses Problem derzeit in der APISIX-Version behoben.
Kompatibilitätsprobleme bei Versionsaktualisierungen
Beim Start von APISIX haben wir außerdem festgestellt, dass in älteren Systemen oder OpenSSL-Bibliotheken die ssl_ciphers keinen Schnittpunkt mit dem Standardwert des Servers haben, was zu einem SSL-Handshake-Fehler führte.
Als Reaktion auf dieses Problem empfehlen wir, vor dem Start von APISIX zunächst mit einigen SSL-Tools zu ermitteln, ob der SSL-Handshake-Schnittpunkt zwischen dem aktuellen alten Gateway und dem APISIX-Gateway korrekt ist oder den Nutzungsszenarien entspricht, und dann umfangreiche Migrationsanpassungen vorzunehmen .
Darüber hinaus haben wir nach der Veröffentlichung der LTS-Version 2.15 durch APISIX das Intranet aktualisiert. Nach dem Upgrade stellten wir jedoch einige Probleme im Zusammenhang mit der Routenanpassung fest.
Da es beim Upgrade von der alten Version auf die neue Version einige Kompatibilitätsprobleme gibt, schlägt die Überprüfung der Parameter http_to_https und append_query_string fehl, wenn der Parameter http_to_https des Redirect-Plugins wahr ist, und dann schlägt das Laden der Route fehl, was zum Verlust von führt die Route. In diesem Fall erfolgt 404 oder eine Weiterleitung an andere Upstreams, wenn die Route übereinstimmt.
Derzeit wurde dieses Problem im Master-Zweig von APISIX gelöst, für Version 2.15 jedoch nicht separat. Daher müssen Sie bei Verwendung dieser Version auf diesen Teil des Problems achten.
Vorteile und Aussichten der Anwendung von APISIX
Obwohl einige der Probleme, auf die wir bei der Einführung von APISIX gestoßen sind, oben erwähnt wurden, hat die Anwendung von APISIX nach der Einführung von APISIX einen großen Mehrwert für die Geschäftsebene des Unternehmens gebracht. Zum Beispiel:
Die Betriebs- und Wartungseffizienz wird verbessert. Nach der Verwendung von APISIX gibt es keine Probleme mehr beim Neuladen und Routing und Zertifikate können jederzeit aktualisiert werden, was den Entwicklern mehr Komfort bietet.
Verbesserte Flusskontrollfunktionen. Durch den Einsatz von APISIX haben wir sowohl die Stromkreisunterbrechung als auch die Strombegrenzung verbessert, wodurch die Fähigkeit auf der Ebene der Verkehrssteuerung gestärkt und der gesamte Kerngeschäftsprozess weiter stabilisiert wurde.
Selbstentwickelte Plug-Ins zur Erweiterung der Gateway-Funktionen. Dank der starken Skalierbarkeit von APISIX und der hervorragenden Leistung der eigenen Plug-Ins werden wir auch bei der Entwicklung einiger Plug-Ins aktiver sein. Beispielsweise haben wir die einheitliche Authentifizierungsfunktion in APISIX integriert, sodass neue Unternehmen nicht separat an das Authentifizierungssystem angeschlossen werden müssen, was den Produktiterationsprozess beschleunigt.
Die redundante Schicht von NGINX wird entfernt, um Kosten zu senken und die Effizienz zu steigern. In der vorherigen zweistufigen Gateway-Architektur war die erste Schicht von NGINX für Entwickler nicht transparent. Nach der Zusammenführung des zweischichtigen Gateways in einer Schicht können Entwickler nun einige Konfigurationen zu Routing oder Plug-Ins in der Architektur klar erkennen, was die Fehlerbehebung bequemer und schneller macht.
Bei der weiteren Planung des Einsatzes von APISIX werden wir die Weiterentwicklung auf Gateway-Ebene weiter vorantreiben. Entwickeln Sie beispielsweise selbst entwickelte Plug-Ins für interne Unternehmen, stellen Sie Multi-Tenant-Funktionen bereit oder bringen Sie API-Verwaltungsfunktionen auf Gateway-Ebene usw.
Selbstverständlich geben wir in diesem Prozess auch aktiv etwas an die Gemeinschaft zurück. Derzeit wurden 8 PRs in der Community beigesteuert, um zur Verbesserung und Behebung einiger Probleme im Zusammenhang mit ökologischen Plug-ins beizutragen. Verbessern Sie beispielsweise „batch_request“, um benutzerdefinierte URIs zu unterstützen, und stellen Sie Funktionen wie die Überprüfung des Anforderungstexts für das hmac-auth-Plug-in bereit.
Wir hoffen, dass wir im weiteren Übungsprozess die Eigenschaften von APISIX besser nutzen und voll ausschöpfen und die Nutzungsszenarien von APISIX aktiver erkunden können. Wir freuen uns auf die Einführung weiterer Co-Konstruktionsfunktionen in der Zukunft.
Über CVTE
Seit seiner Gründung hat CVTE die digitalen Bildungstools und -dienstleister seewo, die intelligente Kollaborationsplattform MAXHUB und viele andere bekannte Marken in der Branche etabliert. Unter anderem hat seewo von 2012 bis 2021 zehn Jahre in Folge die Marktanteilskrone der interaktiven Smart-Tablet-Branche Chinas gewonnen und sich zu einem wahren Branchen-Benchmark-Unternehmen entwickelt.
Über Apache APISIX
Apache APISIX ist ein dynamisches, hochleistungsfähiges Open-Source-API-Gateway in Echtzeit, das umfangreiche Verkehrsverwaltungsfunktionen wie Lastausgleich, dynamischen Upstream, Graustufenfreigabe, Servicesicherung, Identitätsauthentifizierung und Beobachtbarkeit bietet.
Als API-Gateway kann Apache APISIX Unternehmen dabei helfen, API- und Microservice-Verkehr schnell und sicher zu verarbeiten, und kann auf Szenarien wie Gateways, Kubernetes Ingress und Service Grids angewendet werden. Derzeit wurde es von professionellen Netzwerksicherheitsorganisationen wie PwC Data Security Team, Tencent Blue Army, Ping An Galaxy Lab, iQiyi SRC und Origin Castle Technology Security Team getestet und genießt hohe Anerkennung.
Apache APISIX-Landing-Benutzer (nur einige)
Apache APISIX GitHub:https://github.com/apache/apisix
Offizielle Apache APISIX-Website: https://apisix.apache.org/
Apache APISIX-Dokumentation: https://apisix.apache.org/zh/docs/apisix/getting-started