Was ist ein API-Gateway und warum ist es unerlässlich?

Einführung in APIs

Was ist eine API (Application Programming Interface)? Eine API ist eine standardisierte Methode zum Austausch von Daten zwischen verschiedenen Anwendungen und Systemen. Viele Entwicklungsteams verfolgen den API-first-Ansatz, bei dem die Iteration auf der API konzentriert ist, von der Gestaltung, Implementierung, Tests, Sicherung, Bereitstellung, Fehlerbehebung und Analyse von APIs, was den vollständigen Lebenszyklus des API-Managements (APIM) darstellt.

Vor der Einführung von APIs gab es keine standardisierte Methode zum Datenaustausch. Computerprogramme kommunizierten über verschiedene Protokolle wie FTP, FTPS, SFTP, HTTPS usw. miteinander. Das Fehlen von Standards führte zu hohen Entwicklungskosten und versteckten Sicherheitsrisiken in vielen Bereichen: Berechtigungskontrolle, Datenmanagement, Ratenbegrenzung, Überwachung usw. Dies ist der "Turm von Babel" in der Computerwelt. Um ein ausreichend komplexes Produkt zu erstellen, müssen wir die Probleme lösen, die durch Systeme entstehen, die in verschiedenen Sprachen und mit unterschiedlichen Datenspeicherungsschemata entwickelt wurden.

Die Einführung von APIs hat das "Turm-von-Babel"-Problem erfolgreich gelöst. Entwickler müssen sich nur auf die APIs konzentrieren, die von anderen Systemen bereitgestellt werden, und müssen die zugrunde liegenden Implementierungsdetails nicht verstehen.

Die Verbindung und Datenübertragung zwischen Client-Geräten und Servern für mobile Apps, Online-Spiele, Live-Video-Streaming, Remote-Konferenzen und IoT-Geräte sind alle untrennbar mit APIs verbunden. APIs spielen eine wichtige Rolle in ihrer Kommunikation.

Warum ein API-Gateway verwenden?

Das API-Gateway ist eine wesentliche Komponente im vollständigen Lebenszyklus des API-Managements. Es ist für die API-Konfiguration, Veröffentlichung, Versionsrücknahme, Sicherheit und Lastverteilung in der Produktionsumgebung verantwortlich. Darüber hinaus ist das API-Gateway der Eingangspunkt für den gesamten Client-Datenverkehr, der die API-Anfragen des Clients an den richtigen Upstream-Service weiterleitet, um sie zu verarbeiten, und dann die zurückgegebenen Daten an den ursprünglichen Anfragenden zurückgibt, während die Sicherheit, Zuverlässigkeit und niedrige Latenz des gesamten Prozesses gewährleistet wird.

Wenn es am Anfang nicht viele APIs gibt, ist das API-Gateway normalerweise eine virtuelle Komponente, die vom Webserver und den Upstream-Services gebildet wird. Einfache Funktionen wie Routing, Weiterleitung, Reverse-Proxy und Lastverteilung werden von Apache, NGINX und einigen anderen Komponenten übernommen; andere Funktionen wie Authentifizierung und Ratenbegrenzung hängen von den Upstream-Services ab.

Warum benötigen Sie ein API-Gateway?

Mit zunehmender Anzahl von APIs stellten die „faulen“ Entwickler jedoch ein ernstes Problem fest. In verschiedenen Teilen der Upstream-Services wurden dieselben Funktionen wie Authentifizierung, Ratenbegrenzung, Protokollierung und einige andere Funktionen wiederholt programmiert. Dies ist nicht nur eine Ressourcenverschwendung, sondern auch ein Albtraum für das Code-Management. Wenn ein Teil des Codes geändert oder aktualisiert wird, muss auch der Code an anderen Stellen angepasst werden. Wie lösen wir dieses Problem? Die intelligenten Entwickler fanden schnell eine Lösung: die gemeinsamen Funktionen abstrahieren (herausnehmen) und in eine einzelne Komponente integrieren. Wir nehmen den Code, der nicht mit der Geschäftslogik zusammenhängt, aus den Upstream-Services heraus und erweitern die Komponenten Apache und NGINX. Dies ist die Entwicklung des API-Gateways der ersten Generation.

Die Entwicklungsrichtung des API-Gateways besteht darin, so viele nicht geschäftsbezogene Funktionen wie möglich zu integrieren. Um die Produktiteration zu beschleunigen, fordern Frontend- und Backend-Entwickler immer mehr von API-Gateways, nicht nur auf traditionelle Funktionen wie Routing, Weiterleitung, Reverse-Proxy und Lastverteilung beschränkt, sondern auch auf Funktionen für die Beobachtbarkeit wie gRPC und GraphQL.

Die Rolle von API-Gateways

Um das API-Gateway flexibler und effizienter zu gestalten, haben API-Gateway-Entwickler viele Innovationen in der zugrunde liegenden Struktur vorgenommen, wie z.B.:

• Funktions-Plugins. Da immer mehr Funktionen in das API-Gateway integriert werden, wie trennen wir jede Funktion, um die Entwicklung zu erleichtern? Ein Lego-ähnlicher Plugin-Mechanismus wäre die perfekte Lösung. Die meisten API-Gateways verwenden Plugins. In Apache APISIX werden sie als „Plugins“ bezeichnet. In Envoy heißen sie „Filter“. Plugins befreien Gateway-Entwickler von den Implementierungsdetails, und es werden weniger Entwicklungsressourcen benötigt, um neue Funktionen zu implementieren.
• Trennung von Datenebene und Steuerungsebene. In der ersten Generation von API-Gateways wurden Datenebene und Steuerungsebene im selben Computerprozess implementiert. Dies erleichtert die Bereitstellung und Nutzung für Benutzer, birgt jedoch erhebliche Sicherheitsrisiken. Die Datenebene bietet Dienste direkt für die Außenwelt an. Wenn Hacker von außen in die Datenebene eindringen, könnten sie Kontrollberechtigungen und Daten der Steuerungsebene (wie SSL-Zertifikate) erlangen, was potenziell verheerende Schäden verursachen könnte. Daher stellen die meisten Open-Source-API-Gateways DP und CP getrennt bereit und verwenden relationale Datenbanken oder etcd zur Verwaltung und Synchronisierung von Konfigurationen.

Am Beispiel von Apache APISIX zeigt das folgende Architekturdiagramm die oben genannten Innovationen:

Herausforderungen durch Cloud-Native

Die bedeutendste technologische Veränderung in der IT der letzten zehn Jahre war Cloud-Native. Docker, das 2013 geboren wurde, eröffnete das Zeitalter von Cloud-Native. Seitdem wurden Bare-Metal- und virtuelle Maschinen durch Container ersetzt, und monolithische Architekturen wurden durch Microservices abgelöst. Cloud-Native ist jedoch keine einfache technologische Revolution. Die treibende Kraft dahinter ist die rasante Entwicklung und der harte Wettbewerb von Internetprodukten. Cloud-Native-bezogene Technologien wurden zum richtigen Zeitpunkt geboren und wurden schnell populär, wodurch viele frühere technische Architekturen und Lösungen ersetzt wurden. Insbesondere ergeben sich die Herausforderungen für API-Gateways in Cloud-Native hauptsächlich aus den folgenden beiden Aspekten:

Von Monolithisch zu Microservices

Nachdem die Microservice-Architektur bei Entwicklern an Popularität gewonnen hat, hat sie enorme technische Vorteile freigesetzt. Microservices können in ihrem eigenen Tempo aktualisiert und veröffentlicht werden, ohne sich um die Kopplung mit anderen Services kümmern zu müssen. Produktiterationen sind somit agil, mit Dutzenden oder sogar Hunderten von Veröffentlichungen pro Tag.

Die Entwicklung von Microservices bringt jedoch auch einige Nebenwirkungen mit sich, wie z.B.:

• Die Anzahl der APIs und Microservices ist von Dutzenden auf Tausende oder sogar Zehntausende gestiegen.
• Wie können wir schnell feststellen, welche API den Fehler verursacht hat?
• Wie gewährleisten wir die Sicherheit der API?
• Wie erreichen wir Service-Unterbrechung und Service-Degradation?

Das API-Gateway kann Probleme in Bezug auf Sicherheit, Beobachtbarkeit und Canary-Release nicht allein lösen. Es muss mit vielen anderen Open-Source-Projekten und SaaS-Diensten wie Prometheus, Zipkin, Skywalking, Datadog, Okta usw. zusammenarbeiten, um Unternehmen bessere Lösungen zu bieten.

Dynamik und Cluster-Management

Die erste Herausforderung kommt aus dem Ökosystem, während die zweite aus der Technologie stammt.

Dynamik

Die Popularität von Containern und Kubernetes hat Dynamik zu einem Standardmerkmal aller grundlegenden Cloud-Native-Komponenten gemacht. In der Kubernetes-Umgebung werden Container ständig erstellt und zerstört, und elastische Skalierung ist zu einer Notwendigkeit geworden, anstatt einer Option.

Stellen Sie sich ein Szenario vor: Ein E-Commerce-Unternehmen führt eine Promotion durch, und Millionen von Benutzern strömen innerhalb einer Stunde herein und verlassen die Plattform nach Ende der Promotion. In diesem Szenario müssen Unternehmen mit traditioneller Architektur eine Reihe physischer Server kaufen, um den API-Datenverkehr zu Spitzenzeiten zu bewältigen. Unternehmen mit Cloud-Native-Architektur können dagegen die elastischen Ressourcen in der Public Cloud jederzeit nutzen. Sie können die Skalierung des Netzwerks, der Rechenleistung, der Datenbanken und anderer Ressourcen automatisch basierend auf der Anzahl der API-Anfragen anpassen.

Es gibt auch technische Herausforderungen im Zusammenhang mit der elastischen Skalierung von Containern:

• Häufige Änderungen der IP-Adressen und Ports der Upstream-Services.
• Häufige Aktualisierungen der IP-Whitelist und Blacklist.
• Erkennung und Behandlung von Dienstausfällen.
• Regelmäßige Veröffentlichungen von APIs.
• Aktualität der Dienstregistrierung und -erkennung.
• Heißerneuerung und automatische Rotation von SSL-Zertifikaten.

Im Kern der Bewältigung dieser technischen Herausforderungen steht die Dynamik.

Die API-Gateways der ersten Generation, vertreten durch NGINX, haben schwache dynamische Fähigkeiten. Da NGINX von lokalen statischen Konfigurationsdateien angetrieben wird, müssen bei jeder Änderung der Konfiguration die NGINX-Dienste neu geladen werden, um wirksam zu werden, was für Unternehmen im Cloud-Native-Zeitalter inakzeptabel ist. Dies ist der erste technische Schmerzpunkt der API-Gateways der ersten Generation.

Cluster-Management

Der zweite technische Schmerzpunkt ist das Cluster-Management.

WPS, ein SaaS-Bürosoftwareunternehmen in China, das Software wie Microsoft Office 365 anbietet, betreibt Hunderte von physischen Maschinen mit Apache APISIX, fast 10.000 CPU-Kerne, die API-Anfragen von Clients verarbeiten, und verarbeitet täglich Dutzende Milliarden von APIs.

In dieser ultra-großskaligen API-Gateway-Umgebung ist es für Entwickler unmöglich, die Konfiguration jedes API-Gateways einzeln zu ändern und dann neu zu laden. Stattdessen möchten sie eine integrierte Konsole, um den gesamten Cluster zu steuern. Leider gab es bei der Geburt der ersten Generation von API-Gateways keine derart große Instanzenskala, sodass die Entwickler der ersten Generation von Gateways die Anforderungen des Cluster-Managements nicht berücksichtigten.

Die nächste Generation von API-Gateways

Die oben genannten Herausforderungen und Schmerzpunkte haben allmählich eine neue Generation von API-Gateways hervorgebracht.

Merkmale der nächsten Generation von API-Gateways

Im Gegensatz zur ersten Generation von API-Gateways ist die Open-Source-Community die treibende Kraft hinter der Entwicklung der nächsten Generation von API-Gateways im Cloud-Native-Zeitalter. Mit der Kraft der Community und zahlreichen Open-Source-Mitwirkenden haben diese API-Gateways die Möglichkeit, einen positiven Iterations- und Entwicklungszyklus zu bilden:

• Sie können die Bedürfnisse und Schmerzpunkte von Entwicklern und Benutzern viel schneller sammeln.
• Versuchen, diese Probleme in Open-Source-Projekten zu lösen.
• Open-Source-Projekte werden einfacher zu bedienen, was mehr Entwickler anzieht.

In diesem Prozess durchbricht das API-Gateway der nächsten Generation die Positionierung von Lastenausgleich und Reverse-Proxy traditioneller Gateways und übernimmt mehr Verantwortung, wie z.B. die Verbindung, Planung, Filterung, Analyse, Protokollumwandlung, Verwaltung und Integration von Datenverkehr (siehe unten).

API-Gateway unterstützt kostengünstige Sekundärentwicklung

Gleichzeitig ist es auch ein Highlight der nächsten Generation von API-Gateways, Entwicklern die Möglichkeit zu geben, kostengünstig eigene Entwicklungen durchzuführen. Die Integration ist eine der wesentlichen Funktionen des API-Gateways. Für die Downstream-Seite handelt es sich um Protokollauflösung und Protokollumwandlung, einschließlich GraphQL, gRPC, Dubbo usw.; für die Upstream-Seite integriert es Okta, Keycloak, Datadog und Prometheus für Authentifizierungs- und Beobachtbarkeitsdienste sowie die internen Zertifizierungs-, Protokollierungs-, Überwachungs- und anderen Dienste des Unternehmens.

Das API-Gateway kann nicht alle Komponenten des Integrationsprozesses abdecken. Daher ist es unvermeidlich, dass Entwickler über Plugins eigene Entwicklungen durchführen, um ihre eigenen Geschäftsanforderungen zu erfüllen.

Verschiedene API-Gateways bieten unterschiedliche Programmiersprachen und Entwicklungsmethoden für die benutzerdefinierte Entwicklung. Zum Beispiel können sowohl Apache APISIX als auch Kong Lua verwenden, um native Plugins zu schreiben, während Envoy C++ verwendet, um native Plugins zu schreiben. Gleichzeitig kann Apache APISIX auch Go, Python, Node.js, Java und Wasm verwenden, um Plugins zu entwickeln. Fast alle Entwickler verwenden eine dieser Mainstream-Programmiersprachen.

Open Source und einfache benutzerdefinierte Entwicklung sind die wichtigsten Merkmale der nächsten Generation von API-Gateways. Sie bieten Entwicklern mehr Auswahl. Gleichzeitig können Entwickler API-Gateways in einer Multi-Cloud- oder Hybrid-Cloud-Umgebung sicher verwenden, ohne sich Sorgen machen zu müssen, von Cloud-Dienstanbietern abhängig zu sein.

Beispiel: API-Gateway für Black-Friday-Datenverkehr

Lassen Sie uns als Nächstes anhand eines konkreten Beispiels erklären, was ein API-Gateway leistet.

Am Black Friday führen E-Commerce-Unternehmen viele Promotionen durch, und das Volumen der API-Anfragen ist in dieser Zeit Dutzende Male höher als üblich. Schauen wir uns zunächst an, wie die technische Architektur aussehen würde, wenn es kein API-Gateway gäbe:

Wie Sie auf dem obigen Bild sehen können, sind die Authentifizierungs- und Protokollierungsfunktionen in den Order- und Payment-Services dupliziert. Ein E-Commerce-Service besteht im Allgemeinen aus Tausenden von verschiedenen Services. Zu diesem Zeitpunkt werden viele Codes und Verfahren wiederholt.

Die folgende Abbildung zeigt das Architekturdiagramm nach der Hinzufügung des API-Gateways:

Wie Sie sehen können, haben wir die gemeinsamen Dienste auf der API-Gateway-Ebene integriert. Dadurch können sich Backend-Services nur auf ihr eigenes Geschäft konzentrieren, was mehr Möglichkeiten für die elastische Skalierung bietet.

Wenn die Promotion beginnt, strömen Millionen von API-Anfragen von Clients in das API-Gateway, und der Backend-Service muss eine schnelle elastische Skalierung durchführen. Um kritische Geschäftsprozesse vor plötzlichem Datenverkehr zu schützen, müssen wir bösartige Crawler auf dem API-Gateway identifizieren und Drosselung, Service-Degradation und Circuit Breaking implementieren.

Wir können auch einige Dienste vorübergehend abschalten, wie z.B. Produktbewertungen, Versandabfragen usw. Kernprozesse wie Lagerinformationen, Kauf und Zahlung dürfen jedoch nicht ausfallen. Daher müssen wir den Container-Service über K8s verwalten und weitere Service-Kopien erstellen, um den ordnungsgemäßen Betrieb aufrechtzuerhalten. Zu diesem Zeitpunkt muss das API-Gateway die API-Anfrage des Clients an die neu erstellte Replikat-Service weiterleiten und den fehlerhaften Service automatisch entfernen, wie in der folgenden Abbildung dargestellt:

Zusammenfassung

Zusammenfassend ist das API-Gateway keine neue Middleware. Es hat jedoch immer mehr an Bedeutung gewonnen, da sich technische Architekturen weiterentwickeln und Produkte immer schneller iterieren. Die Entstehung der nächsten Generation von Cloud-Native-API-Gateways löst die Schmerzpunkte von Unternehmensnutzern in Bezug auf Cluster-Management, Dynamik, Ökosystem, Beobachtbarkeit und Sicherheit.

Das API-Gateway kann nicht nur API-Datenverkehr, sondern auch den Datenverkehr von Kubernetes Ingress und Service Mesh verarbeiten, die Lernkurve der Entwickler weiter verkürzen und Unternehmen dabei helfen, den Datenverkehr integriert zu verwalten.

Kontaktieren Sie uns, um mehr über Apache APISIX, API7 Enterprise Edition und API7 Cloud-Produkte zu erfahren.