APISIX motiviert API-Gateway-Upgrade in Tencent BlueKing

Diese Fallstudie wurde von Lei Zhu, Technical Director der BlueKing PaaS-Plattform, IEG (Interactive Entertainment Group), Tencent, geteilt.

Über BlueKing

BlueKing ist ein interner Satz von integrierten Forschungs- und Betriebs-PaaS, der innerhalb von Tencent IEG (Interactive Entertainment Group) entwickelt wurde und mehrere Geschäftseinheiten und interne Plattformen bedient. Seine Rolle besteht darin, vollständige Lebenszyklusdienste für die Projekte des Unternehmens in den Phasen CI (Continuous Integration), CD (Continuous Delivery) und CO (Continuous Operation) bereitzustellen.

Überblick

Herausforderungen

• Geringe Leistung: Geringe Leistung bei hoher Parallelität und Algorithmen des Routings, was zu langsamer Routing-Übereinstimmung und -Weiterleitung führt
• Hohe DB-Belastung: Routing-Richtlinien werden in MySQL gespeichert. Daher ist die Datenbank mit vielen Abfrageanfragen belastet
• Hohe Kosten: Redis wird in vielen Szenarien weit verbreitet eingesetzt, was zu hohen Overhead-Kosten führt
• Unzureichende Isolation: Kann keine physische Isolation erreichen; instabile Langzeitverbindungen
• Unterstützung nur eines Protokolls: Unterstützt nur das HTTP-Protokoll
• Keine dynamischen Routing-Regeln: Unterstützt keine dynamischen Routing-Regeln, die nach Bedingungen abgeglichen werden; nicht freundlich genug für Canary-Release-Szenarien; unfähig zur szenariobasierten Kombination und Kapselung
• Fehlende Service-Erkennung: Fehlende automatische Service-Erkennung, nicht freundlich zur Microservices-Architektur

Ziele

• Plattformfähigkeiten in unabhängige Microservices umwandeln und eine Microservices-Transformation durchführen, um eine PaaS-Architektur zu bilden
• Low-Code-Technologie nutzen, um SaaS effizient zu entwickeln und die Microservices-Fähigkeiten der PaaS-Plattform zu nutzen
• Flexibel auf verschiedene Dienstszenarien durch verschiedene SaaS reagieren

Ergebnisse

• Vereinheitlichte Betrieb und Erweiterung des Gateways mithilfe der von K8s bereitgestellten CRD-Benutzerressourcen realisiert
• Bietet reichhaltigere Funktionen, die APISIX integrieren: Ressourcenverwaltung, Versionsfreigabe, automatische Dokumentation, Berechtigungsverwaltung, Beobachtbarkeit, Überwachung und Sicherheitsschutz
• Senkung der Kosten für die Unterstützung von Service-Erkennungsszenarien durch einheitliche Entwicklerschnittstellen und -vorschriften

Vielfalt und Komplexität von Spielen erfordern das BlueKing API-Gateway

Innerhalb von Tencent gibt es möglicherweise Tausende von Spielen. Abgesehen von einigen selbst entwickelten Spielen gehören andere zu den Agenturen. Die Spiele unterscheiden sich in Sprachen, der Speicherung, von der sie abhängen, und der Architekturstil bestimmt, dass BlueKing sein eigenes API-Gateway entwickelt hat.

Angesichts eines so komplexen Geschäftsszenarios, das eine große Anzahl heterogener Architekturen umfasst, muss BlueKing als interne Plattform sein API-Gateway transformieren, um eine PaaS-Architektur zu entwickeln, dann die Low-Code-Technologie nutzen, um SaaS effizient zu entwickeln und die Microservices-Fähigkeiten der PaaS zu nutzen, und verschiedene SaaS verwenden, um Dienstszenarien zu handhaben.

Um die Architektur von BlueKing zu abstrahieren, können wir ein API-Diagramm erhalten.

• Einerseits ist BlueKing eine komplizierte Plattform mit komplexen Anforderungen an ein einheitliches Gateway. Abgesehen davon, als Proxy zu fungieren, um die API der Plattformen aufzurufen, benötigt BlueKing mehr Gateway-Fähigkeiten, zum Beispiel Service-Erkennung, Autorisierung und Authentifizierung, dynamisches Routing, Canary-Release und Rate-Limiting usw.

• Andererseits stellen viele interne SaaS und Plattformen mit der Entwicklung der Cloud-Native-Technologie neue Anforderungen an das Gateway, wie z.B. die einheitliche Verkehrskontrolle externer Aufrufanfragen durch ein einheitliches Verkehrsgateway oder API-Gateway.

Gleichzeitig nutzen einige interne Geschäftssysteme einige der Infrastrukturfähigkeiten der BlueKing-Plattform, wie z.B. Container-Management oder Überwachung. Sie benötigen auch ein einheitliches Dienstgateway, um den gesamten Aufrufverkehr zu verwalten.

Mit der Entwicklung interner Geschäftsanforderungen muss das API-Gateway von BlueKing zunehmend vielfältige Szenarien unterstützen.

BlueKing API-Gateway 1.0

Das BlueKing API-Gateway 1.0 sollte es den Aufrufern der Plattformen (einschließlich verschiedener SaaS und Prozess-Engines) ermöglichen, direkt das API-Gateway aufzurufen, um Protokollumwandlung und Berechtigungsüberprüfung über das Gateway abzuschließen.

Die Architektur war auch relativ einfach und bestand aus zwei Teilen: der Serverseite und der Verwaltungsseite. Die Plattformen müssen auf die Verwaltungsseite zugreifen, die API-Ressourcenadressen und ihre entsprechenden Berechtigungen der Plattformen konfigurieren und schließlich ihre Dienste beim API-Gateway registrieren.

Nach einigen Jahren begannen mit zunehmenden Anfragen und komplexen Szenarien die Schwächen des BlueKing API-Gateways 1.0 allmählich sichtbar zu werden. Zum Beispiel:

• Schlechte Framework-Leistung: Das Django-Framework wurde für die Implementierung gewählt. Seine Leistung ist in Szenarien mit hoher Parallelität durchschnittlich und wird bei der Verarbeitung massiver Anfragen überfordert.

• Durchschnittliche Routing-Implementierungsleistung: Die Leistung des in API-Routing verwendeten Algorithmus ist gering, was die Geschwindigkeit der Routenübereinstimmung und -weiterleitung beeinträchtigt.

• Datenbanken sind belastet: Alle Routing-Richtlinien werden in MySQL gespeichert. Wenn es viele Regeln gibt, müssen viele Abfrageanfragen mit hohem Abfragedruck durchgeführt werden.

• Hohe Netzwerkkosten: Redis wird in verschiedenen Szenarien stark genutzt, was zu hohen Netzwerk-Overhead-Kosten führt.

BlueKing API-Gateway 2.0

Um die oben genannten Probleme zu lösen, hat BlueKing auf der Grundlage von Version 1.0 iteriert und Version 2.0 entworfen und implementiert. Im Vergleich zur vorherigen Generation war die bedeutendste Änderung von Version 2.0 die Neuimplementierung des Gateway-Frameworks und der Weiterleitungsschicht in Golang, da Golang im Vergleich zu Python Vorteile bei der Verarbeitung großer paralleler Anfragen hat.

Es wurden auch andere Optimierungsänderungen vorgenommen. Zum Beispiel wurde eine effizientere Routing-Implementierung im Speicher beibehalten; ein speicherbasierter Cache wurde in der Mittelschicht eingeführt, um die Abhängigkeit von Redis zu verringern. Die neue Architektur fügt auch Lebenszyklusmanagement für Gateways mit mehreren Versionen und Umgebungen hinzu und führt einen erweiterten Plugin-Mechanismus ein, um Entwicklern zu ermöglichen, Gateway-Fähigkeiten durch Plugins zu erweitern.

Insgesamt löst das BlueKing API-Gateway 2.0 Leistungsprobleme und die meisten Schmerzpunkte, die in Version 1.0 auftraten. Aber im Laufe der Zeit begannen neue Probleme langsam aufzutauchen.

• Unzureichende Isolation: Kann keine echte physische Isolation erreichen; der Freigabeprozess führt dazu, dass Langzeitverbindungen getrennt werden

• Unterstützung nur eines Protokolls: Nur HTTP wird unterstützt, und die Nachfrage nach Nicht-HTTP-Protokollen nimmt in tatsächlichen Szenarien zu

• Keine dynamischen Routing-Regeln: Unterstützt keine dynamischen Routing-Regeln, die nach Bedingungen abgeglichen werden; nicht freundlich genug für Canary-Release-Szenarien; unfähig zur szenariobasierten Kombination und Kapselung

• Fehlende Service-Erkennungsfähigkeit: Fehlende automatische Service-Erkennungsfähigkeit, nicht freundlich zur Microservices-Architektur

APISIX sticht bei der Technologieauswahl des BlueKing API-Gateways hervor

Es gibt viele Produktsysteme im Unternehmen, die das API-Gateway nutzen müssen. Es ist sehr schwierig, alle unterschiedlichen Anforderungen an das Gateway in denselben Satz von Gateways zu integrieren.

Daher haben wir die Idee, ein verteiltes Gateway zu entwerfen. Das heißt, ein großes Gateway wird in viele Microgateways aufgeteilt, die verwendet werden, um die Unterschiede in den Anforderungen verschiedener Systeme an Gateways auszugleichen." sagte Zhu.

Die Komponenten der verteilten Gateway-Architektur sind hauptsächlich in zwei Kategorien unterteilt: die Verwaltungsseite und die Microgateway-Instanz.

Die Verwaltungsseite verwaltet und steuert jedes Microgateway einheitlich, und der Administrator jedes Gateways konfiguriert und verwaltet das Gateway. Microgateway-Instanzen sind einzelne Gateway-Dienste, die unabhängig bereitgestellt werden und den Zugriffsverkehr jeder spezifischen Gruppe von Diensten übernehmen und entsprechend den Einstellungen der Verwaltungsseite verwandte Zugriffskontrollen durchführen. Alle Microgateway-Instanzen werden von derselben Verwaltungsseite gesteuert.

"Bei der Technologieauswahl des Microgateways haben wir mehrere beliebte Open-Source-Gateways auf dem Markt berücksichtigt, wie z.B. Kong und Tyk. Nachdem wir Popularität, Technologie-Stack, Protokollunterstützung und andere Ebenen verglichen haben, haben wir uns schließlich für APISIX als wichtigste Backend-Technologie unseres Microgateways entschieden." sagte Zhu.

Zhu sagte, BlueKing habe APISIX ausgewählt, weil es auf NGINX + Lua basiert, sodass seine Gesamtleistung im Vergleich zu denen, die auf Golang basieren, Vorteile hat. Darüber hinaus ist APISIX in der Skalierbarkeit bemerkenswert und unterstützt auch die Erweiterung von Fähigkeiten durch Multi-Programmiersprachen-Plugins. Viele typische Anwendungsfälle wurden beobachtet.

Außerdem kann APISIX dank seiner großen Kompatibilität nach den Anforderungen von BlueKing angepasst werden. Zum Beispiel hat BlueKing auf der Grundlage von APISIX die Kontrollfläche von APISIX nach internen Anforderungen angepasst.

BlueKing API-Gateway 3.0 basierend auf APISIX

In der Cloud-Native-Umgebung ist K8s die wichtigste Basiskomponente, die Aufmerksamkeit erfordert. Da das gesamte Microgateway für die Cloud-Native-Umgebung entwickelt wurde, hat die Version 3.0 eine neue Architektur auf der Grundlage von K8s.

Der Kern besteht darin, die von K8s bereitgestellten CRD-Benutzerressourcen zu nutzen, um den gesamten Betrieb und die Erweiterung des API-Gateways zu realisieren.

Wie in der Abbildung oben gezeigt, führt das Gateway eine Reihe von K8s-CRD-Ressourcen ein, darunter BkGatewayStage (Gateway-Umgebung), BkGatewayService (Backend-Dienst) usw. Durch diese CRDs kann BlueKing das spezifische Verhalten jeder Microgateway-Instanz steuern.

Mehrere "Operatoren" in der Abbildung sind der Kern dieser Architektur. Oben befindet sich der Plugin-Operatoren-Dienst, der eine Reihe von Plugin-Operatoren enthält. Zum Beispiel wird der Operator, der für die Service-Erkennung verantwortlich ist, die Adresse des Backend-Dienstes, der im Service-Erkennungszentrum registriert ist, in den K8s-Cluster schreiben.

Der Kern-Operator in der Mitte überwacht alle Gateway-bezogenen CRD-Ressourcen. Der Ressourcen-Reconciler ist dafür verantwortlich, die Gateway-Konfiguration in ein Format umzuwandeln, das die APISIX-Microgateway-Instanz verstehen kann, und so das vollständige Lebenszyklusmanagement des Microgateways zu realisieren.

Dieser Satz von Microgateways ist in zwei Bereitstellungstypen unterteilt:

• Geteiltes Gateway: Der Standardtyp, der auf der Plattform bereitgestellt wird, und die API-Zugriffsadresse wird einheitlich von der Plattform generiert und verwaltet.

• Dediziertes Gateway: Der Benutzer stellt eine "Microgateway"-Instanz bereit, die nach dem Zugriff auf die Plattform zu einem "dedizierten Gateway" wird. Die API-Zugriffsadresse muss manuell verwaltet werden, und der Verkehr fließt direkt vom "dedizierten Gateway" zum Backend-Dienst.

Es gibt nur eine einheitliche Verwaltungsseite, deren Fähigkeiten, wie Multi-Umgebungsmanagement und Zugriffskontrolle, von allen Gateways gemeinsam genutzt werden. Allerdings unterscheiden sich die unterstützten Funktionssätze zwischen den verschiedenen Arten von Microgateway-Instanzen, die sie verwaltet.

Nehmen wir als Beispiel die geteilte Gateway-Instanz. Der Funktionssatz, den sie unterstützt, ist relativ grundlegend und umfasst hauptsächlich einheitliche Login-Authentifizierung, Rate-Limiting und Multi-Protokoll-Unterstützung. Aber die unabhängigen dedizierten Gateway-Instanzen haben ihre eigenen einzigartigen personalisierten Fähigkeiten. Da das dedizierte Gateway und das Geschäft zum selben Cluster gehören, kann es schnell dynamisches Routing, benutzerdefinierte Service-Erkennung usw. realisieren und die robuste Skalierbarkeit von APISIX nutzen, um weitere Fähigkeiten anzupassen.

Basierend auf der obigen Architektur und den Modi bietet das BlueKing API-Gateway 3.0 mit der Unterstützung von APISIX reichhaltigere Funktionen. Zum Beispiel Ressourcenverwaltung, Versionsfreigabe, automatische Dokumentation, SDK, Berechtigungsverwaltung, Beobachtbarkeit, Überwachung und Alarmierung sowie Sicherheitsschutz.

Praktische Szenarien des BlueKing Gateways 3.0 mit APISIX

Es gibt vier typische praktische Szenarien innerhalb von Tencent: Service-Erkennung, einheitliche Authentifizierung, dynamisches Routing und Lizenzmanagement des Clients.

Service-Erkennung

Die Service-Erkennung ist eine grundlegende Fähigkeit, die von der Microservices-Architektur benötigt wird. Intern kann sie durch benutzerdefinierte Ressourcen CRD implementiert werden. Eine gültige Service-Erkennungs-YAML-Definition ist im Code auf der rechten Seite der folgenden Abbildung dargestellt.

Nachdem die oben genannten CRD-Ressourcen in den K8s-Cluster geschrieben wurden, lösen sie die verwandten Aktionen der Service-Erkennungs-Controller aus. Anschließend kann der Reconciler die entsprechende Service-Erkennungskonfiguration erfassen und Programmierobjekte im Zusammenhang mit der Service-Erkennung erstellen.

Dann liest der Reconciler die relevanten Adressinformationen des Service-Erkennungszentrums durch die integrierte Service-Erkennungsschnittstelle wie Watcher und Lister und schreibt die erhaltene Adresse durch die CRD-Ressource BkGatewayEndpoints zurück in den K8s-Cluster.

Nach einer komplexen Verarbeitung durch den Kern-Operator auf der rechten Seite werden diese Endpunkte schließlich mit dem Upstream synchronisiert, der APISIX entspricht. Ein vollständiger Service-Erkennungsprozess ist abgeschlossen.

Um die Entwicklung zu erleichtern, hat BlueKing ein allgemeines Service-Erkennungsframework implementiert, das eine einheitliche Entwicklerschnittstelle und -spezifikation bereitstellt und verwendet werden kann, um andere Arten von Service-Erkennungsszenarien zu geringen Kosten zu unterstützen.

Einheitliche Authentifizierung

Der Teil der einheitlichen Authentifizierung ist relativ einfach. In der täglichen Praxis gibt es Anfragen aus drei Quellen: Browser, Plattformen und einzelne Benutzer. Basierend auf APISIX hat BlueKing ein Authentifizierungs-Plugin, BK-Auth, angepasst, um eine einheitliche Authentifizierung zu erreichen.

Der spezifische Implementierungsprozess ist in der obigen Abbildung dargestellt. Nach der Anfrage liest das Plugin die relevanten Anmeldeinformationen aus dem Header und ruft dann einheitlich den BK-Auth-Authentifizierungsdienst auf, um die Anmeldeinformationen zu überprüfen und die entsprechenden SaaS-Informationen zu lesen. Dann verwendet das Plugin den mit dem Backend vereinbarten privaten Schlüssel, um ein JWT-Token auszustellen und es in den Anfrage-Header zu schreiben, und schließlich in die APISIX-Variable.

Neben der einheitlichen Authentifizierung gibt es auch einige komplexe Authentifizierungsszenarien in internen Projekten. Seine Hauptfunktion besteht darin, zu beurteilen, ob die SaaS berechtigt ist, wenn die SaaS eine bestimmte Ressource einer Plattform aufruft. Die einheitliche Ressourcenauthentifizierung wird auch durch Golang über das APISIX-Plugin implementiert, wie in der folgenden Abbildung dargestellt.

Die Client-Anfragen können zunächst die SaaS-Anwendungsinformationen über den Authentifizierungslink abrufen, dann mit dem Authentifizierungs-Plugin basierend auf RPC interagieren, wenn sie das ext-plugin durchlaufen. Zu diesem Zeitpunkt wird das Authentifizierungs-Plugin direkt die Authentifizierungsdaten im Cache abfragen, die von der Verwaltungsseite durch den vollständigen und inkrementellen Mechanismus synchronisiert werden, und dann die Authentifizierung abschließen.

Dynamisches Routing

Ein typisches Anwendungsszenario für dynamisches Routing stammt von der BlueKing-Container-Management-Plattform. Die BlueKing-Container-Plattform verwaltet viele K8s-Cluster, von denen einige Dienstcluster und einige Datencluster sind.

Als Benutzer müssen Sie häufig die APIServers dieser Cluster anfordern. Wenn eine Benutzeranfrage in das Microgateway eintritt, bestimmt das Gateway basierend auf dem Anfragepfad, an welchen Cluster-APIServer es weitergeleitet werden soll.

Nachdem die Anfrage eingegeben wurde, extrahiert das dynamische Routing-Plugin zunächst die ID-Informationen des Clusters, schreibt dann die Route um und bestimmt dann, ob der Cluster direkt verbunden ist.

Für nicht direkt verbundene Cluster wird zunächst ein BCS-Cluster-Manager-Upstream generiert und dann über diesen mit dem BCS-Agent interagiert, und schließlich wird die Anfrage an den APIServer des Clusters weitergeleitet.

Für direkt verbundene Cluster ist der Prozess ähnlich wie beim einheitlichen Authentifizierungs-Plugin oben, und das Plugin wird regelmäßig einige grundlegende Informationen im Zusammenhang mit dem Cluster synchronisieren. Nachdem die Clusterinformationen gefunden wurden, wird der relevante Upstream generiert, die Verbindungslogik über das APISIX-Plugin neu definiert und schließlich die Anfrage an den Cluster-APIServer gesendet.

Client-Zertifikatsverwaltung

In den praktischen Szenarien von BlueKing gibt es eine Klasse von Systemen, die einen komplexeren Client-Zertifikatsüberprüfungsmodus verwenden, wenn sie Ressourcen beim Gateway registrieren. Daher muss ein Benutzer, der seine Ressourcen anfordern möchte, ein gültiges Client-Zertifikat bereitstellen.

Die spezifische Implementierung ist in der obigen Abbildung dargestellt. Der Gateway-Manager muss auf der Verwaltungsseite das Client-Zertifikat konfigurieren, das vom Gateway für verschiedene Umgebungen verwendet wird. Nach der Konfiguration wird das Zertifikat in den K8s-Cluster veröffentlicht, in dem sich das entsprechende Microgateway befindet.

Dieser Prozess verwendet einige CRD-Ressourcen und offizielle Secret-Ressourcen von K8s und wird kontinuierlich vom Kern-Operator-Dienst abgeglichen, wie z.B. das Finden des entsprechenden Zertifikats gemäß dem Domainnamen. Eine effektive Client-Zertifikatskonfiguration wird schließlich in der relevanten Konfiguration des APISIX-Service widergespiegelt. (Wie im roten Kasten oben rechts in der Abbildung dargestellt)

Zusammenfassung

Apache APISIX ist ein Open-Source-, dynamisches, skalierbares und leistungsstarkes Cloud-Native-API-Gateway für alle Ihre APIs und Microservices. Nachdem es von API7.ai an die Apache Software Foundation gespendet wurde, ist APISIX zu einem Top-Level-Open-Source-Apache-Projekt herangewachsen.

Mit der Entwicklung der Microservices-Architektur und interner Geschäftsprojekte konnte das vorherige API-Gateway die Anforderungen nicht mehr erfüllen. Tencent BlueKing hat nicht nur das Problem gelöst, sondern auch reichhaltigere Funktionen mit APISIX bereitgestellt.