iQIYI erschließt Innovationen im API-Gateway mit Apache APISIX

Überblick

Herausforderungen

1. Hoher Datenverkehr führt täglich zu zahlreichen CPU-IDLE-zu-niedrig-Warnungen.
2. Zu viele Komponenten hängen von der Systemarchitektur ab.
3. Hohe Betriebs- und Wartungskosten (O&M).

Ziele

1. Wahl eines leistungsstarken API-Gateways, das den Anforderungen von iQIYI entspricht.
2. Minimierung der Migrationskosten.
3. Finden eines API-Gateways mit einer aktiven Community und einem gesunden Ökosystem.
4. Aufbau eines brandneuen API-Gateways, das dem Cloud-native-Trend entspricht.

Ergebnisse

1. Die Leistung verbesserte sich um das 10-fache im Vergleich zu vorher, wobei täglich Millionen von QPS bewältigt werden.
2. Einfache Unterstützung von über 9.000 API-Online-Geschäftsprojekten.
3. Erfolgreiche Realisierung der Daten-Notfallwiederherstellung mehrerer Standorte und Ebenen landesweit in China.

Was geschah hinter den Kulissen von iQIYI?

Cong He, Senior R&D Engineer bei iQIYI, hielt kürzlich einen Vortrag auf dem Apache APISIX Meetup in Shanghai. Er arbeitet im IIG-Infrastrukturteam der Computing Cloud und ist für die Entwicklung des Gateways und die Ops-Arbeiten bei iQIYI verantwortlich. Lassen Sie uns in seinen Vortrag und die Geschichte des API-Gateways von iQIYI eintauchen, um Apache APISIX besser zu verstehen.

Gegründet am 22. April 2010 von Baidu, dem Unternehmen hinter der größten chinesischen Suchmaschine, ist iQIYI derzeit eine der größten Online-Video-Plattformen der Welt, mit fast 6 Milliarden Stunden Nutzung pro Monat und über 500 Millionen monatlich aktiven Nutzern.

iQIYI entwickelte früher sein eigenes API-Gateway namens Skywalker, eine kundenspezifische Entwicklung basierend auf Kong. Skywalker muss heutzutage massiven Datenverkehr bewältigen, und der tägliche Spitzenwert des Gateway-Dienstes kann eine Million QPS und Tausende von API-Routen erreichen. Allerdings zeigen sich die Schwächen dieses Produkts allmählich.

1. Die Gateway-Leistung entspricht nicht mehr den Anforderungen von iQIYI, und es gibt täglich zahlreiche CPU-IDLE-zu-niedrig-Warnungen aufgrund des massiven Datenverkehrs.
2. Es gibt zu viele Abhängigkeiten von Komponenten in der Systemarchitektur.
3. Die Betriebs- und Wartungskosten (O&M) sind zu hoch.

Nach der Übernahme des Projekts in diesem Jahr begann Cong, ähnliche Gateway-Produkte zu untersuchen, um die oben genannten Probleme und Schwierigkeiten zu lösen, und fand schließlich Apache APISIX.

Wie übertrifft Apache APISIX Kong?

Bevor iQIYI Apache APISIX wählte, hatte das Unternehmen bereits mit Kong begonnen, gab es jedoch später auf.

Warum wurde Kong aufgegeben?

Nach der praktischen Anwendung von Kong erklärt Cong, warum sein Team Kong aufgegeben hat. Im Folgenden sind einige der Kernnachteile von Kong aufgeführt.

1. Die Routen von Kong verwenden Durchlaufabfragen, die nicht schnell sind.
2. Die Postgres-Datenbank von Kong führt zu aufgeblähter Bereitstellung, ineffizienter Synchronisierung und geringer Verfügbarkeit.
3. Der Code weist eine hohe Kopplung auf.

Warum wurde APISIX gewählt?

„Wir haben die Leistung von Apache APISIX und Kong während der Untersuchung verglichen und überraschenderweise festgestellt, dass Apache APISIX in Bezug auf die Leistungsoptimierung 10-mal besser war als Kong. Wir haben Apache APISIX auch mit einigen anderen großen Gateway-Produkten verglichen, und die Antwortlatenz von Apache APISIX ist immer mehr als 50 % niedriger als bei anderen Produkten. Darüber hinaus kann Apache APISIX auch dann stabil laufen, wenn die CPU-Auslastung mehr als 70 % erreicht. APISIX ist wirklich erstaunlich!“, sagte Cong.

Sowohl Apache APISIX als auch Kong wurden auf technischer Ebene auf OpenResty entwickelt, was relativ niedrige Migrationskosten mit sich bringt. Darüber hinaus verfügt Apache APISIX über eine hervorragende Anpassungsfähigkeit und kann leicht in vielen verschiedenen Umgebungen, einschließlich Cloud-Computing-Plattformen, bereitgestellt werden.

„Gleichzeitig haben wir festgestellt, dass Apache APISIX ein sehr aktives Open-Source-Projekt ist, das Probleme sehr schnell löst. Sein Cloud-native-Framework stimmt auch mit den Folgeplänen unseres Unternehmens überein. Daher haben wir Apache APISIX als unser API-Gateway gewählt.“

Die Innovation der API-Gateway-Architektur von iQIYI nach der Verwendung von APISIX

Nach der Wahl des großartigen API-Gateways begann iQIYI, seine neue API-Gateway-Architektur zu etablieren, die unten dargestellt ist, einschließlich Domain-Name, Gateway, Service-Instanzen und Monitoring-Alarm.

DPVS ist ein Open-Source-Projekt, das von iQIYI auf Basis von LVS entwickelt wurde. Der Hubble-Monitoring-Alarm ist ebenfalls eine tiefgreifende kundenspezifische Entwicklung auf Basis eines Open-Source-Projekts, und es wurden einige Optimierungen an der Leistung und Hochverfügbarkeit von Consul vorgenommen.

Erfolg 1: Verbesserung der Daten- und Steuerungsebenen für Cluster- und Dienstverwaltung

Die Datenebene ist hauptsächlich auf Frontend-Benutzer ausgerichtet, und die gesamte Architektur von LB bis Gateway verfügt über Multi-Site- und Multi-Link-Bereitstellungen für die Notfallwiederherstellung, sodass Benutzer auf ihr nächstgelegenes Rechenzentrum zugreifen können.

Für die Steuerungsebene gibt es eine Microservice-Plattform, um mehrere Cluster und Dienste zu verwalten. Die Microservice-Plattform ermöglicht es Benutzern, einen One-Stop-Service zu erleben, ohne Tickets einzureichen, was eine erhebliche Menge an Zeit spart. Im Backend steuert der Gateway-Controller hauptsächlich die Konfiguration aller APIs, wie z.B. die Erstellung von APIs und Plugins, während der Service-Controller die Registrierung, Kündigung und Gesundheitsprüfung handhabt.

Erfolg 2: Hinzufügung weiterer Funktionen: Sicherheitskontrolle, Ratenbegrenzung und Monitoring

iQIYI implementierte einige grundlegende Funktionen in der API-Architektur wie Ratenbegrenzung, Authentifizierung, Alarmierung, Überwachung usw., nachdem es sich an Apache APISIX angepasst hatte.

Der erste Teil betrifft HTTPS. Für die Sicherheitskontrolle speichert iQIYI keine Zertifikate oder Schlüssel auf den Gateway-Servern, sondern auf einem dedizierten Remote-Server. Es war jedoch schwierig, dies bei der Verwendung von Kong zu realisieren; stattdessen verwendete iQIYI das Präfix NGINX, um HTTPS-Entlastung durchzuführen. Nach der Migration zu Apache APISIX implementierte iQIYI diese Funktion erfolgreich auf Apache APISIX, was eine weitere Übertragungsebene über den Link einspart.

In Bezug auf die Ratenbegrenzung wurden neben den grundlegenden Ratenbegrenzungsfunktionen auch präzise Ratenbegrenzung und Ratenbegrenzung auf Benutzergranularität implementiert. Für die Authentifizierung wurden spezialisierte Dienste für die Passport-Authentifizierung bereitgestellt. Darüber hinaus kann iQIYI auf die WAF-Sicherheitscloud des Unternehmens zugreifen, um die Underground-Industrie herauszufiltern.

Die Monitoring-Alarm-Funktionalität wird durch die Verwendung des integrierten Plugins von Apache APISIX - Prometheus erreicht, und die Indikatordaten werden direkt an das Monitoringsystem des Unternehmens gesendet. Apache APISIX unterstützt iQIYI auch bei Protokollierungs- und Trace-Analyse-Diensten.

Erfolg 3: Etablierung eines dynamischen Dienstaktualisierungsprozesses

In Bezug auf die oben erwähnte Dienstermittlung werden Dienste hauptsächlich über das Service Center in Consul-Cluster registriert und dann über die DNS-Dienstermittlung dynamisch aktualisiert. QAE in der Grafik ist eine Microservice-Plattform, die intern in unserem Unternehmen verwendet wird. Lassen Sie uns anhand eines Beispiels den Prozess der Instanzaktualisierung kurz demonstrieren.

Bei der Aktualisierung der Instanzen werden wir zunächst entsprechende Knoten aus Consul abmelden und Aktualisierungsanfragen für den DNS-Cache über den API-Gateway-Controller an das Gateway senden. Wenn der Cache erfolgreich aktualisiert wurde, sendet der Controller Anfragen an die QAE-Plattform zurück, um alle zugehörigen Backend-Anwendungsknoten zu stoppen, um zu vermeiden, dass Datenverkehr an offline geschaltete Knoten weitergeleitet wird.

Erfolg 4: Verbesserung der Fähigkeit zur gerichteten Routen

Das Gateway verfügt über Multi-Site-Bereitstellungen, und ein vollständiger Satz von Multi-Site-Backup-Links wurde im Voraus aufgebaut. Darüber hinaus schlägt Cong vor, dass Benutzer Multi-Site-Nächstzugriffsbereitstellungen für ihren Backend-Dienst haben sollten. Somit könnten Benutzer einen API-Dienst in der Skywalker-Gateway-Plattform erstellen, und der Controller würde API-Routen an alle DC-Gateway-Cluster bereitstellen. Gleichzeitig wird der Standard-CNAME der Dienstdomain auf einen einheitlichen Gateway-Domain-Namen geroutet.

Apache APISIX könnte direkt Dienst mit Nächstzugriffs-Multi-Site-Bereitstellungen und Failover-Fähigkeit für die Notfallwiederherstellung bereitstellen und unterstützt benutzerdefinierte Routenauflösungen. Darüber hinaus könnten Benutzer die Konfiguration der Routenauflösung über die UUID-Domain anpassen, wenn sie Failover, Blue-Green-Deployment und Canary-Release benötigen. Zusätzlich unterstützt Apache APISIX auch die benutzerdefinierte Planung der Backend-Dienstwiederherstellung.

Erfolg 5: Verbesserung der Multi-Site- und Multi-Level-Notfalltoleranz

Um Situationen wie hohen Datenverkehr, zahlreiche Cluster und eine breite Kundschaft zu bewältigen, benötigt iQIYI Zugriff auf den nächstgelegenen Dienst und Notfallwiederherstellung auf Betriebsebene.

Zusätzlich zu Multi-Site- und Multi-Link-Backups für die Notfallwiederherstellung muss iQIYI auch die Probleme in Bezug auf Multi-Level- und Multi-Node-Situationen berücksichtigen. APISIX hilft dabei. Je näher die Clients an den toten Knoten sind, desto größer sind die Auswirkungen auf das Geschäft und den Datenverkehr.

1. Wenn der am weitesten entfernte Backend-Dienstknoten ausfällt, könnte iQIYI den Single-Node-Abbruch oder Failover des toten DC über das Service Center und den Gateway-Gesundheitscheck-Mechanismus erreichen. Somit wäre die Auswirkung auf bestimmte Dienste beschränkt, ohne Benutzer zu beeinträchtigen.
2. Wenn das Gateway ausfällt, könnte iQIYI den L4-DPVS-Gesundheitscheck-Mechanismus verwenden, um ausgefallene Gateway-Knoten abzuschalten, und die Auswirkungen sind relativ gering, ohne Benutzer zu beeinträchtigen.
3. Wenn die oben genannten Schutzmaßnahmen den toten Knoten nicht reparieren können, könnte iQIYI den automatischen Failover in DNS über die Multi-Node-Verfügbarkeitstests der Domain-Granularität im Extranet erreichen. Diese Methode ist jedoch relativ langsam und könnte viele andere Dienste beeinträchtigen, und Benutzer könnten dies bemerken.

Die Zukunftspläne von iQIYI

Bei der Integration mit APISIX versucht iQIYI, einige Probleme zu optimieren, um besser zu seinem Geschäft zu passen.

1. In Anbetracht der möglichen Engpässe einiger abhängiger Komponenten wie etcd, Prometheus-Monitoring und Protokollierungsdienst plant iQIYI, eine hybride Bereitstellungsmethode zu verwenden. Das heißt: Informationen innerhalb großer Cluster zu teilen und kleine Cluster unabhängig zu halten. Zum Beispiel werden wichtige Dienste mit kleinen Clustern bereitgestellt.

2. Es werden weitere entsprechende Reduktionen und Optimierungen für Prometheus-Monitoring-Metriken durchgeführt, insbesondere für die DNS-Dienstermittlung.

Cong sagte: „Wir hoffen, dass Apache APISIX in zukünftigen Entwicklungen und Updates mehr Funktionen unterstützen und eine hervorragende Leistungseffizienz sowie Stabilität beibehalten kann.“

Suchen Sie APISIX-Unterstützung?

Möchten Sie Ihre Entwicklung mit Zuversicht wie iQIYI beschleunigen? Um die APISIX-Unterstützung zu maximieren, benötigen Sie API7. Wir bieten umfassende Unterstützung für APISIX und API-Management-Lösungen basierend auf Ihren Anforderungen!

Kontaktieren Sie uns jederzeit: https://api7.ai/contact.