Technische Erkundungen des Open-Source API-Gateways Apache APISIX

Hintergrund

Apache APISIX ist ein dynamisches, Echtzeit-, Hochleistungs-Open-Source-API-Gateway, das umfangreiche Traffic-Management-Funktionen wie Lastenausgleich, dynamisches Routing, Canary Release, Circuit Breaking, Authentifizierung und Beobachtbarkeit bietet.

Als API-Gateway kann Apache APISIX Unternehmen dabei helfen, API- und Microservice-Traffic in Szenarien wie Gateways, Kubernetes Ingress und Service Mesh schnell und sicher zu verarbeiten. Darüber hinaus kann es sowohl den Nord-Süd-Traffic (vom Client zum Server) als auch den Ost-West-Traffic (zwischen verschiedenen Unternehmens-Microservices) handhaben.

APISIX wurde am 6. Juni 2019 als Open-Source-Projekt veröffentlicht und im Oktober 2019 an die Apache Software Foundation gespendet. Innerhalb weniger Monate wurde es zu einem Top-Level-Projekt der Apache Software Foundation.

Warum konnte APISIX in so kurzer Zeit so erfolgreich werden? Welche technischen Innovationen hat APISIX vorangetrieben? Warum entscheiden sich immer mehr Entwickler und Unternehmen für APISIX? Lasst es uns herausfinden.

Hauptmerkmale von Apache APISIX

Unabhängig von Datenbanken

Bevor APISIX auf den Markt kam, gab es bereits viele kommerzielle oder Open-Source-API-Gateway-Projekte. Ein potenzielles Problem dieser Konkurrenten besteht darin, dass die meisten dieser Produkte ihre API-Daten, Konfigurationsinformationen, Zertifikatskonfigurationen und Routing-Informationen in einer relationalen Datenbank speichern.

Die offensichtlichen Vorteile der Speicherung in einer relationalen Datenbank sind, dass Benutzer flexible Abfragen mit SQL-Anweisungen durchführen und Backups sowie Folgewartungen einfach durchführen können.

Allerdings hat jede Medaille zwei Seiten. Als grundlegende Middleware verarbeitet das API-Gateway den gesamten Client-Traffic, was höhere Anforderungen an die Verfügbarkeit stellt. Wenn Ihr API-Gateway von einer relationalen Datenbank abhängt, wird das Gateway beeinträchtigt, sobald ein Datenbankfehler auftritt, wie z. B. ein Absturz oder Datenverlust. In diesem Fall wird die Gesamtverfügbarkeit des Systems stark eingeschränkt.

Daher haben die Designer von APISIX versucht, solche Probleme auf der Ebene der zugrunde liegenden Architektur zu vermeiden.

Die Architektur von APISIX besteht hauptsächlich aus zwei Teilen. Der erste Teil, die Datenebene, ist die Komponente, die die Anfragen und den Traffic der Clients verarbeitet. Sie unterstützt Authentifizierung, Zertifikatsentlastung, Protokollanalyse und Beobachtbarkeit. Die Datenebene speichert keine Daten und ist somit eine zustandslose Struktur.

Der zweite Teil ist die Steuerungsebene. APISIX verwendet auf der Steuerungsebene keine traditionelle Konfigurationsspeicherung wie MySQL, sondern etcd.

Die Vorteile dieser Vorgehensweise:

1. Bessere Übereinstimmung mit der Cloud-Native-Architektur von Produkten
2. Bessere Eignung für die Datentypen, die vom API-Gateway gespeichert werden
3. Bessere Darstellung der Merkmale hoher Verfügbarkeit
4. Millisekundenschnelle Benachrichtigungen über Änderungen

Durch die Verwendung von etcd muss die Datenebene nur die Änderungen von etcd überwachen. Wenn Sie die Datenbank abfragen, kann es 5-10 Sekunden dauern, um die neueste Konfiguration zu erhalten. Wenn Sie jedoch die Änderungen der etcd-Konfiguration überwachen, erhalten Sie innerhalb von Millisekunden Feedback, um den Echtzeiteffekt zu erzielen.

Daher macht die Verwendung von etcd anstelle einer relationalen Datenbank APISIX auf der untersten Ebene besser mit der nativen Cloud-Umgebung kompatibel und stärkt seine Vorteile in Bezug auf hohe Verfügbarkeit.

Plugins für mehrere Programmiersprachen

API-Gateways unterscheiden sich etwas von Datenbanken und anderen Middleware. Im Vergleich zu letzteren werden Gateways häufiger in der individuellen Entwicklung und Systemintegration verwendet.

Obwohl APISIX viele offizielle Plugins veröffentlicht hat, ist es immer noch schwierig, alle Anwendungsszenarien für verschiedene Benutzer abzudecken. Daher müssen in der Praxis mehr oder weniger benutzerdefinierte Plugins für das Geschäft entwickelt werden. APISIX integriert auch mehr Protokolle oder Systeme über das Gateway und erreicht schließlich eine einheitliche Verwaltung auf der Gateway-Ebene.

Anfangs unterstützte APISIX nur die Entwicklung von Plugins in der Programmiersprache Lua. Der Vorteil ist, dass die entwickelten Plugins durch die zugrunde liegende Optimierung der nativen Programmiersprache eine hohe Leistung erzielen können. Es gibt jedoch einen offensichtlichen Nachteil: Das Erlernen von Lua, einer neuen Sprache, erfordert Zeit und Lernkosten.

Im Wesentlichen löst APISIX die Probleme auf zwei Arten.

Die erste Methode besteht darin, mehr Mainstream-Programmiersprachen wie Java, Python, Go usw. über den Runner Plugin zu unterstützen. Wenn Sie ein Backend-Entwickler sind, sollten Sie mindestens eine dieser Sprachen kennen; dann können Sie das RPC-Protokoll leicht nutzen und ein APISIX-Plugin in der Ihnen vertrauten Sprache entwickeln.

Einerseits ist dies vorteilhaft, um die Entwicklungskosten zu senken und die Entwicklungseffizienz zu steigern. Andererseits gibt es auf der Leistungsebene eine gewisse Latenz. Daher stellt sich die Frage: Gibt es eine Lösung, die die native Leistung von Lua erreichen und gleichzeitig die Hochsprache berücksichtigen kann?

Hier kommt die zweite Methode ins Spiel, die im linken Teil des obigen Bildes dargestellt ist. WebAssembly wurde zunächst als Technologie auf der Frontend- oder Browserseite verwendet und bietet allmählich seine Vorteile auf der Serverseite.

Durch die Einbettung von WebAssembly in APISIX können Benutzer es verwenden, um in WebAssembly-Bytecode zu kompilieren, der in APISIX ausgeführt wird. Der ultimative Effekt besteht darin, ein APISIX-Plugin effizient zu entwickeln, das sowohl leistungsstark als auch in Hochsprachen geschrieben ist.

In der aktuellen Version von APISIX können Benutzer Lua, Go, Python, Wasm und andere Methoden verwenden, um benutzerdefinierten Code basierend auf APISIX zu erstellen. Das Design senkt die Schwelle für Entwickler und bietet mehr Möglichkeiten für die Funktionen von APISIX.

Hot Reloading von Plugins

APISIX hat zwei bedeutende Fortschritte im Vergleich zu NGINX: APISIX unterstützt Cluster-Management und dynamisches Neuladen.

Wenn Sie NGINX verwendet haben, wissen Sie, dass alle Konfigurationen von NGINX in der Konfigurationsdatei nginx.conf geschrieben werden. Um die Clustersteuerung durchzuführen, müssen Sie die nginx.conf-Datei auf jedem einzelnen Server ändern. Es gibt keine zentrale Verwaltungssteuerungsebene in diesem gesamten Prozess. Jeder NGINX ist eine Kombination aus Datenebene und Steuerungsebene. Die Verwaltungskosten werden extrem hoch sein, wenn Benutzer Dutzende oder Hunderte von NGINX-Servern haben.

In dem oben genannten Szenario muss jeder NGINX-Server nach der Änderung der nginx.conf-Datei neu gestartet werden, um zu funktionieren. Zum Beispiel müssen Sie für Zertifikatsaktualisierungen oder Upstream-Änderungen zuerst die Konfigurationsdatei ändern und den Server neu starten, damit die Änderungen wirksam werden. Diese Methode ist gerade noch akzeptabel, wenn Ihre Anfrage nicht besonders groß ist. Da jedoch APIs und Microservices zunehmend auftauchen, wird die Auswirkung auf den Client enorm sein, wenn der Server für jede Änderung neu gestartet werden muss.

• Hot Updates und Hot Plugins: Aktualisiert kontinuierlich seine Konfigurationen und Plugins ohne Neustarts!
• Proxy Rewrite: Unterstützt das Umschreiben des Hosts, der URI, des Schemas, der Methode und der Header der Anfrage, bevor sie an den Upstream gesendet wird.
• Response Rewrite: Setzt einen angepassten Antwortstatuscode, -body und -header für den Client.
• Dynamischer Lastenausgleich: Round-Robin-Lastenausgleich mit Gewichtung.
• Hash-basierter Lastenausgleich: Lastenausgleich mit konsistentem Hashing von Sitzungen.
• Health Checks: Aktiviert Gesundheitsprüfungen auf dem Upstream-Knoten und filtert automatisch ungesunde Knoten während des Lastenausgleichs, um die Systemstabilität zu gewährleisten.
• Circuit-Breaker: Intelligente Überwachung von ungesunden Upstream-Diensten.
• Proxy Mirror: Bietet die Möglichkeit, Client-Anfragen zu spiegeln.
• Traffic Split: Ermöglicht es Benutzern, prozentuale Anteile des Traffics zwischen verschiedenen Upstreams schrittweise zu lenken.

Das obige Bild listet die Komponenten auf, bei denen APISIX derzeit Hot Reloading implementiert. Wir können sehen, dass der Code in Echtzeit vom Upstream bis zum Zertifikat und sogar zum Plugin wirksam wird. Einige Community-Mitglieder können verstehen, warum der Upstream und die Zertifikate dynamisch sind, da sich die Daten häufig ändern. Sie würden jedoch fragen, warum die Änderung des Plugins dynamisch sein muss, da sie der Ansicht sind, dass die Änderung des Plugins selten ist, was es unnötig erscheinen lässt, hochaktiv zu sein.

Als die zugrunde liegenden Designer von APISIX hoffen wir, dass es letztendlich dynamisch sein kann, was einen erheblichen Vorteil darstellt, um mehr Möglichkeiten für Unternehmen zu schaffen. Zum Beispiel können Benutzer Code beheben, während sie das Debug-Plugin ändern, ohne den Plugin-Code zu ändern. In solchen Fällen kann der Benutzer das Problem jederzeit reproduzieren und aufzeichnen, ohne neu zu starten. Das Plugin mit Debugging-Funktion in Kombination mit dem Hot-Reloading-Mechanismus wird sehr flexibel sein und Entwicklern Zeit und Mühe bei der Fehlerbehebung sparen.

Dynamische Orchestrierung von Plugins

Neben Hot Reloading unterstützt APISIX auch die Echtzeit-Orchestrierung zwischen Plugins. Die dynamische Orchestrierung bringt auch unendliche Möglichkeiten für den Betrieb von Plugins.

Was ist Plugin-Orchestrierung? Wenn wir verschiedene Anforderungen stellen, hoffen wir, eine Anfrage in ein Plugin zu verwandeln, wie beim Spielen mit LEGO. Wir können durch ein einheitliches Standardformat wie Formpassung und Schnittmenge eine unendliche Vielfalt möglicher Formen bauen, was einer der Freuden von LEGO ist. Für APISIX-Plugins erfüllt jedes Plugin einen unabhängigen Anwendungsfall. Wir können nicht aufhören zu fragen, ob es möglich ist, Benutzern zu ermöglichen, ihre Anforderungen mit Plugins anzupassen, als ob sie LEGO spielen würden.

Zum Beispiel, wenn es 100 Plugins in APISIX gibt, können Benutzer nur die Funktionen dieser 100 Plugins sehen, nicht jedoch ihre zugrunde liegende Flexibilität. Daher müssen wir bei der Entwicklung von Middleware überlegen, was das Produkt sein kann und wie wir mehr Möglichkeiten schaffen können, wenn Menschen es verwenden.

APISIX hat derzeit fast 100 Plugins, aber es bietet weit mehr als 100 Möglichkeiten. Daher wird die Kombination nach der Entwicklung seiner Fähigkeit in der Plugin-Anordnung 100 * 99 * 98 * 97 * 96 * ... betragen, was nahezu unendlich ist.

Zum Beispiel tritt normalerweise ein Fehlercode auf, nachdem Sie die Rate eines Benutzers begrenzt haben. Sie können versuchen, ein Protokollierungs-Plugin oder ein Fehlermeldungs-Plugin für die nachfolgende Aktivitätsaufzeichnung zu verbinden. Das Bild unten zeigt das Modell der Plugin-Orchestrierung von APISIX.

Diese Funktion hat einen versteckten Vorteil: Ein vollständiger Testsuite deckt den Code jedes Plugins ab. Wenn der Benutzer das Plugin anordnet, muss er keinen Code schreiben. Das Design wäre äußerst freundlich für Produktmanager, Sicherheitsingenieure und Betriebs- und Wartungsingenieure, die keine langen Stunden für Schulungen und Lernen aufwenden müssen. Stattdessen können sie ein neues APISIX-Plugin erstellen, indem sie Plugins ablegen, um einige Einstellungen anzupassen. Darüber hinaus ist die Qualität des neuen Plugin-Codes so hoch wie der offizielle Code des Open-Source-APISIX.

Gateway für allseitigen Traffic

Server-seitige Ingenieure, die einige Gateway-bezogene Entwicklungen durchführen, könnten mit zwei grundlegenden Konzepten vertraut sein: Nord-Süd-Traffic, der sich auf den Traffic von Clients, Browsern oder IoT-Geräten (Internet der Dinge) zum Server bezieht, und Ost-West-Traffic, der sich auf die gegenseitigen Aufrufe zwischen Systemen und Microservices innerhalb von Unternehmen bezieht.

Die Komponenten sind unterschiedlich, wenn es um die Handhabung von Nord-Süd- und Ost-West-Traffic geht. Zum Beispiel kann Nord-Süd-Traffic einen Lastenausgleicher durchlaufen, zum API-Gateway gehen und dann zu einem Service-Gateway gelangen. Deshalb gibt es Komponenten wie NGINX, APISIX und Spring Cloud Gateway. Bei der Handhabung von Ost-West-Traffic mit einem Service Mesh können Sie Komponenten wie Envoy verwenden, was viel erscheint, aber Sie können ihre Ähnlichkeiten erkennen, wenn Sie sich auf ihre Funktionen konzentrieren. Die meisten sind Plugins für Routing-Scheduling, dynamischen Upstream und sichere Authentifizierung. In diesem Fall können wir die Komponenten, die den Nord-Süd- und Ost-West-Traffic handhaben, vereinheitlichen? Der ideale Weg ist, dass, wenn eine Client-Anfrage den Server erreicht, alles von APISIX übernommen wird. Egal ob Nord-Süd oder Ost-West, der gesamte Traffic und die Daten werden über die Steuerungsebene kontrolliert. Dies ist mit der aktuellen Technologie von APISIX vollständig realisierbar.

Einige unserer Benutzer bestätigen bereits, dass dieser Modus die Betriebs- und Wartungskosten des Benutzers erheblich reduzieren kann. Gleichzeitig kann er die Komplexität verringern und dadurch die Reaktionsgeschwindigkeit des gesamten Systems verbessern. Darüber hinaus gibt ein solches positives Feedback eine klarere Richtung für nachfolgende Iterationen von APISIX vor, wodurch APISIX versuchen kann, mehr Funktionen und Rollen auf der Ebene des Full-Traffic-Gateways zu übernehmen.

Unterstützung für Multi-Service-Discovery-Komponenten

Das Gateway ist eine grundlegende, aber wichtige Komponente. Es verarbeitet alle Client-Anfragen und integriert sich mit verschiedenen Systemen und Open-Source-Projekten, was noch wichtiger ist.

Eine weitere wesentliche Komponente - Service Discovery und Registrierung - wird bei der Integration mit anderen Elementen verwendet. Benutzer werden verschiedene Dienste in separate Teile wie Eureka und Nacos platzieren. Folglich ist es in großen und langjährigen IT-Systemen üblich, dass mehrere Service-Discovery-Komponenten nebeneinander existieren.

In dieser Situation werden alle Traffic-Eingänge und -Ausgänge zu Gateways. Fast alle Gateways unterstützen nur eine Service-Discovery. Sie müssen eine separate Nacos-Service-Discovery-Komponente auf der A-Route und eine weitere Consul-Komponente auf der B-Route angeben. Folglich müssen Sie mehrere Gateways bereitstellen, um bestimmte Gateways verschiedenen Service-Discovery-Komponenten zuzuordnen.

Derzeit unterstützt APISIX nicht nur die Service-Discovery auf der Datenebene, sondern auch schrittweise die Service-Registrierung und Service-Discovery-Komponenten auf der Steuerungsebene. Es ist eine hocheffiziente Lösung für einige große und langfristige Unternehmensdienste. Sie können leicht eine Verbindung zu verschiedenen Service-Discovery- und Registrierungskomponenten herstellen, indem Sie nur ein API-Gateway bereitstellen.

Erforschung von Multi-Cloud- und Hybrid-Cloud-Szenarien

Wenn Benutzer das Gateway in einer Produktionsumgebung mit Cloud-Native-Architektur bereitstellen, müssen Multi-Cloud- und Hybrid-Cloud-Szenarien ein langfristiges technisches Szenario sein. Andererseits, wenn APISIX mit vollständigen Funktionen, Leistung, Plugins und Multi-Service-Discovery eingerichtet ist, kommt das Problem unweigerlich darauf an, wie Benutzer in einer Produktionsumgebung besser arbeiten können. Multi-Cloud- und Hybrid-Cloud-Szenarien stellen APISIX vor mehr Herausforderungen. Daher müssen folgende Details berücksichtigt werden.

1. Sowohl Upstream als auch Downstream unterstützen mTLS

Wir haben zuvor nicht erkannt, dass die Funktion zur Unterstützung des Upstream-mTLS eine hohe Priorität hat. Sobald es sich jedoch um ein Cross-Cloud-Szenario handelt, kann der Upstream ein Dienst auf einer anderen Cloud oder sogar ein anderer SaaS-Dienst sein. Daher ist es notwendig, den Upstream-mTLS zu unterstützen, um die Datensicherheit zu verbessern.

2. Vollständige Trennung der Steuerungsebene und der Datenebene

Im vergangenen Jahr wurden mehrere Sicherheitslücken von APISIX aufgedeckt, von denen die meisten aus der hybriden Bereitstellung seiner Steuerungs- und Datenebenen stammen. Mit anderen Worten, die Steuerungs- und die Datenebene befinden sich nach dem Start des APISIX-Dienstes im selben Dienst. Wenn also ein Hacker durch eine Sicherheitslücke in eine bestimmte Datenebene eindringt, kann er auch in die Steuerungsebene gelangen, um die gesamten Daten zu kontrollieren, was katastrophale Folgen haben kann.

3. Stärkung des Sicherheitsmanagements

Das Gateway speichert im Allgemeinen einige sensible Daten. Zum Beispiel können einige Benutzer das SSL-Zertifikat oder die kritischen Informationen für die Verbindung zu etcd auf dem Gateway speichern. In solchen Fällen kann es zu schwerwiegenden Datenlecks kommen, sobald etcd oder die Datenebene kompromittiert wird. Daher ist es beim Speichern einiger wesentlicher Informationen notwendig, eine Komponente wie Vault zu verwenden, die speziell für die Speicherung von Schlüsseln entwickelt wurde, um sensible Daten zu schützen.

4. Integration von mehr Cloud-Standards

Wir beabsichtigen sicherzustellen, dass Benutzer auf verschiedenen Cloud-Plattformen reibungslos laufen können, ohne etwas zu konfigurieren, in Multi-Cloud-Szenarien. Dies bedeutet nicht, dass Benutzer benutzerdefinierte Plugins konfigurieren müssen, sondern dass APISIX direkt Standards, APIs oder andere Dienste von verschiedenen Clouds integrieren kann. Dieser Modus kann Benutzern helfen, sich im Voraus anzupassen und Komfort und Bequemlichkeit für die spätere Nutzung zu gewährleisten.

Unterstützer von Apache APISIX

Während der Entwicklungsgeschichte von APISIX wurden viele technische Innovationen gemacht. Wachsende Community-Mitwirkende arbeiten Hand in Hand seit der Code-Konstruktionsphase, um APISIX zu einem integrierten API-Gateway zu machen. Heute hält APISIX dank der Bemühungen der Unterstützer eine schnelle Iteration aufrecht.

Die Iteration und Aktualisierung eines Open-Source-Produkts muss den Mitwirkenden und Benutzern zugeschrieben werden.

Als APISIX vor drei Jahren an die Apache Software Foundation gespendet wurde, war es ein unreifes Projekt mit nur 20 Mitwirkenden. Glücklicherweise hat APISIX aufgrund seiner raschen Entwicklung weltweit mehr Benutzer, Mitwirkende und Unternehmen angezogen. Zum Beispiel gehören zu unseren Kunden Unternehmen wie Tencent, WPS, Sina Weibo und iQiyi, die täglich Milliarden von API-Aufrufen verarbeiten. Darüber hinaus sind viele internationale Benutzer aus verschiedenen Branchen wie NASA, European Factory Platform, Swisscom usw. in unserer Kundenliste.

Nehmen wir WPS als Beispiel. Es ist ein SaaS-Bürosoftwareunternehmen in China, das Software wie Microsoft Office 365 anbietet. Egal, ob Sie mit mehreren Personen auf Mobiltelefonen, Browsern oder Endgeräten arbeiten, Dutzende oder Hunderte von Benutzern können dasselbe Dokument bearbeiten und die Änderungen gleichzeitig sehen. Diese Funktion wird durch verschiedene API-Aufrufe realisiert.

Die meisten großen Unternehmen verarbeiten Milliarden von API-Aufrufen, mit einem Spitzenwert von QPS, der eine Million übersteigt. Ein solcher Nutzungsumfang ermöglicht es APISIX auch, Feedback von echten Benutzern in großem Maßstab zu erhalten. Dank der Unterstützung dieser Unternehmensbenutzer hat sich APISIX schnell zu einem ausgereiften Open-Source-Projekt entwickelt.

Darüber hinaus teilen viele Benutzer ihre Erfahrungen oder Code-Funktionsiterationen bei der Verwendung von APISIX in der Community, was zu gegenseitigem Nutzen und einer Win-Win-Situation für beide Seiten führt. Es zeigt sich, dass Benutzer APISIX nicht nur als ein gutes Produkt, sondern auch als ein lohnenswertes Open-Source-Projekt betrachten. Nur wenn wir das Vertrauen der Entwickler gewinnen, haben wir die Möglichkeit, ein wertvolles Open-Source-Projekt zu werden.

Mitwirkende passen die Erfahrungen und das Feedback an, um viele Produktfunktionen zu schaffen; Benutzer können diese Funktionen nutzen, um den Unternehmen Wert zu bringen. Ein positiver Kreislauf entsteht, was das Wesen von Open Source ausmacht. Wir suchen immer nach dieser Art von Wahrheit, anstatt blindlings den Blasen zahlreicher Anhänger nachzujagen.

APISIX 3.0 Vorschau

Bisher haben wir viel darüber gesprochen, was APISIX in der Vergangenheit und jetzt getan hat. Der Entwicklungsprozess von APISIX kann in mehrere Phasen unterteilt werden.

APISIX 1.0 bestand darin, sein Framework zu erstellen, die zugrunde liegende Architektur zu stärken und einige wesentliche Funktionen des API-Gateways zu präsentieren. Wir haben in der Version 2.0 tiefer geforscht, wodurch die unterste Ebene flexibler und die Architektur reifer wurde.

Für ein ausgereiftes Open-Source-Projekt liegt das Zeichen seiner Reife nicht in seiner großartigen Funktion, sondern darin, den Benutzern und Entwicklern ein besseres Erlebnis zu bieten.

In der aktuellen Phase hat APISIX viele technische Erkundungen und Innovationen durchgeführt, aber die Benutzererfahrungen wurden nicht vollständig berücksichtigt. Das Problem zeigt sich in instabiler Dokumentationsqualität und einem Mangel an Tutorial-Videos. Daher sind viele Benutzer ratlos, wenn sie zum ersten Mal mit APISIX in Kontakt kommen. Sie wissen nicht, wie sie es verwenden oder bestimmte Funktionen auf verschiedene Anwendungsfälle anwenden sollen, und sie sind unsicher, welchen einzigartigen Wert APISIX Unternehmen bieten kann.

Daher werden wir in der nächsten APISIX 3.0-Version versuchen, ähnliche Probleme zu lösen und viele Mängel, die für die Entwicklererfahrung unfreundlich sind, zu überarbeiten. Zum Beispiel werden wir die API neu gestalten, um die Abhängigkeit von bestimmten Rückgabewerten von etcd zu entfernen, und die offizielle Dokumentation erneuern, um benutzerfreundlicher mit klaren Beschreibungen zu sein. Auf der Funktionsebene werden auch die Steuerungsebene und die Datenebene getrennt, um die Sicherheit zu erhöhen; es unterstützt mehr Layer-4-Protokolle und RPC-Protokolle, sodass Benutzer schnell Traffic aus allen Gateway-Richtungen erhalten können.

Nach der Implementierung der oben genannten Funktionen wird APISIX 3.0 sicherer, zuverlässiger und einfacher zu bedienen sein. Wir legen immer Wert auf hervorragende Operationen und Benutzererfahrungen. Wir hoffen, dass APISIX Anfragen von allen APIs und Microservices weltweit verarbeiten und Unternehmen dabei helfen kann, API- und Microservice-Traffic effizienter zu verwalten.

Es wird erwartet, dass APISIX Ende 2022 eine neue Version, 3.0, veröffentlichen wird. Wir hoffen, dass Sie weiterhin die Trends der neuesten Version von APISIX verfolgen und aktiv an der Mitwirkung am Apache APISIX-Projekt teilnehmen werden.

Die Zukunft von APISIX

Die Entwicklung und der Ersatz von Server-seitigen Technologien sind sehr schnell, da viele beliebte Technologien und Frameworks vor fünf Jahren allmählich verschwinden. Der Grund ist nicht, dass Ingenieure neue Dinge bevorzugen, sondern dass diese Technologien die tatsächlichen Bedürfnisse von Ingenieuren und Unternehmen nicht erfüllen können. Ihr Schicksal ist besiegelt: Sie werden abgelöst. Die entscheidende Realität sagt uns, dass Technologie Geschäfte und Produkte bedienen muss und nicht ohne Übereinstimmung mit den aktuellen Marktanforderungen überleben kann.

"Baue keine Burg auf einem Sumpf." Dieser Spruch erinnert die Entwickler von Apache APISIX immer daran, dass sie sich auf tatsächliche Bedürfnisse und Szenarien verlassen sollten, um seine Entwicklung und Evolution zu leiten. Andernfalls wird das Produkt allmählich von Ingenieuren aufgegeben.

Wie können wir die Technologie von Apache APISIX an der Spitze der Branche halten? Es ist die entscheidende Frage, ob Apache APISIX weiterhin Entwickler und Unternehmensbenutzer in der Zukunft anziehen kann. Die Antwort ist einfach: Schließen Sie sich schnell wachsenden Unternehmen und Ingenieuren an, wachsen Sie gemeinsam und unterstützen Sie sich gegenseitig. Dies stellt sicher, dass Apache APISIX immer an der Spitze der Technologie steht. Nur so hat APISIX das Potenzial, ein weltweit führendes, immergrünes Open-Source-Projekt zu werden.

Die Zukunft von APISIX besteht darin, Serverless-Szenarien besser zu unterstützen, das Service Mesh zu verbessern, API-Lebenszyklusplattformen zu erstellen und die Benutzererfahrung in der Public Cloud zu verbessern. Diese werden nicht von einigen internen Entwicklern geplant, sondern von Tausenden von Entwicklern in der Branche. Also schließen Sie sich uns an, um den Charme von Open Source zu erleben!