xRPC wird veröffentlicht – Erfahren Sie mehr über das APISIX-Ökosystem
API7.ai
January 21, 2021
Da Geschäftsszenarien und Anforderungen immer komplexer und vielfältiger werden, entstehen immer mehr Standards und Protokolle. Apache APISIX, als Top-Open-Source-Projekt der Apache Foundation, hat aktiv an der Förderung und Erweiterung der damit verbundenen ökologischen Aspekte teilgenommen.
In diesem Artikel werden wir Ihnen Beispiele für das kommende xRPC-Framework von Apache APISIX und mehrsprachige Plug-ins aus zwei Perspektiven vorstellen: Multi-Protokoll-Proxy und mehrsprachige Unterstützung.
Multi-Protokoll-Proxy
In Apache APISIX entspricht jede Anfrage einem Route-Objekt. Derzeit gibt es zwei Haupt-Proxy-Szenarien für Apache APISIX.
Das erste ist der HTTP-Protokoll-Proxy, der derzeit der am häufigsten verwendete Anfrage-Proxy in APISIX ist. Basierend auf dem HTTP-Protokoll-Proxy hat Apache APISIX derzeit Dutzende von Traffic-Management-Fähigkeiten implementiert, wie z.B. fein abgestimmte Flusskontrolle, Sicherheit und Beobachtbarkeit.
Das zweite ist ein dynamischer Protokoll-Proxy und Lastausgleich basierend auf TCP und UDP, der die grundlegendsten Traffic-Zulassungsfähigkeiten und Link-Level-Protokollierungsfähigkeiten bietet. Dieses Proxy-Modell kann jede TCP/UDP-Protokoll-basierte Anfrage wie MySQL, Redis, Mongo oder DNS proxyen. Da es sich jedoch um einen TCP/UDP-basierten Proxy ohne obere Anwendungsschichtprotokolle handelt, kann es nur einige grundlegende Informationen über das Quaternion erhalten, daher ist es in Bezug auf die Erweiterbarkeit etwas schwächer.
Warum xRPC
Aufgrund der Einschränkungen von Stream Route in Bezug auf Protokoll-Proxys und unserem Wunsch, mehr Anwendungsschichtprotokolle auf APISIX zu unterstützen, um mehr Benutzer und Anwendungsszenarien zu bedienen, wurde das xRPC-Framework geboren.
Das xRPC-Framework macht es sehr einfach, Protokollfähigkeiten zu erweitern, sowohl spezifische als auch private Datenprotokolle, mit präziser Granularität und höherer 7-Ebenen-Kontrolle ähnlich wie HTTP-Protokoll-Proxys, wie z.B. Anfrage-Level-Beobachtbarkeit, erweiterte Zugriffskontrolle und Proxy-Richtlinien.
Was ist xRPC
xRPC bedeutet wörtlich, dass X eine abstrakte Darstellung einer Protokollressource ist. Und RPC ist das, was wir als Prozessverteilung aller Ressourcen betrachten, die durch das Gateway gehen, d.h. es ist ein Protokollerweiterungsframework. In Bezug auf die Positionierung ist xRPC also ein Basis-Framework und keine Implementierung eines spezifischen Protokolls.
Wie Sie aus der obigen Architektur sehen können, ist xRPC ein Framework, das auf APISIX Core-Erweiterungen basiert. Auf diesem Framework können Benutzer verschiedene Anwendungsschichtprotokolle implementieren, wie z.B. Redis, MySQL, Mongo und Postgres. Auf den verschiedenen Protokollen können Sie einige gemeinsame Faktoren abstrahieren und verwandte Plug-in-Fähigkeiten implementieren, so dass verschiedene Protokolle diese Fähigkeiten teilen können.
Die Hauptrolle von xRPC kann also wie folgt zusammengefasst werden: Bereitstellung des Zugriffs auf standardisierte Anwendungsschichtprotokolle, Unterstützung der protokollübergreifenden Fähigkeitsfreigabe und Ermöglichung der Erweiterung benutzerdefinierter Protokolle.
Beispielanwendungsszenarien
Mit dem xRPC-Protokollframework, welche Szenarien kann es adressieren? Hier sind einige Beispiele.
- Beispiel 1: Redis unterstützt in früheren Versionen kein TLS. Wenn es in unserem System mehrere Versionen von Redis gibt und wir aus bestimmten Gründen Redis in der Produktion nicht aktualisieren können, aber TLS-Fähigkeit hinzufügen müssen. In diesem Fall können wir das xPRC-basierte Redis-Protokoll verwenden, um die obige Situation zu lösen.
- Beispiel 2: Wenn wir die Häufigkeit bestimmter IPs oder Aufrufer begrenzen und die Häufigkeit jeder Aufrufquelle visualisieren möchten, was Redis nicht unterstützt. Dies wird perfekt durch das Redis-Protokoll gelöst, das von xRPC erweitert wird.
- Beispiel 3: Wenn Sie MySQL verwenden möchten, um vorübergehend die Slow-Query-Funktion zu aktivieren, müssen Sie nur auf das MySQL-Protokoll zugreifen und die entsprechende Richtlinie in APISIX konfigurieren, was Sie von dem mühsamen Schritt des manuellen Einloggens in die Instanzmaschine befreit.
Natürlich gibt es viele ähnliche Anwendungsszenarien, und wir hoffen, dass Sie nach der Veröffentlichung der Funktion mehr in der tatsächlichen Anwendung erleben und praktizieren können. Der Prozess des Aufrufs von xPRC ist im folgenden Diagramm dargestellt.
Sobald die Upstream-Dienste von Apache APISIX übernommen werden, können die verschiedenen Upstream-Anwendungsdienste einheitlich verwaltet werden. Funktionen wie Protokollierung, Überwachung, Sicherheit und Fehlerbehebung können alle durch einen standardisierten Satz von Richtlinien erreicht werden.
Geplante Implementierungsphasen
Das aktuelle Design des Apache APISIX xRPC-Frameworks ist zunächst in 5 Phasen unterteilt.
- Phase 1: Lesen von Daten und Protokollentschlüsselung.
- Phase 2: Zugriffsphase. Bereitstellung der Plug-in-Zugriffsfunktion, die die Anforderungsszenarien von Sicherheit, Flusskontrolle und Zugriff realisieren kann.
- Phase 3: Proxy-Datenweiterleitung und Lastausgleich. Bereitstellung der Unterstützung für benutzerdefinierte Lastausgleichsrichtlinien und -algorithmen.
- Phase 4: Senden von Daten und Protokollverschlüsselung.
- Phase 5: Protokollierungsphase. Bereitstellung der Plug-in-Zugriffsfunktion, um die Anforderungsszenarien der Protokollierung und Protokollierung zu realisieren.
Mehrsprachige Ökologie
Um der immer reicher und größer werdenden Basis von Computersprachen gerecht zu werden, ist die Schaffung von Code-Unterstützung für eine mehrsprachige Umgebung die erste Schwelle, um der zukünftigen Technologieentwicklung gerecht zu werden. Apache APISIX hat auch auf dem Weg der mehrsprachigen Entwicklung viel Erkundung und Praxis betrieben.
Zum Beispiel hat es kürzlich die Unterstützung für WebAssembly implementiert. Einzelheiten und Funktionen finden Sie im Artikel "Apache APISIX umarmt die WASM-Ökologie". Natürlich ist die Unterstützung für WASM in Apache APISIX noch experimentell, und wir werden die Unterstützung für WASM in Zukunft weiter verbessern. Wenn Sie an diesem Projekt interessiert sind, können Sie gerne zum wasm-nginx-module-Projekt beitragen.
In der Zwischenzeit unterstützt Apache APISIX bereits mehrere Entwicklungssprachen durch den "xPluginRunner Multilanguage Plugin Runtime", bevor die WASM-Unterstützung implementiert wurde. Das heißt, bei der Entwicklung von APISIX-Plug-ins können Benutzer APISIX-Plug-ins nicht nur mit Lua-Code, der nativ von APISIX unterstützt wird, sondern auch mit ihren eigenen vertrauten Sprachen wie Go, Java und Python schreiben und erweitern.
xPluginRunner
Die Implementierung von xPluginRunner ist in der obigen Abbildung dargestellt. Der gesamte Kommunikationsprozess ist "vor" und "nach" der Ausführung der eingebauten Plug-ins, APISIX wird lokale RPC-Anfragen an die Plug-in-Laufzeit jeder Sprache initiieren. In der Plug-in-Runner wird die Berechnung und Richtlinienverarbeitung innerhalb jedes Plug-ins implementiert, und das Ergebnis wird schließlich an APISIX für die nachfolgende Entscheidungsfindung basierend auf dem Antwortergebnis zurückgegeben.
Der xPluginRunner dient als Brücke für die Kommunikation mit Apache APISIX und implementiert hauptsächlich die Analyse von privaten Datenprotokollen und die Verkapselung und Entkapselung von RPC-Nachrichten.
Derzeit befindet sich die Apache APISIX xPluginRunner-Lösung in einem relativ stabilen Stadium, und wir wissen aus dem Community-Feedback, dass einige Unternehmen begonnen haben, sie in Produktionsumgebungen zu testen. Wenn Sie an diesem Projekt interessiert sind, sind Sie auch herzlich eingeladen, an verschiedenen Entwicklungssprachen-Plug-in-Projekten teilzunehmen.
Schließlich zeigen wir Ihnen anhand eines einfachen Java-Beispiels, wie man APISIX-Plug-ins basierend auf dem Java Plugin Runner entwickelt.
Java Plugin Runner Beispiel
Zunächst müssen wir bei der Entwicklung des Plug-ins die Schnittstelle von PluginFilter implementieren. Die name-Methode in der Schnittstelle wird hauptsächlich zur Identifizierung und Extraktion des Plug-in-Namens verwendet, und die filter-Methode wird verwendet, um die Anfrage zu filtern (d.h. die Plug-in-Hauptlogik auszuführen).
Ein zusätzlicher Punkt, den Sie beachten sollten, ist, dass die Parameter request und response, die im obigen Code erscheinen, eine feste Logik im Runner haben (alle Runner gelten):
- Wenn Sie möchten, dass die Anfrage weitergeleitet wird und nur einige Richtlinieneinstellungen vorgenommen werden (wie z.B. das Umschreiben der Anfrageparameter, Header usw.), können Sie einfach das
request-Objekt manipulieren. - Wenn Sie die Anfrage beenden möchten, können Sie dies mit dem
response-Objekt tun (z.B. den Antwortkörper, die Antwortheader, Statuscodes usw. setzen).
APISIX beendet die aktuelle Anfrage, sobald es feststellt, dass das response-Objekt im Runner manipuliert wurde.
Sobald die Plug-in-Entwicklung abgeschlossen ist, ist es an der Zeit, die Anwendung in APISIX zu praktizieren.
Zuerst kompilieren Sie den Runner und die Plug-ins im Projekt in Jar-Pakete und konfigurieren den absoluten Pfad der Jar-Pakete in der Haupt-APISIX-Konfigurationsdatei auf folgende Weise.
Schließlich starten Sie Apache APISIX neu und sind bereit für die Routing- und Plug-in-Konfiguration und die Anfragevalidierungssitzungen.
Zusammenfassung
Dieser Artikel bringt Ihnen die bevorstehende Veröffentlichung des xRPC-Frameworks für Apache APISIX und verwandte Details sowie eine detaillierte Demonstration von Apache APISIX in der mehrsprachigen Entwicklungsunterstützung.
Der Artikel zeigt auch die Details der mehrsprachigen Entwicklungsunterstützung von Apache APISIX. Er zeigt die ökologieorientierten Bemühungen von Apache APISIX aus beiden Perspektiven des Multi-Protokoll-Proxys und der mehrsprachigen Unterstützung.
Fühlen Sie sich frei, eine Diskussion in GitHub Discussions zu starten oder über die Mailingliste zu kommunizieren.