So implementieren Sie Plugin Orchestration in API Gateway

Video ansehen

Zuerst möchte ich mich vorstellen. Ich bin Ming Wen, Mitbegründer von API7.ai. Ich bin der VP und PMC-Mitglied des Open-Source-Projekts Apache APISIX. Außerdem bin ich Committer von Apache SkyWalking. Darüber hinaus bin ich der Gründer des Qihoo 360 Open Source Committee, Tencent Cloud TVP und ein TOC-Mitglied der TARS Foundation. Ich besitze mehr als 40 Sicherheitspatente.

Im heutigen Thema werde ich vier Teile vorstellen. Zuerst eine kurze Einführung in Apache APISIX. Was ist Apache APISIX und womit kann es uns helfen? Der zweite Teil ist die benutzerdefinierte Entwicklung im API-Gateway, und der dritte Teil ist das Plugin in Apache APISIX. Wie können wir es automatisch generieren? Der letzte Teil sind einige Gedanken zur Zukunft des API-Gateways.

Zunächst möchte ich kurz Apache APISIX vorstellen. In einem Satz: Es ist ein Cloud-natives API-Gateway. Hier ist die Repo-Adresse von Apache APISIX auf GitHub.

Apache APISIX ist ein sehr junges Projekt. Es wurde im Juni letzten Jahres Open Source und im Oktober an den Apache-Inkubator gespendet. Im Juli dieses Jahres hat es den Apache-Inkubator verlassen und ist ein Top-Level-Projekt geworden. Dies ist eine schnell wachsende Community, es dauerte nur neun Monate.

Für Entwickler, die mit Apache APISIX nicht vertraut sind, können Sie es sich einfach als eine erweiterte Version von NGINX vorstellen, die alle Funktionen von NGINX abdeckt, während Lua verwendet wird. Es bringt mehr dynamische Funktionen zu NGINX und verwandelt NGINX in ein sehr leistungsstarkes API-Gateway. Das größte Merkmal von Apache APISIX ist, dass es vollständig dynamisch ist, einschließlich Routing, SSL-Zertifikate, Plugins usw. In Apache APISIX werden alle Funktionen dynamisch über die Admin-API konfiguriert, ohne den Dienst neu starten zu müssen. In Apache APISIX werden die geschäftlichen Anforderungen der Benutzer durch die Entwicklung von Plugins mit Lua realisiert. APISIX verfügt über mehr als 40 integrierte Plugins, darunter Authentifizierung, Ratenbegrenzung, Anfragebegrenzung, Sicherheit, Protokollierung, Beobachtbarkeit usw., die im Grunde alle Funktionen abdecken, auf die Benutzer in Unternehmen stoßen können.

Schauen wir uns also an, was Apache APISIX für Sie tun kann? Es kann Layer-4- und Layer-7-Datenverkehr verarbeiten, einschließlich HTTP, HTTPS, TCP, UDP, MQTT usw.

Da Apache APISIX auf NGINX basiert, können Sie Apache APISIX natürlich anstelle von NGINX verwenden, um den Nord-Süd-Datenverkehr zu verarbeiten. Gleichzeitig kann Apache APISIX auch den Datenverkehr zwischen Microservices gut verarbeiten, sodass Sie es verwenden können, um Envoy zu ersetzen. Wir haben auch einige Benutzer, die Apache APISIX als Ingress-Controller von Kubernetes verwenden. Gleichzeitig können wir mit Hilfe des MQTT-Plugins von Apache APISIX Apache APISIX als IoT-Gateway verwenden oder das IDP-Plugin verwenden, um APISIX in ein Zero-Trust-Gateway zu verwandeln. APISIX konzentriert sich also mehr auf die Leistungsfähigkeit des Gateways selbst. Durch Plugins können Benutzer APISIX in verschiedene Gateways verwandeln, die ihr Geschäft benötigt.

Dies ist die technische Architektur von Apache APISIX. Daraus können wir sehen, dass APISIX zwei Teile hat, der linke ist die Datenebene und der rechte die Steuerungsebene.

Schauen wir uns zuerst die Datenebene an. Nachdem die Anfrage des Benutzers durch Apache APISIX verarbeitet wurde, kann sie an private APIs, öffentliche APIs oder Partner-APIs weitergeleitet werden. Innerhalb von Apache APISIX sind Plugins ähnlich wie Lego-Steine aufgebaut. Sie können ein Plugin leicht entfernen oder hinzufügen, ohne den Dienst neu starten zu müssen.

Dann schauen wir uns die Steuerungsebene an. In der Steuerungsebene schreibt der Administrator die Konfigurationen über die Admin-API in den etcd-Cluster, und die APISIX-Datenebene wird etcd überwachen, sodass die Konfigurationen innerhalb von Millisekunden alle Datenebenen erreichen. Nachdem die Knoten der Datenebene die Daten verarbeitet haben, melden sie einige Metriken und Protokolldaten an Komponenten wie SkyWalking, Prometheus usw.

Aus diesem Architekturdiagramm können wir sehen, dass APISIX nur von etcd abhängt und keine RDS wie MySQL und PostgreSQL hat. Daher ist APISIX besser für Hochverfügbarkeit ausgelegt. Gleichzeitig ist seine Architektur einfacher, was die Bereitstellung und den Betrieb erleichtert.

Dieses Bild ist das Landschaftsbild von Apache APISIX. Von links betrachtet unterstützt APISIX viele Layer-4- und Layer-7-Protokolle. Es unterstützt nicht nur Datenverkehr von Browsern und mobilen Apps, sondern auch verschiedene IoT-Geräte, die Datenverkehr an APISIX melden.

Apache APISIX unterstützt auch viele externe Service-Discovery-Zentren, einschließlich etcd Consul.

Als eine sehr wichtige Infrastruktursoftware wird das API-Gateway im Allgemeinen am Eingang des Datenverkehrs platziert. Daher muss es nicht nur alle Anfragen vom Client verarbeiten, sondern auch mit einigen Backend-Diensten wie SkyWalking, Datadog, Kafka usw. verbinden.

Am unteren Rand dieses Bildes unterstützt APISIX nicht nur das Ausführen auf Bare-Metal-Servern, sondern auch auf Servern in verschiedenen Public Clouds. Wir unterstützen auch das Ausführen auf der ARM-Plattform.

OK, Teil 1 ist eine kurze Einführung in APISIX, und dann werde ich in Teil 2 die Entwicklung von benutzerdefinierten Plugins im API-Gateway vorstellen.

Benutzerdefinierte Entwicklung ist ein sehr wichtiger Punkt, wenn wir Open-Source-Gateways verwenden, und es hat eine hohe Einstiegshürde. Das Gateway ist keine Software, die sofort einsatzbereit ist. Dies unterscheidet sich von Datenbanken und Message Queues. MQ und Datenbanken können direkt verwendet werden, nachdem wir sie installiert haben, aber das Gateway nicht. Dies liegt daran, dass das Gateway mehr oder weniger benutzerdefinierte Entwicklung erfordert.

Zum Beispiel, wenn Ihr Unternehmen einige alte Systeme oder spezielle Protokolle hat, wie einige Protokolle in der Finanz- und Sicherheitsbranche, müssen Sie auf der Gateway-Ebene einige Transkodierungen durchführen.

Andererseits bietet APISIX zwar mehr als 40 Plugins, aber es kann definitiv nicht alle Anforderungen des Unternehmens erfüllen, da jedes Unternehmen einige einzigartige Anforderungen hat. Daher müssen wir oft einige benutzerdefinierte Entwicklungen an bestehenden Plugins vornehmen, um unsere Anforderungen zu erfüllen. Dies ist tatsächlich ein großes Problem, da die Plugin-Entwicklung immer noch mehr Fähigkeiten erfordert. Für die Plugin-Entwicklung haben verschiedene Open-Source-Projekte unterschiedliche Lösungen.

Schauen wir uns zuerst Kong an. Es ist ein bekanntes API-Gateway-Projekt. Es ist 5 Jahre alt. Der Technologie-Stack von Kong ist im Grunde derselbe wie bei APISIX, und beide basieren auf NGINX und Lua. Aber die technische Architektur von Kong ist nicht dieselbe wie bei APISIX. Kong basiert auf RDS wie PostgreSQL und Cassandra. APISIX verwendet etcd, und die APISIX-Lösung ist näher an Kubernetes und Cloud Native.

Der gemeinsame Punkt von Kong und APISIX ist, dass Entwickler Lua verwenden müssen, um Plugins zu entwickeln. Lua ist keine weit verbreitete Programmiersprache, und viele Entwickler sind damit nicht vertraut, obwohl Lua selbst einfach ist. Was gibt es also für eine bessere Lösung, außer das Plugin einfacher zu machen?

Kongs Lösung besteht darin, die Entwicklung von Plugins in Go zu unterstützen. Dieser Ansatz wird mehr Go-Entwickler anziehen, um Plugins zu schreiben, um die benutzerdefinierten Anforderungen ihres eigenen Unternehmens zu erfüllen. Dies ist eine gute Idee, aber andererseits ist Kong nativ auf Nginx und Lua implementiert, und Plugins, die in Go geschrieben sind, müssen tatsächlich einen anderen Prozess aufrufen, was eine prozessübergreifende Kommunikation erfordert, was Leistungsprobleme verursacht.

Schauen wir uns das zweite an, das ebenfalls ein sehr bekanntes Open-Source-Datenebenenprojekt zur Verarbeitung von Ost-West-Datenverkehr ist, Envoy, das in C++ geschrieben ist. Daher sind Envoys Plugins natürlich auch in C++ implementiert. Es ist also nicht einfach, damit anzufangen.

Envoy unterstützt auch andere Sprachen für die Entwicklung. Zum Beispiel unterstützt Envoy Lua-Filter, und Lua-Filter haben dasselbe Problem wie Kong, nämlich dass es nur wenige Entwickler gibt, die mit Lua vertraut sind. Daher unterstützt Envoy auch WASM, was mehr Entwickler anderer Sprachen anziehen kann, um Plugins zu schreiben. Diese Lösung ist nicht perfekt, und die Stabilität und Leistung von WASM müssen noch verbessert werden.

Die Lösungen von Kong und Envoy sind dieselben: Sie hoffen, dass mehr Entwickler die Fähigkeit haben, Plugins zu entwickeln, egal ob sie Go, Lua oder WASM verwenden. Also zurück zu APISIX, wir hoffen, eine Wunderwaffe zu finden.

Wie sieht diese Wunderwaffe also aus? Wir denken, dass auf der Gateway-Ebene die folgenden zwei Probleme zuerst gelöst werden müssen, um das Problem der benutzerdefinierten Entwicklung zu lösen.

Das erste ist, dass viele Plugins, die entwickelt werden müssen, tatsächlich einfach sind. Wie können wir die mehr als 40 Open-Source-Plugins, die bereits existieren, wiederverwenden?

Das zweite ist, dass die Anforderungsseite des Gateways im Unternehmen, wie Produktmanager, Betriebs- und Sicherheitsteams, ihre eigenen Anforderungen auf dem Gateway mit so wenig Aufwand wie möglich implementieren können, am besten ohne Code schreiben zu müssen.

Wenn wir diese beiden Probleme lösen können, dann haben wir die Möglichkeit, mehr Menschen, nicht nur Entwickler, in die Lage zu versetzen, das API-Gateway zu entwickeln.

Schauen wir uns zuerst das erste Problem an, wie die Wiederverwendung bestehender Plugins gelöst werden kann. Microservices sind bereits eine sehr beliebte Technologie, also können wir dieses Konzept in API-Gateway-Plugins einführen?

Wir können jedes Plugin nur eine Funktion ausführen lassen, genau wie ein Microservice, was auch dem Design von Prozessen in Linux entspricht. Daher haben wir ein Konzept namens Micro-Plugin vorgeschlagen.

Jedes unserer Plugins führt nur eine unabhängige Funktion aus. Dann benötigen wir ein Design ähnlich der Linux-Pipe, um diese Micro-Plugins zu verbinden.

Zum Beispiel rufe ich zuerst ein URI-Block-Plugin auf. Nachdem der Aufruf abgeschlossen ist, werde ich beurteilen, ob die URI wirklich blockiert ist. Wenn sie blockiert ist, rufe ich das Kafka-Plugin auf.

Mit dieser Pipe-Methode können diese Plugins verbunden werden. Apache APISIX hat jetzt mehr als 40 Plugins. Die Permutation von mehr als 40 Plugins hat unbegrenzte Möglichkeiten, genug, um die Benutzeranforderungen zu erfüllen.

Aber das Problem ist jetzt, dass in allen Open-Source-API-Gateways die Plugins keinen Kontext teilen und nicht miteinander kooperieren können. Daher müssen wir diese Plugins miteinander verbinden. Nur so können wir das Problem der Plugin-Wiederverwendung mit Micro-Plugins lösen.

Das zweite Problem ist, nachdem wir das Micro-Plugin haben, wie können wir die Entwicklungskosten des neuen Plugins des API-Gateways so weit wie möglich auf Null reduzieren, um die Benutzeranforderungen zu erfüllen. Wir hoffen, dass für Nicht-Entwickler, also die Produktmanager und Sicherheitsteams, die keinen technischen Hintergrund haben und nicht programmieren können, ihre Anforderungen ohne Entwicklung realisieren können, weil sie unsere Anforderungen am besten verstehen.

Gleichzeitig wird dies die Einstiegshürde für die API-Gateway-Entwicklung senken, sodass immer mehr Menschen zum API-Gateway beitragen können. Wenn wir ein Slogan verwenden, dann ist es "von der Kreativität zur Kreation", wir können nicht nur unsere eigenen Ideen in Dokumente für Entwickler schreiben, sondern auch direkt ein neues Plugin erstellen.

Das klingt nach einer guten Idee, also kann es realisiert werden? Tatsächlich können wir aus dem technischen Denken herausspringen und sehen, wie andere Branchen es lösen.

Zum Beispiel sind die Prozess-Engines der Medizinbranche in einer GUI-Weise aufgebaut, weil ihre Benutzer Ärzte sind. Dann ist Lego für Kinder dasselbe. Sie können mit einer begrenzten Anzahl von Bausteinen unendlich viele mögliche Formen bauen.

Setzen wir GUI- und Lego-Ideen zusammen, dann können wir sehen, dass es tatsächlich Scratch ist, mit dem Kinder programmieren lernen, also wird die Einstiegshürde sehr niedrig sein.

Basierend auf den beiden vorherigen Problemen, die wir gelöst haben, hat APISIX einzigartig ein neues Konzept vorgeschlagen: Plugin-Orchestrierung. Hier ist eine Demo der Plugin-Orchestrierung, wir können uns zuerst dieses kurze Video ansehen.

In diesem Video erstellen wir zuerst ein URI-Block-Plugin, und dann erstellen wir eine bedingte Überprüfung. Wenn der URI-Block wahr ist, fügen wir ihn dem Fault-Injection-Plugin hinzu; wenn das Ergebnis des URI-Blocks falsch ist, leiten wir es an das Kafka-Plugin weiter, um Protokolle aufzuzeichnen.

Dann konfigurieren wir jedes Plugin und die Bedingungsüberprüfung. Schließlich überprüfen wir es mit curl, um zu sehen, ob dieses neue Plugin wirklich auf dem Knoten des Gateways funktioniert. Ja, es funktioniert.

Als Nächstes werde ich Ihnen erklären, wie diese Plugin-Orchestrierung implementiert wird. Dies könnte auch ein technisches Problem sein, das alle interessiert.

Um die Plugin-Orchestrierung zu implementieren, müssen wir drei Schritte durchlaufen.

Im ersten Schritt müssen wir DAG verwenden, um dieses neue Plugin zu beschreiben. Wir können sehen, dass der Graph mit dem Pfeil auf der linken Seite tatsächlich ein DAG (gerichteter azyklischer Graph) ist, der dem Code entspricht, der im vorherigen Video beschrieben wurde. Dann ist dies eine für Menschen freundliche Beschreibungsmethode. Für den Computer müssen wir ihn in eine Beschreibungssprache einer Datenstruktur auf der rechten Seite umwandeln. Zum Beispiel bedeutet der Knoten 1, gefolgt von 2, 4, 6, dass Knoten 1 auf den zweiten, vierten und sechsten Knoten zeigt; der Wert von Knoten 3 ist nil, was bedeutet, dass es keine anderen Knoten hinter dem Knoten 3 gibt, und die anderen sind ähnlich. Auf diese Weise wandeln wir einen DAG in eine Datenstrukturbeschreibung um.

Nachdem wir diese Datenstruktur haben, wandeln wir diese Datenstruktur in einen JSON-String um und übergeben diesen JSON-String an den Server. Der JSON-String auf der rechten Seite wird aus dem Plugin umgewandelt, das wir in der Demo gesehen haben.

Nach dem ersten Schritt haben wir bereits einen String, der durch JSON beschrieben ist, aber wie wandeln wir diesen String in Code um, der von APISIX ausgeführt werden kann?

Wir wissen, dass wir in APISIX Lua-Code ausführen, also benötigen wir einen Compiler, um JSON in einen AST (abstrakten Syntaxbaum) zu parsen und schließlich Lua-Code zu generieren. In diesem Schritt haben wir jsonschema verwendet. Unten ist das Open-Source-Repository.

Nachdem der Lua-Code generiert wurde, verwenden wir die APISIX-Steuerungsebene, um den Lua-Code über die Admin-API in etcd zu schreiben, und dann erhalten die APISIX-Datenebenenknoten den Lua-Code durch die Überwachung von etcd. APISIX hat die Fähigkeit, den Lua-Code dynamisch auszuführen, genau wie das Serverless-Plugin von APISIX.

Daher ist das neue Plugin, das durch die Plugin-Orchestrierung generiert wird, von DAG bis zur tatsächlichen Ausführung auf dem Datenknoten, der gesamte Prozess vollständig dynamisch, was ein sehr wichtiges Merkmal von APISIX ist.

Wenn Sie dies sehen, haben Sie dann eine Frage, wo kann ich es ausprobieren? Machen Sie sich keine Sorgen, hier ist ein Open-Source-Projekt, und wir haben auch eine Online-Demo.

Im letzten Teil möchte ich über unsere Gedanken zur Zukunft des API-Gateways sprechen. Das API-Gateway existiert seit langem. Es gab viele Unternehmen und Open-Source-Projekte, die vor mehr als zehn Jahren API-Gateways entwickelt haben. Dann in der Cloud-Native-Zeit steht das API-Gateway vor Veränderungen in den Benutzeranforderungen, und es werden höhere Anforderungen an API-Gateways gestellt.

Ein Trend ist, dass traditionelle Nord-Süd-API-Gateways beginnen, Ost-West-Microservice-Datenverkehr zu verarbeiten. Zum Beispiel hat NGINX NGINX Control und NGINX Unit eingeführt. Kong und APISIX fungieren auch als Microservice-API-Gateways.

Gleichzeitig versucht das Ost-West-Service-Mesh-Projekt auch, das Nord-Süd-Zugriffsgateway zu übernehmen. Für Open-Source-Projekte wollen also alle den gesamten Datenverkehr verarbeiten.

Open-Source-Projekte zur Datenverarbeitung blühen auf, wir können Baidus BFE und Alibabas MOSN sehen. Sie konzentrieren sich alle auf den Datenverkehr.

Der zweite Punkt ist Low-Code. Die beste Lösung ist, dass der Produktmanager Funktionen direkt durch Plugin-Orchestrierung implementieren kann, sodass sich die Entwickler mehr auf das Gateway selbst konzentrieren können.

Auf diese Weise werden das Geschäft und der Kern des API-Gateways entkoppelt. Sie können Menschen, die keine Technologie und Plugin-Entwicklung verstehen, Plugins für Open-Source-Projekte beitragen lassen. Dies ist sehr wichtig.

Der dritte Punkt ist Echtzeit. Mit der Verbreitung von 5G und IoT und der Einführung von Kubernetes in Unternehmen werden sehr hohe Anforderungen an die Echtzeitwirkung der Konfiguration, den Prozess der Anfragen und die Echtzeitdatenanalyse gestellt. Für das Gateway, wenn es nicht in Echtzeit, mit sehr hoher Leistung und sehr geringer Latenz arbeiten kann, wird es in den nächsten drei bis fünf Jahren nicht überleben können.

Last but not least ist Open Source. Wir können sehen, dass Software Hardware frisst, und Open-Source-Software frisst Software. Am Ende sind alle Infrastruktur-Softwares Open Source.

Das Gleiche gilt für das API-Gateway. Open Source ermöglicht es Unternehmen, es zu geringeren Kosten zu verwenden, ohne sich um Vendor Lock-in sorgen zu müssen. Darüber hinaus wird die kommerzielle Chance von Open Source auch mehr für Open-Source-Entwickler bringen. Dies ist ein gutes Modell für eine Win-Win-Situation.