NGINX zu APISIX – Neudefinition der Dynamik von Airline-Gateways

Überblick

Über

Als weltweit fünffach ausgezeichnete Airline von Skytrax hat diese führende Fluggesellschaft seit 30 Jahren sicher operiert und deckt insgesamt fast 1.900 internationale Routen ab, einschließlich planmäßigem Passagiertransport, Charterflügen für die Wiederaufnahme von Arbeit und Schule sowie Passagierflügen in Asien, Europa, Afrika, Nordamerika und Ozeanien.

Als schnell wachsende Fluggesellschaft benötigte diese führende Airline ein API-Gateway, um effiziente Flugbuchungsprozesse zu ermöglichen, verschiedene Systeme und Dienste zu integrieren und zu verbinden sowie Hochlastszenarien und Finanz- und Risikodaten zu bewältigen.

Herausforderungen

Der Aufstieg von Microservices und containerisierten Bereitstellungen erschwert die Verwaltung der zunehmenden NGINX-Instanzen und diversen Domain-Konfigurationen.
Das gleichzeitige Vorhandensein zu vieler NGINX-Versionen erhöht die Komplexität bei der Aktualisierung, Kompilierung und Anpassung der Plugins.
Das bisherige API-Gateway konnte nur die grundlegenden Anforderungen dieser führenden Fluggesellschaft erfüllen, bot jedoch keine erweiterten Funktionen wie Circuit Breaker, Canary Release usw.

Ergebnisse

Die Multi-Node-Konfiguration wurde vereinfacht, was die Entwicklungseffizienz erheblich verbessert und Verwaltungskosten spart, dank der Hot-Reloading-Funktion von APISIX.
Die führende Fluggesellschaft nutzt das inklusive Plugin-Ökosystem von APISIX, um erweiterte Funktionen auszuführen, was die Aktualisierung von Plugins und Systemen vereinfacht.
Das Upgrade verbessert die Effizienz und Wartbarkeit des Gateways – ein entscheidender Schritt hin zu einer organisierten, modularen und wiederverwendbaren Konfigurationsverwaltung.

Hintergrund

Diese führende Fluggesellschaft hat NGINX über einen beträchtlichen Zeitraum als Nord-Süd-Gateway verwendet. Trotz der effektiven Bewältigung ihrer Verkehrsanforderungen, stieß das Unternehmen mit der Expansion des Geschäfts und des Produktportfolios auf zunehmende Herausforderungen in verschiedenen Bereichen.

1. Mehrere NGINX-Instanzen und Domains

Innerhalb des Unternehmens gab es mehrere NGINX-Instanzen und verschiedene Domains, deren Komplexität die Verwaltung erschwerte. Der Kern von NGINX liegt in seinen Konfigurationsdateien. Mit der Zunahme der NGINX-Instanzen wurde die Konfigurationsverwaltung durch einfaches Kopieren von Dateien per SCP immer schwieriger. Besonders mit der weit verbreiteten Nutzung von Microservices und containerisierten Bereitstellungen im Backend stieg der Bedarf an Flexibilität in der Reverse-Proxy-Konfiguration, was zu einem erheblichen Anstieg der Arbeitslast für die Konfigurationskonsistenz führte.

2. Verschiedene NGINX-Versionen und problematische Plugin-Upgrades

Aus historischen Gründen verwendete das Team mehrere NGINX-Versionen gleichzeitig sowie zahlreiche NGINX-Plugins. Während die Aktualisierung von NGINX selbst keine großen Herausforderungen darstellte, ergaben sich Schwierigkeiten bei der Aktualisierung, Kompilierung und Anpassung verschiedener Plugins. Viele davon waren inoffiziell, was die Fehlerbehebung während der Kompilierung erschwerte. Darüber hinaus war die Kompatibilität mit NGINX-Versionen nicht garantiert.

3. Fehlende Standards für NGINX-Konfigurationen

Die Übernahme von Systemen verschiedener Teams führte zu einer Vielzahl von NGINX-Konfigurationspraktiken, die zahlreiche Ansätze ohne standardisierte Konfiguration zeigten. Das Fehlen eines einheitlichen Konfigurationsstandards unterstrich die Vielfalt der Implementierungsmethoden über die Teams hinweg und verdeutlichte die Notwendigkeit eines kohärenten und standardisierten Ansatzes für NGINX-Konfigurationen.

4. Unzureichende moderne Gateway-Funktionen

Während NGINX grundlegende Nord-Süd-Gateway-Anforderungen wie Reverse-Proxy und Lastenausgleich effizient erfüllte, erforderten die dynamischen Geschäftsanforderungen des Unternehmens erweiterte Funktionen. Die Implementierung von Diensten wie Circuit Breaking, Sicherheitskontrollen und Canary Release wurde mit NGINX allein schwierig, was die Suche nach robusten Lösungen erforderlich machte.

Gateway-Auswahl für präzise Geschäftsanforderungen

Um die Herausforderungen mit NGINX zu bewältigen, hat diese führende Fluggesellschaft drei grundlegende Anforderungen für eine neue Gateway-Lösung festgelegt:

Einfache Verwaltung und Konfiguration: Sie benötigen eine Lösung, die die einfache und einheitliche Verwaltung und Bereitstellung von Konfigurationen wie Routen und Upstream-Diensten über mehrere Gateway-Knoten hinweg ermöglicht.
Erweiterte API-Gateway-Funktionen: Das neue Gateway muss moderne API-Gateway-Anforderungen erfüllen, einschließlich Circuit Breaking, Sicherheitskontrollen und Canary Release.
Benutzerfreundlichkeit und geringe Lernkurve: Um die Verwaltungskosten zu senken, erwartet das Team, dass die neue Gateway-Lösung die meisten grundlegenden Anforderungen durch Konfiguration und Low-Code-Methoden problemlos erfüllt.

Nach der Klärung der iterativen Upgrades und grundlegenden Anforderungen für das bestehende Nord-Süd-Gateway recherchierte das Unternehmen verschiedene beliebte Produkte auf dem Markt und entschied sich schließlich für APISIX als neues Gateway.

Warum nicht OpenResty

Während der Recherche wurde zunächst OpenResty in Betracht gezogen, eine weit verbreitete Lösung, die von einigen Unternehmen genutzt wird. Der Hauptvorteil war die vollständige Kompatibilität der Konfigurationsdateien mit NGINX. Die Migration von NGINX zu OpenResty war für das Unternehmen nicht so schwierig, obwohl es komplexe Domain-Setups gab.

Im Vergleich zu Kong und APISIX fehlten der Open-Source-Version von OpenResty jedoch umfassende Plugins und ein Dashboard für die visuelle Konfiguration. Benutzer mussten codieren, um einige grundlegende Funktionen zu erfüllen.

Warum nicht Kong

Die Fluggesellschaft zog Kong als Alternative in Betracht. Obwohl die Standard-Plugins die meisten Anforderungen erfüllten, blieb die visuelle Oberfläche (Dashboard) der Open-Source-Version über mehrere Jahre unverändert, was die Präferenz für Lösungen mit aktualisierten und benutzerfreundlicheren Schnittstellen verstärkte.

In Stresstests übertraf APISIX Kong und zeigte beeindruckende Leistung – doppelt so gut wie Kong ohne Plugins und bis zu zehnmal besser mit aktivierten Rate-Limiting- und Prometheus-Plugins. Darüber hinaus zeigte APISIX, basierend auf OpenResty, hervorragende Routing-Fähigkeiten, was das Vertrauen des Teams stärkte.

Warum nicht Envoy

Trotz der beeindruckenden Funktionen von Envoy führten die Programmiersprache C++ und die steilere Lernkurve, insbesondere aufgrund der technischen Einschränkungen des Teams, dazu, dass Envoy nicht als bevorzugte Gateway-Lösung gewählt wurde.

Schließlich entschied sich das technische Team für APISIX als neues Gateway aufgrund seiner anerkannten Funktionalität und Leistung.

Warum sticht APISIX hervor?

APISIX stach im Vergleich zu Kong aus zwei Hauptgründen hervor.

APISIX Dashboard

Mit dem Dashboard kann das technische Team bequem verschiedene Routen und Plugin-Konfigurationen verwalten. Bemerkenswert ist, dass das APISIX Dashboard ein Open-Source-Teil des Projekts ist, was kontinuierliche Updates im Einklang mit der Entwicklung von APISIX gewährleistet und eine verbesserte Verwaltungserfahrung bietet.
Apache Open-Source-Projekt

Als Top-Level-Projekt der Apache Software Foundation war es für Benutzer einfacher, relevante technische Dokumentationen im Vergleich zu Kong zu finden. Die Unterstützung durch die Apache-Community bietet zuverlässige technische Hilfe bei Herausforderungen, was APISIX zu einer geeigneteren Wahl für die Fluggesellschaft macht.

Darüber hinaus behebt APISIX effektiv die zuvor erwähnten Probleme mit NGINX.

APISIX speichert Konfigurationen in etcd, was Entwicklern ermöglicht, mehrere APISIX-Knoten für verschiedene Domains einfach zu verwalten, indem ein einzelner etcd-Cluster bereitgestellt wird.
APISIX bietet gängige Plugins, einschließlich Gesundheitschecks und anderer Überwachungs-Plugins, was Bedenken hinsichtlich Kompatibilität und Upgrades, wie sie bei NGINX auftraten, beseitigt.
APISIX enthält verschiedene Sicherheits- und Verkehrskontroll-Plugins, die Funktionen wie Circuit Breaking, Sicherheitskontrollen, Canary Releases und mehr problemlos ermöglichen.

Insgesamt sticht APISIX als das am besten geeignete Produkt für das technische Team hervor.

Migration von NGINX zu APISIX: Erforschung erweiterter, aber einfacherer Lösungen

In NGINX werden Domain-Verwaltung und Funktionsimplementierung hauptsächlich durch NGINX-Konfigurationsdateien erreicht. Obwohl APISIX immer noch auf NGINX und OpenResty basiert, verfolgt es einen völlig anderen Ansatz und verwendet keine NGINX-Konfigurationsdateien mehr, um Domains zu verwalten und Funktionen zu implementieren.

Stattdessen konfiguriert APISIX Routen und Upstreams basierend auf Domain-Namen und implementiert verschiedene zusätzliche Funktionen auf diesen Routen durch Plugins. Das integrierte CORS-Plugin von APISIX kann verwendet werden, um regionsübergreifende Konfigurationen zu erreichen, was die Notwendigkeit einer zeilenweisen Konvertierung erspart.

Nachfolgend ein Code-Vergleich zwischen der Konfiguration in NGINX und APISIX.

#   NGINX  conf
    add_header 'Access-Control-Allow-Origin' $corsHost;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver';
    if ($request_method = 'OPTIONS') {
            return 204;
     }

#  APISIX  plugins config
    "cors": {
      "allow_credential": true,
      "allow_headers": "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver",
      "allow_methods": "GET,POST,PUT,OPTIONS",
      "allow_origins": "https://wap.test.com,http://wap.test.com,",
    },
    "response-rewrite": {
      "status_code": 204,
      "vars": [
        [
          "request_method",
          "==",
          "OPTIONS"
        ]
      ]
    }

Durch den Vergleich von NGINX und APISIX lässt sich leicht feststellen, dass die NGINX-Konfiguration möglicherweise prägnanter erscheint, aber für Personen, die mit NGINX und CORS nicht vertraut sind, ist das Verständnis der zugrunde liegenden Bedeutung möglicherweise nicht so einfach. Im Gegensatz dazu kapselt APISIX verschiedene Funktionen in Plugins, was die Konfiguration modularer macht. Daher wird es offensichtlicher, Funktionen zu finden und die Funktionalitäten zu verstehen. Ähnliche Beispiele für die Migration von Konfigurationen von NGINX zu APISIX existieren für verschiedene Szenarien, wie z.B. die Konfiguration von WebSocket in NGINX.

Erfolge

Vereinfachte Multi-Node-Konfigurationsverwaltung

APISIX verbessert die Konfigurationsspeicherung mit etcd, was die Verwaltung verschiedener APISIX-Knoten über mehrere Domains hinweg erleichtert. Dies vereinfacht Aufgaben durch die Verwendung eines einzelnen etcd-Clusters und gewährleistet eine effektive Kontrolle über verschiedene APISIX-Instanzen mit spezifischen Domain-Setups. Darüber hinaus reduziert die zentralisierte Methode die Komplexität, fördert eine reibungslose Verwaltung und verbessert die Skalierbarkeit und Effizienz von APISIX in verschiedenen Domain-Szenarien. Folglich reicht in der Fluggesellschaft die Bereitstellung eines einzelnen etcd-Clusters aus, um verschiedene APISIX-Instanzen, die mit unterschiedlichen Domain-Setups verbunden sind, zu überwachen.

Vereinfachte Operationen mit APISIX-Plugins

APISIX bietet integrierte Plugins wie gängige Gesundheitschecks, ähnlich den häufig verwendeten Plugins in NGINX. Diese Funktion beseitigt die Notwendigkeit für die Fluggesellschaft, sich um Probleme im Zusammenhang mit Upgrades und Kompatibilität zu kümmern. Die Einbindung dieser Plugins in APISIX gewährleistet eine nahtlose Funktionalität und beseitigt Bedenken hinsichtlich Upgrades und Kompatibilität, was der Fluggesellschaft ein sorgenfreies Erlebnis bietet.

Darüber hinaus können in APISIX Funktionen wie Cross-Origin Resource Sharing (CORS) und WebSocket-Unterstützung nahtlos mit Plugins implementiert werden. Dieser Ansatz vereinfacht nicht nur den Entwicklungsprozess, sondern trägt auch zu einer anspruchsvolleren und effizienteren Lösung der Herausforderungen der Fluggesellschaft bei.

Etablierung eines umfassenden API-Gateways

APISIX ist mit verschiedenen Sicherheits- und Verkehrskontroll-Plugins ausgestattet, die die einfache Implementierung von Dienst-Drosselung, Sicherheitsmaßnahmen und schrittweisen Releases ermöglichen. Dies befähigt die Fluggesellschaft, ein breiteres Spektrum an grundlegenden und erweiterten Funktionen zu nutzen. Die Einführung von APISIX stellt einen bedeutenden Erfolg für die Fluggesellschaft dar, der eine verbesserte Dienstzuverlässigkeit, robuste Sicherheitskontrollen und effiziente Bereitstellungsstrategien wie schrittweise Releases ermöglicht, was letztendlich zu einer gesteigerten Betriebskapazität und Leistung beiträgt.

Überarbeitung veralteter Konfigurationen in wiederverwendbare Module

Während des gesamten Upgrade-Prozesses entdeckte das technische Team zahlreiche veraltete Konfigurationen im bestehenden NGINX-Setup, von denen viele sinnloses Kopieren und Einfügen beinhalteten. Dieses Upgrade diente als umfassende Überholung des gesamten Nord-Süd-Gateways, wobei insbesondere die von APISIX bereitgestellten Funktionen wie plugin_config im Fokus standen. Diese Funktionen erleichterten die modularisierte Verwaltung und Wiederverwendung von Konfigurationen auf Gateway-Ebene erheblich. Die Implementierung von APISIXs plugin_config und verwandten Funktionen vereinfachte nicht nur den Konfigurationsprozess, sondern verbesserte auch die Gesamteffizienz und Wartbarkeit unseres Nord-Süd-Gateways. Dieses Upgrade markierte einen entscheidenden Schritt hin zu einem organisierten, modularen und wiederverwendbaren Konfigurationsmanagement.

Zusammenfassung

Von April 2023, als diese führende Fluggesellschaft erstmals auf APISIX stieß, bis zur erfolgreichen Migration von NGINX zu APISIX in der Produktionsumgebung im Juli desselben Jahres, hat der gesamte Migrationsprozess zufriedenstellende Ergebnisse erzielt.

In den frühen Phasen der Migration befasste sich das technische Team mit verschiedenen historischen Konfigurationen und hatte Bedenken, ob APISIX-Plugins alle Funktionalitäten des bestehenden NGINX vollständig replizieren könnten. Das Endergebnis zeigte jedoch, dass APISIX-Plugins mehr als in der Lage waren, diese Herausforderung zu meistern.

Zusammenfassend bot APISIX eine elegantere Lösung und half der führenden Fluggesellschaft, in eine neue technische Phase einzutreten. Es hat die verschiedenen Probleme, die wir mit NGINX hatten, perfekt gelöst, und sein reichhaltiges Plugin-Set ermöglicht es der Fluggesellschaft, verschiedene neue Anforderungen der Kunden problemlos zu bewältigen.