Open-Source Project

Community-Driven

High Availability, Stability

Ultimate Performance,

Developer Friendly

Go for Apache APISIX

Looking for the best API Gateway?

Companies choose Apache APISIX as their API gateway after comparing it with Kong. Not only is Apache APISIX is faster, but the experience is also excellent.

Apache APISIX vs Kong:

## 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.

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

## Ü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](https://en.wikipedia.org/wiki/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**](https://www.iq.com/?lang=en_us) 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.

![iQIYI's API Gateway Architecture Diagram](https://static.api7.ai/2022/12/02/6389647220deb.jpeg)

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**.

![microservice-gateway.webp](https://static.api7.ai/2022/11/21/637b4c61c02c0.webp)

### 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](https://github.com/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](https://apisix.apache.org/docs/apisix/plugins/limit-count/) 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](https://apisix.apache.org/docs/apisix/next/plugins/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.

![iQIYI's dynamic service discovery updating process](https://static.api7.ai/2022/12/02/63897fa31ff83.jpeg)

### 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**.

![iQIYI's directional routes diagram](https://static.api7.ai/2022/12/02/63898546bd508.jpeg)

### 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](https://api7.ai/contact).


iQIYIs technisches Team vergleicht APISIX mit Kong und aktualisiert sowie integriert die Infrastruktur von iQIYI, um erfolgreich ein brandneues API-Gateway zu entwickeln.

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

## Ü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.

Apache APISIX vs Kong:
93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

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

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

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

Bereit, Ihre APIs zu verwalten?

Apache APISIX vs Kong:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

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

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

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

Bereit, Ihre APIs zu verwalten?

Apache APISIX vs Kong:
93x Faster & 200% QPS