Warum ist Apache APISIX das beste API-Gateway?

Heutzutage werden Mobiltelefone für alle möglichen Dinge verwendet, und im AppStore sind verschiedene Anwendungen verfügbar, darunter soziale Medien, Utility-Apps, Spiele, Lifestyle-Apps, Online-Shopping usw. Die Entwicklung dieser Apps ist untrennbar mit APIs verbunden. Daher müssen Unternehmen, die Dienstleistungen über APIs anbieten, ein zuverlässiges API-Gateway wählen, um die Geschwindigkeit, Stabilität und Sicherheit ihrer Dienste zu gewährleisten.

In der API-Gateway-Landschaft der CNCF gibt es fast 20 Arten von API-Gateways (ohne die Dienste von Cloud-Anbietern), darunter Apache APISIX, Kong, Tyk usw. Viele von ihnen behaupten, das beliebteste Open-Source-API-Gateway-Projekt oder das nächste Generation API-Gateway zu sein, aber sind sie das wirklich?

In diesem Artikel werden wir mehrere API-Gateways in den Dimensionen der Beliebtheit bei Entwicklern, ihrer Open-Source-Lizenzen, ihrer Leistung und des gesamten Ökosystems analysieren. In dieser Analyse werden wir sehen, wie Apache APISIX das nächste Generation API-Gateway ist und in vielen Aspekten besser abschneidet als seine Mitbewerber.

Software-Ingenieure kennen es gut

Software-Ingenieure sind die Benutzer und Entwickler von APIs und API-Gateways, daher ist die Beliebtheit bei Ingenieuren ein direkter Indikator für den Trend. Unten ist ein Diagramm, das die Gesamtzahl der GitHub-Mitwirkenden von vier API-Gateways vergleicht: Apache APISIX, Kong, Tyk und Gloo.

Wir können aus dem Diagramm sehen, dass sowohl Kong als auch Tyk um 2015 herum begannen, während Apache APISIX und Gloo später im Jahr 2019 starteten. Noch bedeutender ist, dass wir sehen können, dass das jüngste Apache APISIX die steilste Kurve unter allen hat und mehr als 320 Mitwirkende angesammelt hat, was den zweitplatzierten Kong um 57 Personen übertrifft und damit das API-Gateway-Projekt mit den meisten Mitwirkenden ist.

Abgesehen von der Gesamtzahl der Mitwirkenden ist die Anzahl der monatlich aktiven Mitwirkenden von größerer Bedeutung. Die monatlich aktiven Mitwirkenden für Tyk lagen nur bei etwa 5 und überschritten selten 10, während Kong und Gloo zwischen 10 und 20 schwankten. In der Zwischenzeit hat Apache APISIX stabil über 20 monatlich aktive Mitwirkende und fast 40 auf dem Höhepunkt, was es zum aktivsten API-Gateway-Projekt macht.

Hinter den vier Open-Source-API-Gateway-Projekten stehen vier entsprechende kommerzialisierte Unternehmen. Ein weiterer Indikator, der APISIX hervorhebt, ist das Verhältnis der Anzahl der monatlich aktiven Mitwirkenden zur Anzahl der Mitarbeiter.

Stand 2022 haben Kong und Tyk ein Verhältnis von 4 %, und Gloo hat ein Verhältnis von 24 %. Im Gegensatz dazu erreicht APISIX fast 100 %. Der Grund dafür ist, dass das Unternehmen API7.ai von Anfang an, als es das APISIX-Projekt startete, kontinuierlich in die Open-Source-Community investiert hat und sich unter Entwicklern einen Ruf erworben hat.

Open-Source-Lizenz: Der wichtigste Faktor bei der Wahl eines Open-Source-API-Gateways

Seit MongoDB 2018 seine Open-Source-Lizenz auf SSPL (Server Side Public License) geändert hat, müssen Unternehmen ihren eigenen Code open-sourcen, wenn MongoDB als verwalteter Dienst verwendet wird. Daher müssen Unternehmen die Open-Source-Lizenz eines Projekts ernsthaft in Betracht ziehen, wenn sie ein Projekt auswählen.

Oberflächlich betrachtet verwenden Apache APISIX, Kong und Gloo alle die kommerziell freundliche Apache License Version 2.0, und Tyk verwendet die Mozilla Public License Version 2.0. Tiefer gehend sind Kong, Gloo und Tky jedoch alle von kommerzialisierten Open-Source-Anbietern unterstützt. Sie können ihre Lizenz jederzeit ändern, genau wie MongoDB, was die freie Nutzung durch Public Clouds oder andere Unternehmen einschränkt und Sie zwingt, für den Zugriff auf neue Versionen zu bezahlen.

Niemand kennt die Wahrscheinlichkeit von Lizenzänderungen. Dieses Risiko ist jedoch wie das Damoklesschwert, das über den Benutzern hängt.

Unter solchen Umständen ist die Wahl eines Open-Source-Projekts der Apache Software Foundation (ASF) oder der CNCF die beste Wahl, da sie die Lizenz des Projekts nicht ändern können. Apache APISIX ist ein solches Projekt. Es ist ein Top-Level-Projekt der ASF, was bedeutet, dass kein kommerzielles Unternehmen die absolute Kontrolle über das Apache APISIX-Projekt hat, alle Codes gehören der ASF und die Lizenz wird nicht geändert. Unternehmensbenutzer können es frei verwenden, ohne sich Sorgen machen zu müssen, Anfrage-E-Mails von Anwälten und Compliance-Abteilungen zu erhalten.

Leistung von Apache APISIX, Kong und Gloo

Eine häufig gestellte Frage in der Community: Welches hat die bessere Leistung, das auf Envoy basierende Gloo oder das auf NGINX basierende APISIX? Obwohl die Leistung nicht das kritischste Metrik ist, ist sie zweifellos das direkteste Metrik. Die folgende Tabelle zeigt die Benchmark-Ergebnisse von Apache APISIX und Gloo. Die QPS von Apache APISIX ist 4,6-mal so hoch wie die von Gloo, und die Latenz von Apache APISIX beträgt nur 7 % der von Gloo.

Die Wahl von NGINX oder Envoy ist nicht der Hauptfaktor für den Leistungsunterschied, sondern die zugrunde liegende Optimierung, die APISIX in seinem Quellcode vorgenommen hat. Selbst im Vergleich zu KONG, das ebenfalls auf NGINX basiert, hat APISIX einen großen Leistungsvorteil. Das folgende Diagramm stammt aus dem GigaOm-Bericht über die Tests der Enterprise Edition von Kong und der Enterprise Edition von AP7 (Sie können uns für die vollständigen Daten kontaktieren).

Die Latenz von Kong ist zehn- oder sogar hundertmal höher als die von API7 (Enterprise Edition, erstellt von den Autoren von Apache APISIX).

Warum hat APISIX einen so großen Leistungsvorteil? Es gibt keine Geheimnisse vor dem Code.

Reden ist billig, zeig mir den Code

Lassen Sie uns nun Apache APISIX, Kong und Gloo aus technischer Sicht analysieren. Der Vorteil von Apache APISIX beruht hauptsächlich auf der Optimierung und Innovation des Quellcodes. Die Vorteile dieser Technologien spiegeln sich nicht unbedingt in einem einfachen PoC (Proof of Concept) wider, sondern zeigen sich in einer komplexeren Produktionsumgebung.

Vor dem Aufkommen des APISIX-Projekts gab es viele kommerzielle API-Gateways oder Open-Source-API-Gateway-Produkte. Diese Produkte speicherten API-Daten, Routing-Informationen, Zertifikate und Konfigurationsdaten in einer relationalen Datenbank. Die Vorteile der Speicherung dieser Daten in relationalen Datenbanken sind sehr offensichtlich. Benutzer können SQL-Anweisungen verwenden, um flexible Abfragen durchzuführen, und es ist auch bequem für Benutzer, Backups und nachfolgende Wartungen durchzuführen.

Das Gateway ist jedoch eine Middleware, die den gesamten Datenverkehr vom Client verarbeitet. Die Anforderung an die Verfügbarkeit ist extrem hoch. Wenn das API-Gateway von einer relationalen Datenbank abhängig ist, bedeutet dies, dass das API-Gateway ebenfalls beeinträchtigt wird, sobald die relationale Datenbank ausfällt (z. B. Ausfall oder Datenverlust), und die Verfügbarkeit des gesamten Systems leidet ebenfalls.

Um den Schaden zu verringern, strukturierte APISIX seine Architektur so, dass die Möglichkeit von Ausfällen und Datenverlust vermieden wird. APISIX verwendete etcd, um Konfigurationsdaten zu speichern, anstatt einer relationalen Datenbank. Die Vorteile davon sind wie folgt:

1. Es ist besser an die Cloud-native-Architektur angepasst
2. Es ist eine bessere Darstellung des für das API-Gateway benötigten Datentyps
3. Es wird eine höhere Verfügbarkeit haben
4. Änderungen können auf Sub-Millisekunden-Ebene benachrichtigt werden

Nach der Verwendung von etcd zur Speicherung von Konfigurationsdaten müssen Benutzer nur etcd-Updates auf Datenänderungen überwachen. APISIX kann die neueste Konfiguration innerhalb von Millisekunden erhalten und so einen Echtzeiteffekt erzielen. Wenn wir jedoch die Datenbank abfragen würden, könnte es 5-10 Sekunden dauern, um die neuesten Konfigurationsinformationen zu erhalten. Daher macht die Verwendung von etcd als Speicherschema APISIX nicht nur cloud-nativer, sondern auch hochverfügbarer.

Hochleistungs-Routenabgleichsalgorithmus

Um eine Anfrage zu verarbeiten, muss das API-Gateway den Zielausdruck mit den Host-Informationen, der URI, den HTTP-Methoden und anderen Informationen jeder Anfrage abgleichen. Daher ist ein effizienter Abgleichsalgorithmus entscheidend. Der hashbasierte Algorithmus hat eine gute Leistung, kann jedoch keine unscharfen Abgleiche durchführen. Reguläre Ausdrücke können unscharfe Abgleiche durchführen, aber die Leistung ist nicht so gut. Die Lösung von Apache APISIX besteht darin, einen Baum zu verwenden, eine effiziente Suchdatenstruktur, die unscharfe Abgleiche unterstützt. Genauer gesagt verwendet Apache APISIX einen Radix-Baum (komprimierter Präfixbaum), eine Datenstruktur, die nur Zwischenknoten mit einem Kind komprimiert. Unter allen bekannten API-Gateway-Produkten ist Apache APISIX das erste, das den Radix-Baum im Routenabgleich anwendet und das Szenario unterstützt, in dem ein Präfix mehrere Routen abgleichen kann. Für die Implementierungsdetails siehe lua-resty-radixtree.

Beim Abgleich einer Anfrage wird der Algorithmus mit dem Radix-Baum progressiv abgeglichen, mit einer Komplexität von O(K) (K ist die Länge der URI in der Route und unabhängig von der Anzahl der APIs). Dieser Algorithmus eignet sich sehr gut für Szenarien, in denen es eine große Anzahl von Routen gibt, wie z. B. in Public Clouds oder CDNs. Er hat auch kein Problem mit einer großen Anzahl von Routen, die schnell zunehmen.

Hochleistungs-IP-Abgleichsalgorithmus

Eine IP-Adresse hat zwei Notationen: die Standard-IP-Notation und die CIDR-Notation, wobei 32-Bit-IPv4 als Beispiel genommen wird:

• Standard-IP-Notation: 192.168.1.1
• CIDR-Notation: 192.168.1.1/8

Der IP-Abgleich und der Routenabgleich von Apache APISIX verwenden unterschiedliche Algorithmen. Nehmen wir die IP 192.168.1.1 als Beispiel. Da der Bereich jedes IP-Segments 0 bis 255 beträgt, können wir davon ausgehen, dass die IP-Adresse aus vier 16-Bit-Ganzzahlen besteht und die Länge der IP fest ist. Daher können wir einen effizienteren Algorithmus verwenden, um den Abgleich abzuschließen.

Angenommen, es gibt eine IP-Bibliothek mit 500 IPv4-Einträgen, wird APISIX die 500 IPv4-Einträge in der Hashtabelle zwischenspeichern und die Hashtabelle für den IP-Abgleich verwenden. Die Zeitkomplexität beträgt O(1). Andere API-Gateways führen den IP-Abgleich durch Listeniteration durch, und jede an das Gateway gesendete Anfrage kann bis zu 500 Mal iteriert werden. Daher verbessert der hochpräzise IP-Abgleichsalgorithmus von APISIX die Effizienz von Szenarien, die eine massive IP-Allowlist- und Denylist-Abgleichung erfordern (z. B. WAF), erheblich.

Routenverfeinerung

API-Gateways gleichen die vordefinierten Regeln mit verschiedenen Informationen der Anfragen ab, wie z. B. den Host-Informationen, der URI, den URI-Abfrageparametern, den URI-Pfadparametern, den HTTP-Methoden, den Anfrageheadern usw. Diese Informationen werden von den meisten API-Gateways unterstützt. Apache APISIX unterstützt jedoch zusätzlich zu diesen noch mehr Daten, um komplexere Fälle zu lösen.

Zunächst unterstützt Apache APISIX NGINX-interne Variablen, was bedeutet, dass wir Dutzende von NGINX-internen Variablen als Abgleichsparameter verwenden können, darunter uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_name.

Eine Liste der NGINX-internen Variablen finden Sie unter NGINX-Variablen.

Zweitens unterstützt Apache APISIX bedingte Ausdrücke als Abgleichsregeln, und seine Struktur ist [var, operator, val], ...]], wobei:

• var-Werte können NGINX-interne Variablen sein.
• operator unterstützt gleich, größer als, kleiner als, reguläre Ausdrücke, enthält usw.

Angenommen, der Ausdruck ist ["arg_name", "==", "json"], bedeutet dies, ob es einen Parameterwert von name gibt, der gleich json in den URI-Abfrageparametern der aktuellen Anfrage ist. Apache APISIX implementiert diese Funktion über seine Bibliothek lua-resty-expr. Einzelheiten finden Sie unter lua-resty-expr. Diese Funktion gibt dem Benutzer viel Flexibilität und ist hoch erweiterbar.

Darüber hinaus erlaubt Apache APISIX den Benutzern, die TTL (Time to Live) von Routen festzulegen.

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

Der obige Code bedeutet, dass APISIX die Routing-Konfiguration nach 60 Sekunden automatisch löscht, was für einige temporäre Verifizierungsszenarien wie Canary Releases erforderlich ist. Es ist auch sehr bequem für das Online-Traffic-Splitting, eine Funktion, die andere Gateway-Produkte nicht haben.

Schließlich unterstützt Apache APISIX benutzerdefinierte Filterfunktionen. Man kann benutzerdefinierte Lua-Funktionen im Parameter filter_func schreiben, zum Beispiel:

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

Der Eingabeparameter von filter_func ist vars, und NGINX-Variablen können aus vars abgerufen werden, und dann kann die Filterlogik angepasst werden.

Unterstützung für Mehrsprachige Plugins

Benutzer müssen oft einige der Entwicklungen und Systemintegrationen des API-Gateways an bestimmte Szenarien anpassen.

APISIX unterstützt derzeit mehr als 80 Plugins, aber es ist immer noch schwierig, alle Benutzerszenarien abzudecken. Daher entwickeln die meisten Unternehmen benutzerdefinierte Plugins für spezifische Geschäfte, integrieren mehr Protokolle und Systeme über das Gateway und erreichen eine einheitliche Verwaltung auf der Gateway-Ebene.

In früheren Versionen von APISIX konnten Entwickler nur Lua verwenden, um Plugins zu entwickeln. Obwohl Plugins, die in nativen Programmiersprachen entwickelt wurden, eine sehr hohe Leistung haben, erfordert das Erlernen von Lua, einer neuen Programmiersprache, Zeit und Lernkosten.

Als Reaktion auf diese Situation bietet APISIX zwei Lösungen.

Die erste Lösung besteht darin, mehr Mainstream-Programmiersprachen (wie Java, Python, Go usw.) über Plugin Runner zu unterstützen. Mit Plugin Runner können Backend-Ingenieure über lokales RPC kommunizieren, um APISIX-Plugins mit den Programmiersprachen zu entwickeln, mit denen sie vertraut sind. Der Vorteil davon ist, die Entwicklungskosten zu senken und die Entwicklungseffizienz zu verbessern. Der Nachteil wird Leistungsverluste sein. Gibt es also eine Möglichkeit, die nahezu native Leistung von Lua mit Hochsprachen zu erreichen, die Entwickler kennen?

Die zweite Lösung besteht darin, Wasm zu verwenden, um Plugins zu entwickeln, wie im linken Teil der obigen Abbildung gezeigt. Wasm (WebAssembly) wurde zunächst als eine neue Technologie verwendet, die in Browsern läuft, aber jetzt zeigt es auch auf der Serverseite seine Vorteile. Wir haben Wasm in APISIX eingebettet, und Benutzer können Wasm verwenden, um Wasm-Bytecode zu kompilieren, der in APISIX läuft. Um Wasm zu nutzen, haben wir ein Wasm-Plugin entwickelt, in dem Benutzer nahezu native APISIX-Plugins mit Hochsprachen entwickeln können.

Dadurch können Benutzer Lua, Go, Java, Python, Node.js und Wasm verwenden, um benutzerdefinierte Plugins auf APISIX zu schreiben. Indem die Entwicklung erleichtert wird, öffnet es die Tür für die APISIX-Plugin-Entwicklung.

Fazit

In diesem Artikel haben wir API-Gateway-Produkte aus mehreren Perspektiven wie Software-Ingenieure, Open-Source-Protokolle, Leistungsbewertung, Technologie und Ökosystem analysiert und verglichen. Wir können sehen, dass Apache APISIX in vielen Aspekten überlegen ist, ein Pionier im API-Netzwerk.

Apache APISIX ist nicht nur ein API-Gateway, das Nord-Süd-Datenverkehr verarbeiten kann, sondern hat auch Open-Source-Produkte wie APISIX Ingress Controller und Service Mesh.

Es bietet auch APISIX-basierte Enterprise-Produkte und SaaS-Produkte.

Probieren Sie Apache APISIX und API7 Enterprise-Produkte noch heute aus!