Teil 1: Wie man ein Microservices-API-Gateway mit OpenResty erstellt

In diesem Artikel wollen wir zu den Kapiteln über OpenResty in Aktion übergehen. Ich werde drei Kapitel verwenden, um Ihnen zu zeigen, wie man einen Microservice-API-Gateway implementiert. In diesem Prozess werden wir nicht nur das zuvor gelernte OpenResty-Wissen einbeziehen, sondern ich werde Ihnen auch zeigen, wie man ein neues Produkt und ein Open-Source-Projekt von Grund auf aus verschiedenen Dimensionen wie Branche, Produkt und Technologieauswahl aufbaut.

Was macht ein Microservices-API-Gateway?

Schauen wir uns zunächst die Rolle des Microservice-API-Gateways an. Das folgende Bild ist eine kurze Beschreibung:

Wie wir alle wissen, ist der API-Gateway kein neues Konzept. Es existiert seit mehr als zehn Jahren. Seine Funktion besteht hauptsächlich darin, als Eingangspunkt für den Datenverkehr zu dienen und geschäftsbezogene Anfragen einheitlich zu verarbeiten. Dadurch können die Anfragen sicherer, schneller und genauer verarbeitet werden. Es hat die folgenden traditionellen Funktionen:

• Reverse-Proxy und Lastausgleich, die mit der Positionierung und den Funktionen von NGINX übereinstimmen;
• Dynamische Funktionen wie dynamisches Upstream, dynamisches SSL-Zertifikat und dynamische Drosselung und Ratenbegrenzung zur Laufzeit, die die Open-Source-Version von NGINX nicht bietet;
• Aktive und passive Gesundheitsprüfungen der Upstreams sowie Service-Unterbrechungen;
• Erweiterung des API-Gateways zu einer vollständigen API-Management-Plattform.

In den letzten Jahren wird geschäftsbezogener Datenverkehr nicht mehr nur von PC-Clients und Browsern initiiert, sondern zunehmend von Mobiltelefonen und IoT-Geräten. Mit der Verbreitung von 5G in der Zukunft wird dieser Datenverkehr zunehmen. Gleichzeitig wächst der Datenverkehr zwischen Diensten mit der Veränderung der Struktur der Microservice-Architektur explosionsartig. In diesem neuen Geschäftsszenario sind natürlich immer mehr fortgeschrittene Funktionen des API-Gateways entstanden:

1. Cloud-nativ freundlich, die Architektur sollte leichtgewichtig und einfach zu containerisieren sein.
2. Anbindung an Prometheus, Zipkin, SkyWalking und andere statistische und Überwachungskomponenten.
3. Unterstützung von gRPC-Proxy und Protokollumwandlung zwischen HTTP und gRPC, wobei die HTTP-Anfrage des Benutzers in eine interne gRPC-Anfrage umgewandelt wird.
4. Übernahme der Rolle des OpenID Relying Party, Verbindung mit den Diensten von Identitätsauthentifizierungsanbietern wie Auth0 und Okta und Behandlung der Verkehrssicherheit als oberste Priorität.
5. Realisierung von Serverless durch dynamische Ausführung von Benutzerfunktionen zur Laufzeit, wodurch die Edge-Knoten des Gateways flexibler werden.
6. Keine Benutzerbindung und Unterstützung einer hybriden Cloud-Bereitstellungsarchitektur.
7. Der Gateway-Knoten sollte zustandslos sein und sich beliebig erweitern und verkleinern lassen.

Wenn ein Microservice-API-Gateway die oben genannten Funktionen hat, kann sich der Dienst des Benutzers nur um das Geschäft selbst kümmern. Diese Funktionen, die nichts mit der Geschäftsimplementierung zu tun haben, können auf der unabhängigen Gateway-Ebene gelöst werden. Zum Beispiel Dienstentdeckung, Unterbrechung, Authentifizierung, Ratenbegrenzung, Statistiken, Leistungsanalyse usw.

Aus dieser Sicht kann der API-Gateway alle Funktionen von NGINX ersetzen und den Nord-Süd-Verkehr handhaben; er kann auch die Rolle der Istio-Kontroll-Ebene und der Envoy-Daten-Ebene übernehmen, um den Ost-West-Verkehr zu handhaben.

Warum das Rad neu erfinden?

Da die Bedeutung des Microservice-API-Gateways so groß ist, war es schon immer ein umkämpftes Gebiet, und die traditionellen IT-Giganten sind schon lange in diesem Bereich tätig. Laut dem API Lifecycle Report, den Gartner 2018 veröffentlicht hat, sind Google, CA, IBM, Red Hat und Salesforce führende Hersteller, und Apache APISIX, das Entwicklern besser bekannt ist, gehört zu den Visionären.

Die Frage ist also, warum wir ein neues Rad erfinden müssen.

Einfach ausgedrückt, liegt das daran, dass keines der derzeitigen API-Gateways für Microservices unseren Anforderungen gerecht wird. Schauen wir uns zunächst geschlossene kommerzielle Produkte an. Sie haben vollständige Funktionen, die das gesamte Lebenszyklusmanagement von API-Design, mehrsprachigen SDKs, Dokumentation, Tests und Veröffentlichungen abdecken, und bieten SaaS-Dienste an. Einige sind in die Public Cloud integriert, was sehr bequem zu verwenden ist. Aber gleichzeitig bringen sie auch zwei Schmerzpunkte mit sich.

Der erste Schmerzpunkt ist das Problem der Plattformbindung. Der API-Gateway ist der Eingangspunkt für geschäftlichen Datenverkehr. Im Gegensatz zu nicht geschäftlichem Datenverkehr, der von CDNs wie Bildern und Videos beschleunigt wird und beliebig migriert werden kann, bindet der API-Gateway viel geschäftsbezogene Logik. Sobald Sie eine geschlossene Lösung verwenden, ist es schwierig, nahtlos und kostengünstig zu anderen Plattformen zu migrieren.

Der zweite Schmerzpunkt ist das Problem, dass es nicht weiterentwickelt werden kann. In der Regel haben mittelständische und große Unternehmen ihre eigenen spezifischen Anforderungen und benötigen eine angepasste Entwicklung, aber zu diesem Zeitpunkt können Sie sich nur auf den Hersteller verlassen und keine Weiterentwicklung durchführen.

Das ist ein Grund, warum Open-Source-API-Gateway-Lösungen populär geworden sind. Allerdings sind die bestehenden Open-Source-Produkte nicht allmächtig und haben auch viele Mängel:

1. Abhängigkeit von relationalen Datenbanken wie PostgreSQL und MySQL. Auf diese Weise kann der Gateway-Knoten nur die Datenbank abfragen, wenn sich die Konfiguration ändert. Dies führt nicht nur dazu, dass die Konfiguration langsam wirksam wird, sondern erhöht auch die Komplexität des Codes, was das Verständnis erschwert. Gleichzeitig wird die Datenbank auch zu einem Single Point of Failure und einem Leistungsengpass des Systems, was die allgemeine Hochverfügbarkeit nicht garantieren kann. Wenn Sie den API-Gateway in der Kubernetes-Umgebung verwenden, wird die relationale Datenbank noch umständlicher, was eine schnelle Skalierung erschwert.
2. Plugins können nicht heiß geladen werden. Wenn Sie ein neues Plugin hinzufügen oder den Code eines bestehenden Plugins ändern, müssen Sie den Dienst neu laden, damit es wirksam wird. Dies ist dasselbe wie die Notwendigkeit, nach der Änderung der NGINX-Konfiguration neu zu laden, was Benutzeranfragen beeinträchtigt.
3. Die Codestruktur ist komplex und schwer zu erfassen. Einige Open-Source-Projekte haben mehrschichtige objektorientierte Kapselungen vorgenommen, und einige einfache Logiken sind verschwommen geworden. Aber für das Szenario des API-Gateways ist der direkte Ausdruck klarer und effizienter und fördert auch die Weiterentwicklung.

Daher benötigen wir einen leichteren, cloud-nativen und entwicklerfreundlichen API-Gateway. Natürlich können wir kein Auto hinter verschlossenen Türen bauen. Wir müssen die Eigenschaften der bestehenden API-Gateways tiefgehend verstehen. Zu diesem Zeitpunkt ist das Panorama der Cloud Native Software Foundation (CNCF) eine gute Referenz:

API-Gateway-Kernkomponenten und Konzepte

Natürlich müssen wir vor der Implementierung die Kernkomponenten des API-Gateways verstehen. Gemäß den Funktionen des API-Gateways, die wir zuvor erwähnt haben, benötigt es mindestens die folgenden Komponenten, um zu funktionieren.

Die erste ist Route. Sie passt die Anfrage des Clients durch die Definition einiger Regeln an, lädt und führt dann das entsprechende Plugin gemäß dem Anpassungsergebnis aus und leitet die Anfrage an das angegebene Upstream weiter. Diese Routing-Anpassungsregeln können aus host, uri, header usw. bestehen. Die bekannte location in NGINX ist eine Implementierung des Routings.

Die zweite ist das Plugin, die Seele des API-Gateways. Funktionen wie Authentifizierung, Verkehrs- und Ratenbegrenzung, IP-Beschränkung, Prometheus, Zipkin usw. werden alle durch Plugins implementiert. Da es sich um ein Plugin handelt, muss es plug-and-play sein; außerdem können Plugins nicht miteinander interagieren. Genau wie beim Bau von Lego-Steinen müssen wir einheitliche Regeln und vereinbarte Entwicklungschnittstellen verwenden, um mit der unteren Ebene zu interagieren.

Als nächstes kommt das schema. Da es sich um ein Gateway zur Verarbeitung von APIs handelt, ist es notwendig, das Format der API zu überprüfen, wie Datentypen, erlaubte Feldinhalte, Felder, die hochgeladen werden müssen usw. Zu diesem Zeitpunkt ist eine Ebene von schema erforderlich, um eine einheitliche und unabhängige Definition und Überprüfung durchzuführen.

Schließlich ist da die Speicherung. Sie wird verwendet, um verschiedene Benutzerkonfigurationen zu speichern und ist dafür verantwortlich, sie bei einer Änderung an alle Gateway-Knoten zu pushen. Dies ist eine sehr kritische Basiskomponente auf der unteren Ebene. Ihre Auswahl bestimmt, wie die oberen Plugins geschrieben werden, ob das System Hochverfügbarkeit und Skalierbarkeit aufrechterhalten kann usw., daher müssen wir eine sorgfältige Entscheidung treffen.

Darüber hinaus müssen wir auf diesen Kernkomponenten auch mehrere gemeinsame Konzepte von API-Gateways abstrahieren, die unter verschiedenen API-Gateways üblich sind.

Route

Lassen Sie uns zunächst über Route sprechen. Eine Route besteht aus drei Teilen: Anpassungsbedingungen, gebundene Plugins und Upstream, wie in der folgenden Abbildung dargestellt:

Wir können alle Konfigurationen direkt in Route vornehmen, was am einfachsten ist. Aber im Fall von vielen APIs und Upstreams wird dies zu vielen doppelten Konfigurationen führen. Zu diesem Zeitpunkt benötigen wir die beiden Konzepte von Service und Upstream, um eine Ebene der Abstraktion vorzunehmen.

Service

Schauen wir uns als nächstes Service an. Es ist eine Abstraktion einer bestimmten Art von API und kann auch als eine Abstraktion einer Gruppe von Routes verstanden werden. Es hat normalerweise eine 1:1-Entsprechung mit Upstream-Diensten, und die Beziehung zwischen Routes und Services ist normalerweise N:1. Ich habe auch ein Bild verwendet, um dies darzustellen:

Durch diese Ebene der Abstraktion von Service können wir die doppelten Plugins und Upstreams trennen. Auf diese Weise müssen wir, wenn sich das Plugin und das Upstream ändern, nur den Service ändern, anstatt die Daten zu ändern, die an mehrere Routes gebunden sind.

Upstream

Schließlich sprechen wir über Upstream. Wenn wir das obige Beispiel fortsetzen, wenn die Upstreams in den beiden Routes gleich sind, aber die gebundenen Plugins unterschiedlich sind, dann können wir die Upstreams separat abstrahieren, wie in der folgenden Abbildung dargestellt:

Auf diese Weise ist Route völlig unbewusst, wenn sich der Upstream-Knoten ändert, und alles wird innerhalb von Upstream verarbeitet.

Aus dem Ableitungsprozess dieser drei Hauptkonzepte können wir auch sehen, dass diese Abstraktionen auf praktischen Anwendungsszenarien basieren und nicht auf Vorstellungen. Sie gelten für alle API-Gateways, unabhängig von spezifischen technischen Lösungen.

Zusammenfassung

In diesem Artikel haben wir die Rolle, Funktionen, Kernkomponenten und abstrakten Konzepte des Microservice-API-Gateways vorgestellt, die die Grundlage des API-Gateways bilden.

Hier ist eine Frage, über die Sie nachdenken können: "Was den traditionellen Nord-Süd-Verkehr und den Ost-West-Verkehr zwischen Microservices betrifft, glauben Sie, dass der API-Gateway beides handhaben kann?" Wenn Sie bereits einen API-Gateway verwenden, können Sie auch Ihre Gedanken zur Technologieauswahl aufschreiben. Willkommen zur Kommunikation und Diskussion, und Sie sind eingeladen, diesen Artikel mit Ihren Kollegen und Freunden zu teilen, um gemeinsam zu lernen und Fortschritte zu machen.

Nächste Schritte: Teil 2: Wie man einen Microservices-API-Gateway mit OpenResty baut Teil 3: Wie man einen Microservices-API-Gateway mit OpenResty baut