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

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?

## Überblick

### Herausforderungen

- Eine bedeutende Herausforderung in der Datenverwaltung, da sich das Geschäft von Airwallex weltweit ausdehnt
- Komplizierte Verwaltung verschiedener Systeme und deren Vernetzung verursachen Probleme in anderen Systemen, wenn ein Problem auftritt

### Ergebnisse

- Stabile Leistung für eine **15-monatige** Produktionsumgebung
- **99 %** der Antwortverzögerungen liegen innerhalb von **23 ms**, wenn dynamisches Routing, Multi-Tenant-Rate-Limiting, Multi-Tenant-IP-Whitelist, Authentifizierung und Autorisierung aktiviert sind
- Sichere und effiziente Unterstützung der Datenhoheit, die mehr als **50 Währungen** in über **130 Ländern und Regionen** abdeckt

## Über Airwallex

Als globales Fintech-Unternehmen hat [Airwallex](https://www.airwallex.com/us) eine globale Finanzplattform aufgebaut, deren Zahlungsnetzwerk mehr als 50 Währungen in über 130 Ländern und Regionen weltweit abdeckt und digitale Fintech-Produkte für Unternehmen bereitstellt.

![Airwallex Business](https://static.api7.ai/apisix-webp/202108/1646626634389-7d9a0a82-a76c-4645-93b6-8a431bb1f9a1.webp)

> Dieser Artikel basiert auf einem Interview mit Yang Li, Ph.D., Committer von Apache APISIX und Technical Platform Lead bei Airwallex, der für die Weiterentwicklung der Technologieplattform von Airwallex verantwortlich ist.

## Datenhoheit stellt Airwallex vor Herausforderungen

[Data sovereignty](https://api7.ai/blog/leveraging-api-gateway-for-data-sovereignty-and-data-compliance) wird in der Datenverwaltung im Cyberspace immer wichtiger. Airwallex bedient Nutzer in verschiedenen Regionen, was zwangsläufig das Problem der Datenhoheit mit sich bringt.

Früher, ohne die Anforderung der Datenhoheit, konnten Daten in Europa gespeichert und nach Asien oder in jedes Rechenzentrum der Welt synchronisiert werden. Das Dateninteraktionsdiagramm sah so aus:

![Multi-Cluster-Interaktion](https://static.api7.ai/202108/1635907812257-962b1247-f5ca-448f-904d-f5d47c3ea4586.png)

In einem Zeitalter, in dem die Datenhoheit geschätzt wird, sind Daten jedoch kontrolliert, und die vorherige Architektur kann nicht mehr verwendet werden. In Europa können nur europäische Daten verarbeitet werden, und in Asien können nur asiatische Daten verarbeitet werden. Die Dateninteraktion ändert sich wie folgt.

![Interaktion in einer Umgebung mit Datenhoheit](https://static.api7.ai/uploads/2023/02/01/63Z7AhJx_2.webp)

Infolgedessen stellt die Datenhoheit eine erhebliche Herausforderung für das globale Geschäft von Airwallex dar. Airwallex beabsichtigt, Daten aus Europa in andere Regionen zu migrieren, und muss sicherstellen, dass die Anforderungen von Drittländern an die Datenhoheit mit denen der EU übereinstimmen.

## Warum wählt Airwallex APISIX?

Bei der Auswahl des API-Gateways verglich Airwallex hauptsächlich die wichtigsten Gateway-Produkte aus sechs Dimensionen:

- **Stabilität**: Airwallex legt großen Wert auf die Sicherstellung der Stabilität des API-Gateways. Unter den Top 1000 Websites der Welt basieren **62,1 % auf NGINX**, was zeigt, dass die auf NGINX basierenden Webserver den Test komplexer und vielfältiger Szenarien in der Produktionsumgebung bestanden haben. Apache APISIX basiert auf NGINX. Darüber hinaus ermöglicht das Design von **Apache APISIX’s [vollständig dynamischer](https://api7.ai/blog/how-nginx-reload-work)** Funktion, die Route ohne Neuladen zu ändern und die langfristige Verbindung des Clients aufrechtzuerhalten. Außerdem führte **Airwallex auch Belastungstests für Apache APISIX durch, die auch dann stabil laufen, wenn die CPU-Auslastung mehr als 70 % beträgt.**

- **Leistung**: Jede API-Anfrage wird durch das API-Gateway geleitet. Die Reduzierung des [Leistungsverlusts](https://api7.ai/blog/apisix-kong-3-0-performance-comparison) des Gateways kann die Gesamtantwortzeit der APIs von Airwallex erheblich verkürzen.
  
    > "Im PoC verglichen wir die wichtigsten Gateway-Produkte: **Die Antwortverzögerung von Apache APISIX ist mehr als 50 % niedriger als bei anderen Gateways**. Darüber hinaus ermöglicht die unabhängige Datenebene von Apache APISIX unabhängige Instanzen in den Clustern, was eine horizontale Skalierung von Natur aus unterstützt." sagte Li.

- **Skalierbarkeit**: Airwallex benötigt APISIX als API-Gateway, das komplexe **[Authentifizierung](https://api7.ai/blog/api-gateway-authentication), Berechtigungskontrolle, [Service Discovery](https://api7.ai/blog/what-is-service-discovery-in-microservices), [Rate-Limiting](https://api7.ai/blog/rate-limiting-in-api-management), Downgrade, Lastenausgleich, Whitelist und dynamisches Routing** unterstützt.

- **Aktive Community**: Eine aktive Community ist der Schlüssel, damit das API-Gateway mit dem Tempo der technologischen Entwicklung Schritt halten kann.

    > **Die [Community](https://api7.ai/category/community) von Apache APISIX war bereits aktiv, als es noch ein Apache-Inkubationsprojekt war, gemessen an der Anzahl der Mitwirkenden, der Reaktionszeit auf Issues und der Anzahl der Pull Requests.** teilte Li mit.

- **Private Bereitstellung**: Das API-Gateway ist die Kernkomponente der technischen Architektur von Airwallex, und das Unternehmen stellt das API-Gateway am Rand seines eigenen privaten Netzwerks bereit. **Apache APISIX hat eine gute Umweltanpassungsfähigkeit und kann problemlos in verschiedenen Umgebungen, einschließlich Cloud-Computing-Plattformen, bereitgestellt werden.**

- **Geschäftsfreundliche Open-Source-Lizenz**: Die Apache 2.0-Lizenz ermöglicht es Airwallex, den Code von APISIX zu ändern und darauf zu kommerzialisieren, ohne sich um Vendor Lock-in sorgen zu müssen.

## Intelligente Routing-Lösung von Apache APISIX

**Airwallex wählt Apache APISIX für eine intelligente Routing-Lösung**, und es ist das Apache APISIX-Gateway, das entscheidet, wo die Daten verarbeitet werden sollen.

![Zweischichtiges Gateway von Airwallex](https://static.api7.ai/uploads/2023/02/01/cGg9YfNp_3.webp)

Das Gateway besteht aus zwei Schichten. Die erste Schicht ist für das Routing von Anfragen verantwortlich und bestimmt, welches Rechenzentrum die Anfrage erreichen soll. Die zweite Schicht übernimmt die Weiterleitung des Datenverkehrs.

Darüber hinaus implementierte **Airwallex die Hauptfunktionen als benutzerdefinierte [Plugins](https://api7.ai/blog/how-to-implement-plugin-orchestration-in-api-gateway)**, um jederzeit auf eine neue Version von Apache APISIX zu aktualisieren. Auf diese Weise gibt es keinen Wettlauf zwischen der Code-Bibliothek von Airwallex und dem Kerncode des Haupt-Repositorys von Apache APISIX. Manchmal ist es jedoch notwendig, den Kerncode zu ändern. In diesem Fall versucht Li, diese Funktionen in der Open-Source-Community zu implementieren. **Die Mitwirkenden in der Community sind sehr enthusiastisch, wenn es um die Diskussion der Funktionsimplementierung geht, und in den meisten Fällen können sie schnell verfügbare Lösungen bereitstellen.**

## Wie profitiert Airwallex von der Nutzung von APISIX?

Unten ist ein Diagramm, das die Integration von Airwallex mit APISIX zeigt.

![Integrationsdiagramm von Airwallex und APISIX](https://static.api7.ai/uploads/2023/01/31/Q0LbIb0E_88.webp)

Airwallex verwendet Apache APISIX als Kernkomponente des Microservice-Gateway-Modells. Es wird am Rand des Netzwerks bereitgestellt und bietet eine allgemeine Gateway-Funktion für den gesamten Datenverkehr, der in Airwallex eingeht. Die Probleme, die es löst, sind:

- **Datenhoheit**: Für Finanzinfrastrukturen, die grenzüberschreitend operieren, ist die Datenhoheit eine kritische regulatorische Anforderung. Zu diesem Zweck entwickelte **Airwallex ein dynamisches, regelkonformes Routing-Plugin, das die Fähigkeiten der dynamischen Upstream-Auswahl von Apache APISIX nutzt**. Dynamisches Routing kann intelligente Upstreams für die Anfrageverteilung basierend auf den Merkmalen der Benutzeranfragen auswählen, wodurch komplexe Multi-Rechenzentrums-Kollaborationsprobleme von der Service-Ebene auf die Gateway-Ebene abstrahiert werden. Das Wesen des dynamischen Routings besteht darin, zwei Fragen zu beantworten: Wie werden Upstreams gruppiert und wie werden Anfragen und Gruppen abgeglichen.

- **Isolation in Microservices**: Airwallex hofft, dass die Engineering-Teams jedes Microservices ihre eigenen Dienste unabhängig kontrollieren können, um die Kosten für Kommunikation und Koordination effektiv zu reduzieren und die Engineering-Effizienz zu verbessern. Dieses Architekturkonzept erfordert, dass Infrastrukturkomponenten, die von verschiedenen Teams gemeinsam genutzt werden, wie z. B. das API-Gateway, die Mandantenisolation unterstützen können. **APISIX eignet sich perfekt, um die Mandantenisolation zu erfüllen.** Während die Robustheit und Kostenkontrolle des gesamten Systems sichergestellt wird, ermöglicht APISIX den Geschäftsteams, Gateway-Funktionen gemäß ihren eigenen Anforderungen zu konfigurieren und zu erweitern, wodurch die Unabhängigkeit der Microservice-Teams und Dienste gewahrt bleibt.

- **Multi-Tenant-Rate-Limiting**: In einer Multi-Tenant-Umgebung sind die Verkehrsmerkmale jedes Mandanten unterschiedlich. Die Anwendung desselben Rate-Limiting auf verschiedene Mandanten kann die kommerziellen Anforderungen nicht erfüllen. **Multi-Tenant-[Rate-Limiting](https://api7.ai/blog/rate-limiting-in-api-management) kann basierend auf Benutzermerkmalen angemessener sein.**

- **Multi-Tenant-IP-Whitelist**: Die Zugriffs-IP jedes Mandanten variiert in einer Multi-Tenant-Umgebung. **Multi-Tenant-IP-Whitelist ermöglicht es jedem Mandanten, seine eigene Whitelist zu kontrollieren, ohne sich Sorgen über die Invasion anderer Benutzer in seine eigenen Ressourcen machen zu müssen.**

- **Authentifizierung**: Häufige Schlüsselaktualisierungen sind ein kritischer Schritt, um die Sicherheit der Benutzerressourcen zu gewährleisten. **APISIX unterstützt nicht nur die [Authentifizierung](https://api7.ai/blog/understanding-microservices-authentication-services) von Anfragen, sondern auch die dynamische Aktualisierung von Schlüsseln.**

- **Autorisierung**: Die Berechtigungsverwaltung von Unternehmensanwendungen ist sehr komplex, und verschiedene Anwendungsszenarien haben völlig unterschiedliche Berechtigungsverwaltungsmodelle. **APISIX kann überprüfen, ob der anfragende Benutzer über ausreichende Berechtigungen verfügt, um auf die Schnittstelle zuzugreifen, und illegalen Datenverkehr beim ersten Mal abfangen.**

Die Produktionsumgebung von Airwallex läuft seit **15 Monaten**, und die Gesamtleistung ist äußerst stabil. Etwa **99 % der Antwortverzögerungen liegen innerhalb von 23 ms**, wenn dynamisches Routing, Multi-Tenant-Rate-Limiting, Multi-Tenant-IP-Whitelist, Authentifizierung, Autorisierung und andere Funktionen aktiviert sind.

**Dank des hervorragenden Plugin-Mechanismus von Apache APISIX kann Airwallex private Plugins hinzufügen, die den Geschäftsanforderungen entsprechen, ohne den Kerncode zu ändern.** Das vollständige Testsystem gewährleistet weiterhin die Softwarequalität, und Sie können sicher die personalisierten Anforderungen des Plugins erhöhen, während sichergestellt wird, dass die ursprüngliche Kernlogik nicht beschädigt wird.

## Zukünftige Pläne

Die weiteren Pläne von Airwallex umfassen hauptsächlich drei Aspekte:

1. Verwenden eines mehrschichtigen Netzwerks, um die Gateway-Logik in verschiedene Schichten aufzuteilen, z. B. die Verteilung des Datenverkehrs nach Datenhoheit oder anderen Gateway-Logiken.

2. Einfach zu lesendes und einfach zu verwendendes Routing-Management ist entscheidend für den Erfolg des API-Gateways. Das Routing-Management muss für die Entwickler freundlich sein, damit sie leicht verstehen können, was das Gateway für sie tun kann und wie sie es konfigurieren und veröffentlichen können.

3. Verwenden von farbcodierten Anfragen, um die Produktionsumgebungstests zu implementieren. Die Verwendung von farbcodierten Anfragen des API-Gateways zur Implementierung von Produktionsumgebungstests kann mehr Flexibilität und Benutzerfreundlichkeit bieten.

## Benötigen Sie Unterstützung für APISIX?

[Apache APISIX](https://api7.ai/apisix) ist ein Open-Source-, dynamisches, skalierbares und leistungsstarkes Cloud-natives API-Gateway für alle Ihre APIs und Microservices. Als Spende an die Apache Software Foundation von API7.ai ist APISIX zu einem Top-Level-Open-Source-Apache-Projekt herangewachsen.

Möchten Sie Ihre Entwicklung wie Airwallex mit Zuversicht beschleunigen? Um die APISIX-Unterstützung zu maximieren, benötigen Sie [API7](https://api7.ai/). Wir bieten umfassende Unterstützung für APISIX und API-Management-Lösungen basierend auf Ihren Anforderungen!

Kontaktieren Sie uns jetzt: [https://api7.ai/contact](https://api7.ai/contact).

Mehr über den Interviewpartner:

![Yang Li, Airwallex](https://static.api7.ai/uploads/2023/01/31/uGbiZnt5_Airwallex2.webp)


Airwallex löst technische Herausforderungen, die die Datenhoheit mit sich bringt, und entwickelt intelligente Routing-Lösungen mithilfe von Apache APISIX.

What is Apache APISIX?

Why Apache APISIX?

APISIX vs alternatives

To Maximize APISIX, You Need API7

Case Studies

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

Wie integriert sich vivo mit APISIX?

Wie Airwallex globale Zahlungen mit Apache APISIX ermöglicht?

Looking for Apache APISIX Support?