Dynamic

Rich Features

Cluster Management

Go for Apache APISIX

Looking for the best API Gateway?

Built on NGINX, with more features than NGINX.

 Many companies have migrated from NGINX to Apache APISIX, immediately achieving fast growth and reducing operational costs.

Apache APISIX vs NGINX:

## Überblick

Als weltweit führender Anbieter von Unternehmens- und Konsortiums-Blockchain-Infrastrukturen und Lösungen ist [Hyperchain Technologies](https://www.hyperchain.cn/en/about/company) bestrebt, innovative Infrastrukturen aufzubauen und die digitale Entwicklung der Gesellschaft zu fördern. Während seines rasanten Wachstums stieß Hyperchain bei der Einrichtung seiner Hyperchain-Blockchain-Plattform auf zahlreiche Probleme, wie folgt:

- Kein standardisiertes Traffic-Management mit dem potenziellen Risiko eines Systemzusammenbruchs
- Unvollständige Sicherheitskontrolle und Authentifizierungsverwaltung
- Unbequeme Berechtigungskontrolle
- Hohe Kosten für öffentliche Netzwerk-IP-Adressen
- Instabile Blockchain-Knoten: Einzelne Knoten sind anfällig für Angriffe
- Fehlende einheitliche Verwaltung mehrerer Protokolle

Hyperchain probierte Kong und NGINX aus, aber leider konnten diese die Geschäftsszenarien von Hyperchain nicht zufriedenstellend abdecken. **Nach der Einführung von Apache APISIX wurden jedoch alle oben genannten Probleme gelöst, wodurch die Hyperchain-Blockchain-Plattform mit unendlicher Vitalität ausgestattet wurde.**

### Über die Hyperchain-Blockchain-Plattform

Die Hyperchain-Blockchain-Plattform bezieht sich auf die Einbettung des Blockchain-Frameworks in die Cloud-Computing-Plattform, wobei die Vorteile der Cloud-Service-Infrastruktur in Bezug auf Bereitstellung und Verwaltung genutzt werden. Es handelt sich um eine offene Blockchain-Plattform, die Entwicklern ein bequemes und leistungsstarkes Blockchain-Ökosystem sowie unterstützende Dienstleistungen bietet und auch die Geschäftserweiterung und den Betrieb von Entwicklern in Web3 unterstützt.

**Die Hyperchain-Blockchain-Plattform kann das Blockchain-Netzwerk schnell und flexibel aufbauen. Mit der Plattform können Unternehmen das Blockchain-Geschäft einheitlich verwalten.** Beispielsweise können wir über die Plattform Verträge in der integrierten Entwicklungsumgebung unterzeichnen und diese dann in unserem erstellten Blockchain-Netzwerk bereitstellen. Das übergeordnete Dienstmodul kann blockchain-bezogene Verträge aufrufen, um den Geschäftsprozess fortzusetzen.

Da es viele Knoten in der Kette gibt, die von Dutzenden bis zu Tausenden reichen, wird es für uns schwierig, den Betrieb der Kette ohne die Unterstützung der Plattform zu überwachen und zu warten. **Durch die Nutzung der Hyperchain-Blockchain-Plattform können Benutzer nicht nur Kosten sparen, sondern auch die Blockchain bequemer verwalten und die Sicherheit des gesamten Systems verbessern.**

Lassen Sie uns Hyperchain als Beispiel nehmen, um herauszufinden, wie und warum Blockchain-Unternehmen Apache APISIX unter vielen API-Gateways auswählen sollten. Im Folgenden werden wir die Anwendung von APISIX sowohl in der Hyperchain-Blockchain-Plattform als auch im Blockchain-Knoten analysieren.

## APISIX’s Anwendung in der Hyperchain-Blockchain-Plattform

Unten ist ein Anwendungsinteraktionsdiagramm von APISIX in der Hyperchain-Blockchain-Plattform dargestellt. Der Backend-Dienst registriert die Dienstinformationen bei etcd entsprechend seinen Geschäftsmerkmalen und registriert dann den Dienst bei APISIX über das Routenregistrierungsmodul.

APISIX fungiert als einheitlicher Einstiegspunkt für interne Microservices im System. Externe Anfragen werden zunächst an APISIX gesendet; dann besuchen sie die Zugriffsschicht über die API, nachdem sie die Authentifizierung bestanden haben, und später besuchen sie die Kernservices über RPC (Remote Procedure Call).

![Hyperchain-Anwendungsinteraktionsdiagramm](https://static.api7.ai/2022/11/15/637335a53d73c.png)

### Routenweiterleitung

Manchmal sollen APIs unter demselben Domainnamen verfügbar gemacht werden. In diesem Fall können wir einige Präfixe zum API-Pfad desselben Dienstes hinzufügen, wie z.B. `/baas-core` oder `/baas-other`. Wenn der Client diese APIs anfordert, muss das API-Gateway diese hinzugefügten Präfixe entfernen und die Anfrage dann an den Backend-Dienst weiterleiten. Das [proxy-rewrite-Plugin](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/) von APISIX kann uns dabei helfen, solche Fälle bequem zu handhaben.

Beispiel:
Wenn Sie besuchen: http://apisix:8080/baas-{service}/api/v1/…
Kann die Anfrage an http://{service}/api/v1/… weitergeleitet werden
durch das Schreiben eines regulären Ausdrucks: `^/baas-core/(.*)$,/$1`

![proxy-rewrite-Plugin-Bearbeitung](https://static.api7.ai/2022/11/15/637335b538dc0.png)

### Traffic-Limit-Management

Benutzer können Konsortiums-Blockchains nach ihren Bedürfnissen auswählen, nicht nur die von Hyperchain, sondern auch IBM Data Fabric, Baidu XuperChain usw. Daher muss Hyperchain den Lebenszyklus aller Konsortiums-Blockchains im System verwalten.

Bei der Erstellung einer Konsortiums-Blockchain muss Hyperchain nur den Hardcode auf der Blockchain-Plattform schreiben und die steckbaren Treiberkomponenten auf die Blockchain-Plattform hochladen, um die Konsortiums-Blockchain zu erstellen. In einigen privaten Bereitstellungsfällen können die steckbaren Treiberkomponenten schnell unterstützen.

Jeder Aufruf der Treiberkomponenten ist ein Prozess, der begrenzt werden muss, insbesondere wenn die Anzahl groß ist. Folglich kann das [limit-req-Plugin](https://apisix.apache.org/docs/apisix/plugins/limit-req/) von APISIX nützlich sein, um den Traffic-Eingang und -Ausgang der Plattform zu begrenzen und so deren Stabilität zu sichern.

Das limit-req-Plugin ermöglicht eine benutzerdefinierte Konfiguration von Rate und Burst.

![limit-req-Plugin-Modell](https://static.api7.ai/2022/11/15/637335b790f49.jpeg)

### Sicherheitskontrolle und Berechtigungsverwaltung

Um mit APISIX zusammenzuarbeiten, entwickelte Hyperchain ein Plugin für private Bereitstellungsumstände. Partei A bevorzugt oft die Nutzung ihrer eigenen Authentifizierungsdienste oder Dienstkontensysteme. Wenn der Frontend-Traffic die Website besucht, durchläuft er zunächst das Access-auth-Plugin und kann nur dann auf das Backend BFF (Backend for Frontend) zugreifen, wenn die Authentifizierung bestanden wurde.

![Authentifizierungsprozessdiagramm](https://static.api7.ai/2022/11/15/637335b994030.png)

Gemäß den drei Schlüsselfaktoren der Restful-Standardspezifikation (die Authentifizierungsinformationen, der Restful-Pfad und HTTP-Verben wie GET, POST, PUT, DELETE, PATCH usw.) wird eine Konto-Rolle-Berechtigungsauthentifizierung durchgeführt. Wenn die Authentifizierung bestanden wird, werden die Benutzerinformationen im Header zurückgegeben; wenn nicht, wird 403 zurückgegeben.

![API-Authentifizierungspfad](https://static.api7.ai/2022/11/15/637335bd3e080.png)

### Hot Reloading

APISIX bietet [Hot Reloading](https://apisix.apache.org/docs/java-plugin-runner/hot-reloading/) von intern entwickelten Plugins an. Es spart Zeit während der Entwicklung und ermöglicht Benutzern, Teile ihres Codes zu ändern, ohne den gesamten Plugin-Runner neu zu starten. Auf diese Weise können Entwickler Anpassungen an der Schnittstelle im Backend vornehmen, die sofort wirksam werden, was für Online-Veröffentlichungen bequem und benutzerfreundlich ist.

### Warum nicht Kong?

Hyperchain hatte zuvor Kong verwendet, ersetzte es jedoch schließlich durch Apache APISIX, hauptsächlich weil

- **Hohe Bereitstellungs- und Wartungskosten**

    Der Kong-Cluster muss mit der Postgresql-Datenbank zusammenarbeiten und erfordert einen spezifischen Datenbankadministrator für hohe Verfügbarkeit. Die Cluster-Bereitstellung der Postgresql-Datenbank ist relativ schwierig zu implementieren und erhöht die Kosten für den späteren Betrieb und die Wartung.

- **Erhöhung der Systemkomplexität und der Ausfallrate**

    Die Hyperchain-Blockchain-Plattform verwendet die MySQL-Datenbank, was zu zwei relationalen Datenbanken im System führt, wenn Kong verwendet wird, was das System komplizierter macht. Es erhöht auch die Ausfallrate bei der Verbesserung der Kompatibilität zwischen den beiden Datenbanksätzen.

## APISIX’s Anwendung im Blockchain-Knoten

![Hyperchain-Blockchain-Diagramm](https://static.api7.ai/2022/11/15/637335bfa08dc.png)

### Kostenersparnis bei öffentlichen Netzwerk-IP-Adressen

Der Benutzer kauft Blockchains über die Hyperchain-Blockchain-Plattform. Dann können die übergeordneten Geschäfte und Entwicklerclients eine Verbindung zu den Knoten herstellen. Die Dienste können eine Verbindung zu einem oder mehreren Knoten herstellen, und die Benutzer können auf einen oder mehrere Knoten zugreifen, was ein Problem mit sich bringt: Fast alle Knoten werden besucht, was den Besuchsdruck eines einzelnen Knotens erhöht.

In einigen privaten Beschäftigungsumgebungen ist dies relativ einfach zu handhaben. Für Systeme, die auf Internetnutzer abzielen, sind jedoch zu viele Knoten und öffentliche Netzwerk-IPs erforderlich. Der Preis für jede öffentliche Netzwerk-IP von 4 Megabyte Traffic kann fast 200 CNY pro Monat erreichen. Es gibt Tausende von Knoten auf der Hyperchain-Plattform, was hohe öffentliche IP-Kosten verursacht.

APISIX verwaltet alle Besuchsanfragen und verteilt den Traffic auf die entsprechenden Blockchain-Knoten. Auf diese Weise sparte Hyperchain hohe Kosten.

![Hyperchain-Modus mit APISIX](https://static.api7.ai/2022/11/15/637335c23f4f8.png)

### Bequeme Berechtigungskontrolle

Es gibt verschiedene Blockchains auf der Hyperchain-Blockchain-Plattform, und jede Kette hat verschiedene komplizierte RBAC-Berechtigungskontrollen. Daher müssen verschiedene Arten von Zertifikaten auf der Client-Seite hinzugefügt werden, wie z.B. TLS-Zertifikate, was auch Benutzer verwirrt.

Derzeit kann das [key-auth-Plugin](https://apisix.apache.org/docs/apisix/plugins/key-auth/) von APISIX verwendet werden, um dieses Problem effizient zu lösen. Autorisierte Benutzer können direkt auf die Blockchain zugreifen, ohne sich um die Berechtigungskonfiguration zu kümmern, da APISIX die zugrunde liegende Kette vereinheitlicht.

### Clustering verbessert die Knotenstabilität

Wie oben erwähnt, werden die Knoten häufig besucht. Bei den meisten Bankbenutzern besteht eine hohe Parallelität, da die TPS (Transaktionen pro Sekunde) 40.000-50.000 Mal erreichen kann.

Es stellt sich heraus, dass ein einzelner Knoten auf der Blockchain anfällig ist, da jede Transaktion den besuchten Knoten beeinflusst.

Hyperchain hat Apache APISIX auf K8s mit dem Horizontal Pod Autoscaler bereitgestellt. Da APISIX etcd mit guter dynamischer Skalierbarkeit verwendet, kann es das Problem des Einzelpunkt-Traffic-Impacts effektiv lösen.

### Unterstützung mehrerer Protokolle

Die Protokolle der heterogenen Ketten auf der Hyperchain-Blockchain-Plattform sind vielfältig, wie z.B. HTTP-Protokoll, Websocket-Protokoll, gRPC-Protokoll, TCP-Protokoll, UDP-Protokoll usw.

APISIX unterstützt mehrere Protokolle und passt sich flexibel den zugrunde liegenden Schichten verschiedener Blockchains an, wodurch die Entwicklungskosten reduziert werden.

### Warum nicht NGINX?

Es scheint, dass Hyperchain NGINX nutzen könnte, um seine Probleme zu lösen. Nach dem Test gab Hyperchain es jedoch auf, weil

- **Ungeeignet für dynamische Erweiterung**

    Hyperchain muss häufig Knoten in der Blockchain-Plattform hinzufügen und löschen, was erst nach einem Neustart wirksam wird, was für Entwickler unbequem ist. Darüber hinaus müssen Entwickler komplexen Regelcode für Plugins in der conf-Datei von NGINX schreiben.

- **Schwierig zu clustern**

    NGINX unterstützt kein Clustering, was relativ komplex und unfreundlich für Benutzer ist.

- **Keine direkte Unterstützung für TCP und UDP**

    NGINX kann nur das 7-Schichten-Protokoll und nicht das 4-Schichten-Protokoll proxyen und kann TCP- und UDP-Protokolle nicht direkt unterstützen. Darüber hinaus ist das Modul nicht standardmäßig kompiliert und erfordert eine zusätzliche Verarbeitung.

- **Kein Dashboard**

    Es gibt keine visualisierte Schnittstelle für NGINX, was es für Entwickler und Betreiber schwierig macht, so viele Knoten zu verwalten.

## Zusammenfassung

Aus den oben genannten Inhalten wissen wir, dass Apache APISIX ein dynamisches API-Gateway ist, das im Blockchain-Bereich angewendet werden kann. Darüber hinaus bietet Apache APISIX umfangreiche Traffic-Management-Funktionen wie Lastenausgleich, dynamisches Upstream, Canary-Release, Circuit Breaking, Authentifizierung, Beobachtbarkeit usw.

Wir hoffen, dass APISIX mehr Blockchain-Unternehmen unterstützen kann, um in eine weitere Entwicklungsphase einzutreten.
Willkommen, um mehr über Apache APISIX zu erfahren.
Sie können uns unter https://api7.ai/contact kontaktieren.


Wie das Blockchain-Unicorn-Unternehmen Hyperchain den Open-Source-API-Gateway APISIX nutzt, um die Hyperchain Blockchain Platform zu stärken und Blockchain-Datenverkehr in Web3 zu verwalten, unter Erwähnung des Vergleichs zwischen APISIX, Kong und NGINX.

API Gateway für Web3: Wie APISIX Hyperchain stärkt

## Überblick

Seit Mai 2021 hat [vivo](https://www.vivo.com/en) [Apache APISIX](https://apisix.apache.org/) 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](https://apisix.apache.org/blog/2022/11/02/apache-apisix-v3-preview/) 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

![vivo's API gateway architecture with APISIX](https://static.api7.ai/2022/11/23/637dc2f51318e.jpg)

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](https://github.com/apache/apisix-dashboard) 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.

![vivo's management and publishing mode](https://static.api7.ai/2022/11/25/638036da44e7f.jpeg)

Das [etcd](https://etcd.io/docs/v3.5/learning/why/#comparison-chart "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

![Cluster Split Management](https://static.api7.ai/2022/11/25/6380381595b00.jpeg)

Die Open-Source-Version von APISIX bietet [etcd](https://apisix.apache.org/docs/apisix/FAQ/#why-does-apache-apisix-use-etcd-for-the-configuration-center) 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**.

![data showing vivo's improvment on carrying traffic](https://static.api7.ai/2022/11/23/637dc306a5fa1.jpg)

## 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](https://apisix.apache.org/blog/2022/09/13/why-is-apache-apisix-the-best-api-gateway/) als Verkehrsgateway zu einem API-Gateway zu erweitern, indem es seine Vorteile wie [Ratenbegrenzung](https://apisix.apache.org/docs/apisix/plugins/limit-count/#attributes), [Authentifizierung](https://apisix.apache.org/docs/ingress-controller/tutorials/mtls/), 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](https://api7.ai/contact) kontaktieren.


Wie nutzt der bekannte Mobilgerätehersteller vivo APISIX als API-Gateway und passt es an seine Geschäftsanforderungen an?

Wie integriert sich vivo mit APISIX?

## Hintergrund

In den letzten Jahren sind viele bekannte Online-Konferenzsoftwarelösungen mit der Entwicklung von Online-Meetings und Remote-Arbeit entstanden. Das typische Beispiel, Zoom, ist zu einem beliebten Meeting-Tool für Homeoffice, Online-Lehre und soziale Szenarien geworden. Es hat 350 Millionen tägliche Meeting-Teilnehmer und fast 470.000 zahlende Geschäftskunden, die die Plattform nutzen. Darüber hinaus zeigen aktuelle Daten, dass die Anzahl der Minuten, die für die Meeting-Facilitation verwendet werden, mehr als 3,3 Billionen pro Jahr erreicht hat.

Allerdings hat Zoom, wie andere SaaS- und Internetunternehmen, technische Herausforderungen erlebt, da sein Geschäft schnell wächst.

- **Eine beträchtliche Anzahl von Microservices**: Aufgrund des schnellen Wachstums von Zooms Geschäft und Teams müssen über 100 Backend-Services bereitgestellt werden. Es ist jedoch schwierig, eine große Anzahl von Microservices effizient zu verwalten.

- **Verschiedene Bereitstellungsumgebungen**: SaaS-Unternehmen stoßen oft auf Szenarien, in denen Kunden auf dedizierten Clouds, privaten Clouds und Multi-Clouds bereitstellen müssen. Zooms Geschäftsdienste sind weltweit verteilt, daher gibt es technische Herausforderungen mit einer großen Anzahl von Hybrid-Cloud-Umgebungen.

- **Komplexe Infrastruktur**: Mittelgroße und große Internetunternehmen haben in der Regel dedizierte Infrastrukturteams, die für API-Gateways, Konfigurationszentren, Schlüsselverwaltung, Protokolle, Überwachungsalarme, Datenbanken usw. verantwortlich sind.
Da Zooms verteilte R&D-Teams global agieren, ist es eine große Herausforderung, diese komplexen Middleware- und Infrastrukturkomponenten in die kontinuierliche Lieferpipeline zu integrieren.

**Die oben genannten Herausforderungen sind keine einfache additive Beziehung, sondern eine multiplikative. Mit anderen Worten, die tatsächliche Situation ist weitaus komplexer.** Die Open-Source-Tools, die Zoom bisher verwendet hat, können jedoch Zooms aktuellen Anforderungen nicht mehr gerecht werden. Deshalb ist eine zuverlässige kontinuierliche Lieferpipeline so wichtig.

Im Folgenden sind die detaillierten Gründe aufgeführt, warum Zoom sich nicht weiter für diese bisherigen Open-Source-Tools entschieden hat.

| Helm/Kustomize  | Terraform/Pulumi  | KubeVela + Crossplane  |
| ------------ | ------------ | ------------ |
| Kann keine Systeme außer Kubernetes verbinden  | Schwierig, Terraform in der Kubernetes- und Middleware-Schicht zu verwenden, es sei denn, es werden zusätzliche Provider entwickelt  | Zu neue Technologie mit schnellen Updates, nicht sicher und stabil genug für die Produktionsumgebung  |
| Schwierig, die Plattform im Git-Sub-Repository-Modus zentral zu steuern  | Erhöht die Kosten für das Erlernen einer weiteren Konfigurationsmanagement-Sprache: hcl  | Kubevelas Definition von Trait + Cuelang-Vorlagen und seine Programmierausdrucksfähigkeiten reichen nicht aus, um verschiedene nicht-cloud-native Middleware-Plattformen außerhalb des Kubernetes-Systems abzudecken  |
| Schwierig zu warten und zu debuggen aufgrund der komplexen Logik der Helm Chart-Vorlagen  | Mono Repo zentrale Steuerung ist für große Teams ungeeignet  | /  |
| Kein leistungsfähiges Parametersystem, um dynamische Parameter in einer großen Anzahl von Umgebungen zu verwalten  | /  | /  |

Aufgrund der Einschränkungen der oben genannten Open-Source-Tools hat Zoom schließlich einige Mainstream-Lösungen für den Aufbau der zugrunde liegenden kontinuierlichen Lieferpipeline untersucht.

Nach einigen Runden von Vergleich und Verifizierung hat sich Zoom schließlich für den APISIX Ingress Controller entschieden, um seine neue kontinuierliche Lieferpipeline zu unterstützen.

## Apache APISIX Ingress Controller

### Was ist der Apache APISIX Ingress Controller?

[Apache APISIX Ingress Controller](https://github.com/apache/apisix-ingress-controller) ist ein Cloud-nativer Ingress-Controller, der Apache APISIX als Datenebene verwendet, um den Datenverkehr zu tragen, und die Funktionalität von Kubernetes durch die Verwendung von CRD (CustomResourceDefinition) erweitert. Er ist dafür verantwortlich, mit dem Kubernetes API-Server zu interagieren, rollenbasierte Zugriffskontrolle (RBAC) zu beantragen, Änderungen zu überwachen, Objektkonvertierungen innerhalb des Ingress-Controllers zu implementieren, die Änderungen zu vergleichen und dann mit Apache APISIX zu synchronisieren. Darüber hinaus kann er benutzerdefinierte Ressourcen unterstützen, einschließlich APISIX Route, APISIX Upstream und andere native Ingresses von Kubernetes, um den externen Datenverkehr zu steuern, der auf in Kubernetes bereitgestellte Dienste zugreift.

Unten ist das [Timing-Diagramm des APISIX Ingress Controllers](https://apisix.apache.org/docs/ingress-controller/design/#timing-diagram).

![Timing-Diagramm von APISIX Ingress](https://static.api7.ai/2022/10/27/635a5613af56a.jpeg)

## Warum wählt Zoom den APISIX Ingress Controller?

Vor dem oben genannten Hintergrund stellt sich die Frage: Welche Art von kontinuierlicher Lieferpipeline möchte Zoom aufbauen, und wie nutzt es APISIX Ingress, um seine zugrunde liegende kontinuierliche Lieferpipeline zu etablieren?

Zoom hat zuvor NGINX als API-Gateway verwendet. Mit der raschen Entwicklung des Geschäfts und der Zunahme von Microservices werden jedoch die Grenzen der aktuellen NGINX-Lösung immer deutlicher.

Verschiedene Teams müssen NGINX separat pflegen, und Tausende von Zeilen NGINX-Konfigurationsdateien machen die Wartung schwierig. Darüber hinaus kann NGINX nicht schnell skaliert werden, wenn viele Zeilen auf dem Cloud-Server bereitgestellt werden. Über den Reload-Modus von NGINX können Sie [diesen Blog](https://api7.ai/blog/how-nginx-reload-work) lesen. Zooms Geschäfte begannen sich in Richtung Ingress Controller zu entwickeln.

Das API-Gateway-Team hat einige Open-Source-Lösungen untersucht. Nach der Simulation der Migration und Analyse der tatsächlichen Geschäftskonfiguration in NGINX und einer großen Anzahl von Benchmark-Tests der Leistung und des Plugin-Ökosystemvergleichs hat sich Zoom schließlich für das APISIX Ingress Controller-Projekt der Apache Software Foundation entschieden, um ein fortschrittlicheres Cloud-Native-Gateway zu erkunden.

Unter Berücksichtigung seiner Geschäftsszenarien legte Zoom mehr Wert auf die folgenden beiden Teile, die von APISIX Ingress erfüllt werden können.

- **Datensicherheit**: Zoom nimmt die Privatsphäre der Kunden und die Dienstsicherheit ernst; daher werden mTLS-Authentifizierung und -Verifizierung weitgehend in Online-Meetingräumen und Telefonanrufen verwendet. Dennoch können viele ähnliche API-Gateways einen solchen Service nur in ihrer Enterprise-Version anbieten, während APISIX Ingress große Machbarkeit und Bequemlichkeit bietet, um dieses Ziel zu erreichen.

- **Dienststabilität**: Zooms Backend-Dienste erfordern Multi-AZ (Multi-Availability Zones)-Bereitstellungen für hohe Verfügbarkeit in verschiedenen Regionen. Im Allgemeinen werden die Geschäfte in anderen Rechenzentren platziert. Wenn ein Fehler im ursprünglichen Rechenzentrum auftritt, muss der Client-Datenverkehr in ein anderes transformiert werden, was APISIX Ingress erfolgreich erfüllen kann.

### Funktionen des Apache APISIX Ingress Controllers

Da Apache APISIX als Datenebene verwendet wird, um den Geschäftsverkehr zu tragen, erbt der Apache APISIX Ingress Controller die folgenden Vorteile von Apache APISIX.

- **Hohe Leistung und Stabilität**: Als hochleistungsfähiges dynamisches Open-Source-API-Gateway ist Apache APISIX in seiner Leistung widerstandsfähig und stabil und wird in vielen [großvolumigen Verkehrsszenarien von Unternehmen](https://apisix.apache.org/blog/tags/case-studies/) verwendet.

- **Aktive Community**: Als Top-Level und das aktivste Open-Source-API-Gateway-Projekt verfügt Apache APISIX über eine aktive Community und hat seit dem ersten Tag eine hervorragende Wachstumsrate beibehalten.

- **Reiches Ökosystem**: Apache APISIX unterstützt L7-Protokolle, einschließlich HTTP(S), HTTP2, Dubbo, IoT-Protokoll MQTT usw. Darüber hinaus unterstützt APISIX L4-Protokolle wie TCP/UDP. Außerdem wird in Apache APISIX 3.0 die volle Unterstützung von ARM64 unterstützt.

- **Mehrere Plugins**: Es gibt fast 100 Plugins, die von APISIX offiziell veröffentlicht wurden und die Benutzer durch einfaches Ziehen verwenden können. Das Hot-Reloading und die dynamische Orchestrierung von Plugins bieten den Benutzern große Bequemlichkeit.

Darüber hinaus hat der APISIX Ingress Controller auch die folgenden einzigartigen Vorteile:

- **Gute Kompatibilität**: Der APISIX Ingress Controller unterstützt mehrere Versionen von Ingress-Ressourcen und kann mit verschiedenen Kubernetes-Versionen kompatibel sein.

- **Dynamische Aktualisierung**: Es ist kein Neuladen des Dienstes erforderlich, wenn Routen, Zertifikate und andere Konfigurationen geändert werden, was den reibungslosen Betrieb des Geschäfts gewährleistet.

- **Flexible Skalierung**: Da der APISIX Ingress Controller eine Struktur verwendet, die die Steuerungsebene und die Datenebene trennt, kann die Datenebenen-Cluster von Apache APISIX unabhängig erweitert werden, ohne den APISIX Ingress Controller zu skalieren.

![APISIX Ingress Controller Architektur](https://static.api7.ai/2022/10/27/635a56148940c.jpeg)

- **Freundlich für Betrieb und Wartung**: Unter der aktuellen Architektur können Benutzer je nach tatsächlicher Situation wählen, ob sie die Datenebenen-APISIX-Cluster im Kubernetes-Cluster oder in der physischen Bare-Metal-Maschinenumgebung bereitstellen möchten. Darüber hinaus führt die architektonische Trennung des APISIX Ingress dazu, dass APISIX auf der Datenebene den Datenverkehr trägt, während der APISIX Ingress Controller die Steuerungsebene ist. Daher hat ein Ausfall des APISIX Ingress Controllers keine Auswirkungen auf den Geschäftsverkehr.

Nachdem die Gateway-Auswahl abgeschlossen war, stand das API-Gateway-Team vor einer neuen Herausforderung: Wie kann die ursprüngliche API-Gateway-Konfiguration von Hunderten von Diensten auf APISIX Ingress migriert werden? Zooms Infrastrukturteam entwickelte die kontinuierliche Lieferpipeline, die die Migrationskosten für die Umwandlung von nginx.conf und anderen Ingress-Konfigurationen in APISIX Ingress erheblich reduzieren kann.

## Der Prozess und die Funktionen des Aufbaus der kontinuierlichen Lieferpipeline

### Zooms kontinuierliche Lieferpipeline

Die kontinuierliche Lieferpipeline ist ein End-to-End-Anwendungslieferungssystem, das ein einziges Modell für die Deklaration aller Anwendungslieferungsanforderungen implementiert und alle kontinuierlichen Lieferungsschritte in einer Linie anordnet und ausführt.

![Zooms kontinuierliche Lieferpipeline](https://static.api7.ai/2022/10/27/635a56149b270.jpg)

Es gibt sechs Teile in der kontinuierlichen Lieferpipeline:

1. **Vorbereiten**: Vorbereiten von vordefinierten Ressourcen, einschließlich Infrastruktur, Middleware, Cloud-Service-Ressourcen usw.;

2. **Konfigurieren**: Vorbereiten der Konfigurationsdateien und Schlüssel, die von der Anwendung benötigt werden;

3. **Bereitstellen**: Verwenden von K8s für die Bereitstellung in Cloud-nativen Szenarien (einschließlich Informationen über Container, Container-Images, Parameter, Versionen und Instanzen);

4. **Zugriff**: Erstellen eines Kubernetes-Service und automatisches Konfigurieren der Routing-Regeln des Apache APISIX Ingress, wenn die Bereitstellung externen Zugriff erfordert;

5. **Beobachten**: Durchführen von Beobachtbarkeitsbezogenen Konfigurationen, wie Überwachung, Alarmierung, Protokollierung und Tracing-Analyse;

6. **Skalieren**: Deklarieren der dynamischen Skalierungsregeln von KEDA (Kubernetes Event-driven Autoscaling) durch Überwachungsmetriken.

### Wie APISIX Ingress in der Pipeline verwendet wird

![Übersicht über Zooms Pipeline-Architektur](https://static.api7.ai/2022/10/27/635a5616254ed.jpg)

**Projektmanagement**

Projektmanager legen mehr Wert auf R&D-Iterationen und darauf, wie sie den iterativen Veröffentlichungsfortschritt und die Personaleffizienz auf der Zeitleiste, die den Iterationen entspricht, besser verwalten können. Zoom verwendet intern einen GitOps-Workflow, um die API-Gateway-Konfiguration in das Anwendungslieferungsmodell zu integrieren. Unter diesem Modell ist die Definition von APISIX-Routing-Regeln mit „Bereitstellen“ und anderen Links integriert, wodurch die Änderungskontrolle an GitHub übergeben wird. Mit der Erstellung und dem Zusammenführen von GitHub-Zweigen realisiert die Pipeline konsistente Zeitleisten zwischen der Anwendungs- und Gateway-Konfigurationsfreigabe und -Rücknahme.

```yaml
# Code-Snippet von Zooms CD-Pipeline im Git-Repository
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*
```

Auf diese Weise wird das Release-Management in das Workflow-Management innerhalb von GitHub vereinfacht und das Problem der zeitlichen Verzögerung zwischen Upstream- und Downstream-Systemen gelöst, die Änderungen abgleichen, wenn mehrere Iterationen gleichzeitig verarbeitet werden.

**Anwendungsentwicklung**

Entwickler konzentrieren sich hauptsächlich auf die Routing- und Authentifizierungsfähigkeiten von APIs, die stark mit Geschäftsdiensten verbunden sind und von Entwicklern ausgefüllt werden sollten, um den automatischen Effekt zu erzielen. Darüber hinaus legen sie Wert auf die Entwicklung und Implementierung von Geschäftsfunktionen und der oberen Geschäftsebene und hoffen, eine sofort einsatzbereite Infrastruktur aufzubauen.

Aus den oben genannten Codes können wir sehen, dass Entwickler nur `Authentication` und `Match` in dieser kontinuierlichen Lieferpipeline definieren müssen. Sie müssen die zugrunde liegende Logik nicht kennen:

- Zuerst wird es in Kubernetes Deployment und Service übersetzt.
- Dann wird die Plattform-API aufgerufen, um die Korrektheit des Pfads zu überprüfen.
- Schließlich wird es in ApisixRoute-Objekte übersetzt.

Die Integration der APISIX-Konfiguration und des kontinuierlichen Lieferpipeline-Workflows bietet Entwicklern eine arbeitserleichternde Möglichkeit.

**Umgebungsmanagement**

Komplexe Anforderungen an das Umweltmanagement und die Kontrolle treten oft in toB-Szenarien auf, und Lieferprobleme in einigen privaten Cloud-, dedizierten Cloud- und Hybrid-Cloud-Szenarien müssen berücksichtigt werden.

Einige Konfigurationen von APISIX Ingress wurden implementiert, um die Anforderung der Abschirmung von Umweltunterschieden zu erfüllen. Auf diese Weise können Systemmanager die Unterschiede in einigen heterogenen Umgebungen umfassend kontrollieren. Alle Dienste, die in der Umgebung bereitgestellt werden, sind effektiv, wodurch die kognitive Belastung und spezielle Bereitstellungsoperationen, die durch Umweltunterschiede für Anwendungs- und Betriebsentwickler verursacht werden, vermieden werden. Zum Beispiel kann Zoom benutzerdefinierte Konfigurationen verwenden, um Tracing für einige Umgebungen zu deaktivieren, ApisixRoute-Objekte in native Ingress-Objekte und NGINX Ingress-Annotationen umzuwandeln und verschiedene Images zum Abrufen von Geheimnissen zu verwenden.

Darüber hinaus ist eine Multi-Tenant-Isolierung erforderlich, wenn mehrere Geschäftsbereiche die APISIX-Umgebung nutzen. **APISIX Ingress bietet einen Annotation-Selektor**, der es ermöglicht, dass verschiedene ApisixRoute-Objekte von verschiedenen Instanzen des APISIX Ingress Controllers aufgenommen werden.

**Infrastrukturmanagement**

Das API-Gateway-Team muss alle APISIX-Instanzen kontrollieren, Sicherheitsrichtlinien umfassend konfigurieren, Multi-Availability-Zones implementieren und so weiter.

Jedes Plugin der Pipeline bietet Konfigurationsoptionen für Infrastrukturingenieure. Im Plugin `ingress-apisix` gibt es eine `defaultPlugins`-Eigenschaft.

Nachdem das API-Gateway-Team die Eigenschaft konfiguriert hat, wird die Einstellung für alle Dienste wirksam, was für eine einheitliche Sicherheits- und Risikokontrollstrategie geeignet ist.

## Fazit

Der APISIX Ingress Controller spielt eine wichtige Rolle in Zooms kontinuierlicher Lieferpipeline, indem er den Druck auf Projektmanagement, Anwendungsentwicklung, Umweltmanagement sowie Middleware- und Infrastrukturmanagement verringert. Der Fall von Zoom ist es wert, von anderen Unternehmen gelernt zu werden, und wir freuen uns darauf, dass der APISIX Ingress Controller zur Innovation weiterer Unternehmen beiträgt.

Darüber hinaus hat Apache APISIX Ingress im August 2022 offiziell V1.5 veröffentlicht, das den Vorschlag aller Ressourcen-API-Versionen vereinheitlicht und alle CRD-API-Versionen auf V2 aktualisiert. Gleichzeitig unterstützt es die meisten Gateway-API-Ressourcen. Apache APISIX Ingress hat Ingress-Ressourcen ermöglicht, beliebige APISIX-Plugins zu verwenden, indem eine neue Annotation „k8s.apisix.apache.org/plugin-config-name“ zu Ingress-Ressourcen hinzugefügt wurde. Auf diese Weise wird die Benutzerfreundlichkeit des APISIX Ingress Controllers erheblich erhöht und die Kosten für Benutzer, die von anderen Ingress Controllern zu APISIX Ingress Controller migrieren, reduziert.

Weitere Informationen finden Sie unter [Apache APISIX Ingress V1.5](https://apisix.apache.org/blog/2022/08/05/apisix-ingress-1.5rc1-release/).


Zoom integriert den APISIX Ingress Controller in seine kontinuierliche Bereitstellungspipeline, um das gesamte Management von Projekten, Anwendungen, Umgebungen und Infrastruktur zu realisieren.

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway für Web3: Wie APISIX Hyperchain stärkt

Wie integriert sich vivo mit APISIX?

Wie nutzt Zoom APISIX Ingress in seiner Continuous-Delivery-Pipeline?

Bereit, Ihre APIs zu verwalten?

Apache APISIX vs NGINX:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}Dynamic Configuration,Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway für Web3: Wie APISIX Hyperchain stärkt

Wie integriert sich vivo mit APISIX?

Wie nutzt Zoom APISIX Ingress in seiner Continuous-Delivery-Pipeline?

Bereit, Ihre APIs zu verwalten?

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management