Wie integriert sich vivo mit APISIX?

Überblick

Seit Mai 2021 hat vivo Apache APISIX als sein API-Gateway eingeführt. Nach mehr als einem Jahr Praxis bei vivo hat APISIX viele technische und geschäftliche Herausforderungen gelöst und wird in großem Umfang eingesetzt.

Herausforderungen vor der Nutzung von APISIX

• Komplexes Management von Geschäftsszenarien und Systemwartung

  Aufgrund des rasanten Geschäftswachstums gibt es verschiedene Szenarien und Systeme, die diese bedienen, die vivo auf einheitliche Weise verwalten muss.

• Interaktion zwischen der Datenebene und der Steuerungsebene

  Für mittelständische und große Unternehmen wie vivo ist es unerwartet, dass kleinere Probleme in der Datenebene Auswirkungen auf die Steuerungsebene haben.

• Keine Unterstützung für mehrdimensionale Ressourcen

  Diverse Projekte führen zu verschiedenen Domainnamen und URLs. Die Geschäftsabteilung muss nach unterschiedlichen Ressourcendimensionen suchen.

• Unkontrollierbare Auswirkungen von Problemen

  Da die Projekte von vivo komplex sind, sind die Auswirkungen von auftretenden Problemen unkontrollierbar. Die Verwendung einiger komplizierter Plugins verstärkt dies.

Durch den Ersatz von NGINX durch APISIX hat vivo schließlich eine Reihe von Erfolgen erzielt, wie unten aufgeführt.

Erfolge nach der Nutzung von APISIX

• Hohe Verfügbarkeit

  Seit dem Start von APISIX bei vivo ist kein größerer Ausfall aufgetreten, und die Systemverfügbarkeit liegt über 99,99 %.

• Hohe Leistung

  Bei der Bewältigung eines erheblichen Online-Verkehrs und der Bereitstellung einer großen Anzahl von Diensten erreicht der aktuelle Online-Weiterleitungsverkehr fast eine Million QPS (Queries-per-second).

• Umfangreiche Funktionen

  Dank der umfangreichen Funktionen von APISIX kann APISIX fast alle gängigen NGINX-Proxy-Szenarien abdecken. Etwa 50 % der vivo-Projekte wurden von NGINX auf die APISIX-Cluster migriert.

• Unterstützung der Entwicklung und des Aufbaus von Cloud-Native

  Das K8s-Bare-Metal, das die Containerisierung unterstützt, hat einen Umfang von 10.000 erreicht. Etwa 40 % der Projekte wurden von Bare-Metal und virtuellen Maschinen auf die K8s-Container-Plattform migriert, was den Fortschritt der Containerisierung bei vivo unterstützt und fördert.

Systemdesign von vivo basierend auf APISIX

Als nächstes werfen wir einen Blick auf das Systemdesign von vivo nach der Einführung von APISIX.

Angepasste Architekturdarstellung auf APISIX

Aus dem obigen Diagramm können wir analysieren, dass vivo:

• Den Aufbau von Layer 4 und Layer 7 Verkehrsgateways abgeschlossen hat, die von APISIX unterstützt werden
• Den Verkehrszugang und die gemischte Bereitstellung von Bare-Metal, virtuellen Maschinen und Containern realisiert hat
• Das APISIX-Cluster-Management implementiert hat
• Die interne DevOps-Plattform und die Geschäftsbereitstellungsdienste verbunden hat, um den Verkehr schnell und automatisch zugänglich zu machen
• Die Überwachungskonstruktion verbessert hat

Konfigurationsmanagement und Veröffentlichungsverbesserungen

Um den tatsächlichen Anforderungen der Geschäftsabteilung besser gerecht zu werden, hat vivo eine Reihe von Anpassungen an APISIX vorgenommen. Nachfolgend sind einige dieser Anpassungen aufgeführt, darunter Änderungen an der Steuerungsebene, getrenntes Cluster-Management und Datenweiterleitung.

Änderungen an der Steuerungsebene

Der gesamte Prozess kann wie folgt ablaufen:

Nachdem die Daten in der A6-Änderungsplattform konfiguriert wurden, werden die Informationen über RPC-Benachrichtigungen an die ManagerAPI übermittelt, die von vivo auf der Grundlage des Open-Source-APISIX Dashboards erstellt wurde.

Dann wird der Verkehr an apisix-agent gesendet. APISIX fragt apisix-agent regelmäßig über den privilegierten Prozess ab, um Änderungsaufgaben in Batches zu erhalten. Anschließend benachrichtigt der privilegierte Prozess den worker über gemeinsame Warteschlangen, um die Änderung im Speicher zu realisieren.

In der Zwischenzeit informiert APISIX den apisix-agent über das Ergebnis der Aufgaben und liefert sie dann an die ManagerAPI. Darüber hinaus kann die A6-Änderungsplattform die ManagerAPI abfragen, um Aufgabenresultate zu erhalten.

Das etcd ist ein Highlight von APISIX, das den unabhängigen Betrieb der Steuerungs- und Datenebene ermöglicht. Aufgrund der Einzigartigkeit seiner Architektur hat vivo etcd im obigen Prozess verworfen. Hier sind einige Gründe.

Aufgrund der Vielfalt der Projekte von vivo gibt es verschiedene Domainnamen und URLs. Darüber hinaus müssen die Geschäftsabteilungen verschiedene Dimensionen abfragen. Dank der Anpassungsfähigkeit von APISIX, nicht nur mit etcd, sondern auch mit verschiedenen Datenbanken, konnte vivo leicht Datenbanken wie MongoDB nutzen, um mit APISIX zusammenzuarbeiten.

Darüber hinaus hat vivo die folgenden Beiträge geleistet, um mit Apache APISIX kompatibel zu sein.

• Entwicklung der Agent-Komponente

  Seit Mai 2021 hat vivo Apache APISIX eingeführt. Aufgrund des technischen Hintergrunds und Kontexts war vivo unsicher, ob es APISIX nicht nutzen könnte, da vivo keine Erfahrung mit OpenResty und Lua hat. Darüber hinaus gibt es viele nicht-weiterleitende Aufgaben wie die Protokollsammlung und die Überwachungsverarbeitung, die die Komplexität der Verwaltung der Datenebene erhöhen könnten. Folglich entwickelte vivo die Agent-Komponente, um die Komplexität der Entwicklung zu reduzieren.

• Schreiben von Daten auf die Festplatte

  Um das System anpassbar zu machen und die Datenebene unabhängig betreiben zu können, wodurch die Abhängigkeit von der Steuerungsebene verringert wird, schrieb vivo die Konfigurationsdatei auf die Festplatte. Wenn APISIX gestartet wird, unterstützt es das vollständige Abrufen aus dem Konfigurationszentrum und unterstützt auch das direkte Abrufen von Konfigurationsressourcen aus dem Dateiverzeichnis der lokalen Festplatte. Diese Methode verbessert die Unabhängigkeit der Daten und die Robustheit des Systems erheblich. Darüber hinaus ist es sehr intuitiv, die konfigurierte Route und Upstream-Informationen auf der Festplatte zu verstehen, was bei der Fehlerbehebung hilfreich ist.

• Rückruf des Änderungsaufgabenergebnisses

  Als großes Unternehmen muss vivo sicherstellen, dass Änderungen an Ressourcen wie Routern und Upstreams garantiert effektiv und erfolgreich sind und das System den Fehler melden kann, selbst wenn diese Änderungen fehlschlagen. Eine solche ACK-Logik (Acknowledgement Code) stellt sicher, dass NGINX-Worker auf einer Maschine zurückrufen können. Wenn die Rückrufaufgaben erfolgreich sind, werden alle Worker auf APISIX die Ressourcenänderungen in den relevanten Speicher aktualisieren.

Getrenntes Cluster-Management

Die Open-Source-Version von APISIX bietet etcd für alle zur gemeinsamen Nutzung an. Die Projekte des Unternehmens sind jedoch komplex, und die auftretenden Probleme sind unkontrollierbar. Darüber hinaus ist die Verwendung komplizierter Plugins unvermeidlich, was die Leistung des Systems beeinträchtigt.

Daher wird es durch getrenntes Cluster-Management verwaltet, um die Isolierung der Cluster-Konfiguration auf APISIX zu realisieren, was folgendes ermöglicht:

• Die Fehlerdomäne zu kontrollieren und die Komplexität der Projekte effektiv zu unterstützen, ohne andere Projekte zu beeinträchtigen
• Die Last, die durch die APISIX-Nicht-Weiterleitungsebene verursacht wird, effektiv zu reduzieren, wenn die Container-Knoten häufig wechseln
• Die Lastauswirkung durch die Gesundheitsprüfung zu reduzieren

Erhöhung der von HTTPS getragenen QPS

Gemäß den relevanten Anforderungen des Ministeriums für Industrie und Informationstechnologie in China muss der externe Netzwerkverkehr über das HTTPS-Protokoll laufen. Als ein auf TLS basierendes HTTP-Verschlüsselungsprotokoll belastet HTTPS die CPU stark im Verschlüsselungs- und Entschlüsselungsprozess.

Wenn die Routing- und anderen Konfigurationen gleich sind, beträgt der Verkehr, den HTTPS tragen kann, etwa 1/8 - 1/10 des HTTP-Verkehrs.

Nach dem Patchen der Intel® QAT (QuickAssist Technology) Beschleunigerkarte überträgt vivo die Entschlüsselungsverarbeitung auf die QAT-Beschleunigerkarte, wodurch die CPU entlastet wird und somit die von HTTPS auf einer einzelnen Maschine getragene QPS erhöht wird. Wie aus der folgenden Abbildung ersichtlich ist, verdoppelt sich die HTTPS-Lastkapazität einer einzelnen Maschine etwa.

Wie kombiniert vivo Geschäfte mit APISIX

Unterstützung der Containerisierungsentwicklung

Um die Containerisierungsentwicklung zu unterstützen, hat vivo einen K8s-Ingress-Controller selbst entwickelt. Nachfolgend sind einige Funktionen davon aufgeführt.

1. Anpassung an den von vivo modifizierten asynchronen Push-Konfigurationsänderungsmechanismus

2. Durchführung von Multi-K8s-Cluster-Ereignisverarbeitungsbenachrichtigungen an APISIX

3. Bewältigung komplexer Projektszenarien wie:

• Ein Server mit mehreren Ports

• Wenn andere RPC-Framework-Server wie Dubbo und gRPC mit K8s verbunden sind, ist eine einheitliche Verarbeitungslogik erforderlich, um APISIX oder andere Frameworks gemäß den Konfigurationsmerkmalen der Projekte über Portinformationen zu informieren

4. Anpassung an die besonderen Anforderungen der internen DevOps- und anderen Automatisierungsszenarien des Unternehmens, Erleichterung der schnellen Bereitstellung und Aktivierung des Verkehrs

Unterstützung der Migration von Projekten von NGINX zu APISIX

Die Projekte von vivo sind auf dem bestehenden NGINX-Cluster bereitgestellt und laufen seit langem stabil. Es bringt jedoch nicht-geschäftliche Arbeitslasten und Instabilität in die Projekte. Folglich ist die Migration schwierig. Wie fördert man also die Migration von Projekten zu APISIX?

• Zuerst ein Projekt einer kooperativen Abteilung finden, die Geschäftsabteilung gut bedienen, um einen Benchmark zu setzen, und technische Anleitung und Schulung bereitstellen

• Ein benutzerfreundliches Steuerungsebenensystem aufbauen, um den Geschäftszugang und die mehrdimensionale Verwaltung der Geschäftsabteilungen zu erleichtern

• Automatische Konvertierungsfähigkeit und grundlegende Konfiguration bereitstellen, um von der NGINX-Konfiguration zur APISIX-Konfiguration zu konvertieren

Aktualisierung von APISIX und Unterstützung seiner Open-Source-Version

Basierend auf der APISIX 2.4-Version hat vivo einige Anpassungen vorgenommen und die neue Version veröffentlicht, die im zweiten Quartal dieses Jahres auf eine neuere Version aktualisiert wurde.

Einerseits ist es dank der modularen Architektur von APISIX relativ einfach, den von vivo modifizierten Lua-Code in den Zweig der höheren Version von APISIX zu integrieren. Andererseits aktualisiert vivo auch den OpenResty-Abschnitt, mit etwa einer Version pro Jahr. Da vivo viele PATCHs und einige nützliche Funktionen wie QAT nutzt, ist die Aktualisierung dieser Komponente schwierig und arbeitsintensiv.

Die Community-Funktionen der kostenlosen Version von NGINX werden langsam aktualisiert und sind inaktiv. Vivo überlegt, ob es gemeinsam mit APISIX aufbauen soll. Um den Personalbedarf für die Durchführung verwandter Systemtests zu reduzieren, hat vivo Robot Framework, ein generisches Testautomatisierungsframework für Systemintegrationstests, übernommen. Sie fördern die relevanten Komponenten für die Unit-Test-Abdeckung und das Entwicklungsmodell von TDD (Test-driven development).

Zukunftsplanung von vivo

Im nächsten Jahr plant vivo, APISIX als Verkehrsgateway zu einem API-Gateway zu erweitern, indem es seine Vorteile wie Ratenbegrenzung, Authentifizierung, Circuit Breaking usw. nutzt. In Betracht der Kombination von APISIX mit DPDK-NGINX wird vivo auch technisches Personal ausbilden und sich am Community-Aufbau beteiligen. Darüber hinaus wird es die Grundlagenkenntnisse konsolidieren, um eine gute Grundlage für den Aufbau von Verkehrs- und Dienstegestaltung zu schaffen.

Willkommen, mehr über Apache APISIX zu erfahren.

Sie können uns unter https://api7.ai/contact kontaktieren.