Ein interner Dienst muss Benutzerdaten von einem Abrechnungsdienst abrufen – und jede Millisekunde zählt. Wenn Sie diesen internen Datenverkehr über ein öffentlich zugängliches Edge-Gateway leiten, muss Ihre Anfrage das private Netzwerk verlassen, externe Firewalls passieren und verursacht unnötigen Serialisierungsaufwand. Dieser Pfad kann einem einzelnen Abhängigkeitsaufruf leicht 30 Millisekunden Latenz hinzufügen.
Die interne Kommunikation von Dienst zu Dienst erfordert einen anderen architektonischen Ansatz als das Edge-Routing. Am Edge benötigen Sie öffentliche Entwicklerportale, komplexe Ratenbegrenzungen für externe Clients und eine aufwendige OAuth2-Validierung. Intern benötigen Sie geringe Latenzzeiten, native Service-Discovery und minimalen Betriebsaufwand.
Die Wahl des richtigen API-Gateways für interne Microservices hängt davon ab, wie viel Betriebsaufwand Ihr Team bewältigen kann und wie hoch Ihr Bedarf an reiner Performance ist.
Die Herausforderung beim Routing interner Microservices: Self-Hosted vs. Managed
Plattform-Architekten stehen beim Entwurf des internen Routings vor einer grundlegenden Entscheidung: Entweder sie stellen ein selbst gehostetes Gateway in der Nähe der Dienste bereit und verwalten es selbst, oder sie verlagern die Infrastruktur auf einen verwalteten Cloud-Dienst.
Selbst gehostete Gateways laufen innerhalb Ihres privaten Netzwerks – oft als Sidecars oder Ingress-Controller in einem Kubernetes-Cluster. Dieses Bereitstellungsmodell hält den Datenverkehr lokal, was die Latenz minimiert. Es bietet Ihnen außerdem die vollständige Kontrolle über Routing-Regeln, Header-Manipulationen und Service-Discovery-Integrationen mit Tools wie Consul oder Etcd. Allerdings muss Ihr Team die zugrunde liegenden virtuellen Maschinen, Skalierungsrichtlinien und Upgrades selbst verwalten.
Verwaltete Cloud-Gateways laufen als externe Dienste. Sie erfordern fast keine Wartung und skalieren automatisch, um Datenverkehrsspitzen abzufangen. Der Kompromiss liegt bei der Latenz und den Kosten. Jede interne Anfrage muss zum Gateway-Endpunkt des Cloud-Anbieters und zurück in Ihre Virtual Private Cloud (VPC) geleitet werden. Dieser zusätzliche Network Hop führt zu Latenzen, die die Performance von verketteten Microservice-Aufrufen beeinträchtigen können.
Kong: Hohe Performance mit einem plugin-reichen Ökosystem
Kong ist ein Open-Source-Gateway, das auf dem Nginx-Webserver und der OpenResty-Webplattform aufbaut. Da es die ereignisgesteuerte Architektur von Nginx übernimmt, zeichnet sich Kong durch Routing mit hohem Durchsatz und geringer Latenz aus.
[Interne Anfrage] ---> [Kong Gateway (Nginx/OpenResty)] ---> [Ziel-Microservice]
|
[Lua-Plugins] (Auth, Ratenbegrenzung, Logging)
Kong verwendet Lua für die Erweiterbarkeit. Wenn Sie Header ändern, Authentifizierungs-Token injizieren oder Anfragen in Prometheus protokollieren müssen, wenden Sie ein Plugin an. Die Open-Source-Version, Kong Gateway OSS, enthält eine große Auswahl an Community-Plugins. Für erweiterte Enterprise-Funktionen wie die rollenbasierte Zugriffskontrolle (RBAC) und Multi-Zonen-Bereitstellung müssen Teams auf Kong Enterprise umsteigen.
Die Verwaltung von Kong erfordert die Verwaltung seines Konfigurationsstatus. Sie können Kong in einem traditionellen Datenbankmodus betreiben, der eine PostgreSQL-Datenbank zur Speicherung von Routing-Konfigurationen erfordert. Alternativ können Sie Kong im DB-losen Modus ausführen. Im DB-losen Modus schreiben Sie Konfigurationen in eine deklarative YAML-Datei und wenden diese direkt im Speicher des Gateways an. Dieser Ansatz eignet sich gut für GitOps-Workflows und Kubernetes-Umgebungen – bedeutet jedoch, dass Sie einige Plugins, die einen dynamischen Datenbankspeicher erfordern, nicht nutzen können.
Tyk: Funktionsstark und von Haus aus Go-nativ
Tyk ist ein Open-Source-API-Gateway, das vollständig in Go geschrieben ist. Im Gegensatz zu Kong, das bei Kernfunktionen auf eine modulare Plugin-Architektur setzt, enthält Tyk Ratenbegrenzung, Analysen und Service-Virtualisierung direkt in seiner Core-Engine.
Da Tyk in Go geschrieben ist, spricht es Teams mit bestehender Go-Expertise an. Entwickler können benutzerdefinierte Plugins in Go, Python, JavaScript oder Lua mithilfe des gRPC-basierten Plugin-Coprozessors von Tyk schreiben.
Tyk benötigt Redis für den Betrieb. Es verwendet Redis für die Sitzungsspeicherung, Ratenbegrenzungszähler und das Caching. Obwohl diese Datenbankabhängigkeit eine zusätzliche zu verwaltende Betriebskomponente darstellt, ermöglicht Redis es Tyk, große Mengen an Datenverkehr mit vorhersehbarer, geringer Latenz zu verarbeiten. Die Open-Source-Version von Tyk ist äußerst funktional und bietet dieselbe Gateway-Engine wie die kostenpflichtige Enterprise-Edition – die Enterprise-Stufe bietet jedoch zusätzlich eine Management-Control-Plane und ein Dashboard.
Cloud-native Optionen: AWS API Gateway und verwaltete Plattform-Dienste
Wenn Ihre Infrastruktur vollständig in einer öffentlichen Cloud läuft, sind verwaltete Optionen wie AWS API Gateway, Azure API Management oder Google Cloud Apigee sehr leicht zugänglich.
AWS API Gateway lässt sich direkt in andere AWS-Dienste integrieren. Sie können einen eingehenden API-Aufruf direkt an eine AWS-Lambda-Funktion, eine SQS-Warteschlange oder einen internen Application Load Balancer (ALB) weiterleiten, ohne benutzerdefinierten Integrationscode schreiben zu müssen. Die Sicherheit wird über AWS Identity and Access Management (IAM)-Richtlinien verwaltet, was die Zugriffskontrolle vereinfacht.
Verwaltete Cloud-Gateways bringen jedoch Performance-Kompromisse mit sich:
- Kaltstarts: Wenn Sie serverlose Backends integrieren, kann die Verarbeitung der ersten Anfrage mehrere Sekunden dauern.
- Network Hops: Der Datenverkehr muss oft Ihr privates Subnetz verlassen, um den öffentlichen Endpunkt des Gateways zu erreichen, bevor er wieder in Ihr privates Netzwerk zurückgeleitet wird.
- Vendor-Lock-in: Konfigurationen sind an die proprietären APIs und Bereitstellungstools des Cloud-Anbieters gebunden.
Für interne Microservices mit hohem Durchsatz können diese Faktoren dazu führen, dass cloud-native Optionen weniger geeignet sind als selbst gehostete Alternativen.
Entscheidungsrahmen: Auswahl nach Teamgröße und Betriebsbudget
Um das richtige Gateway auszuwählen, sollten Sie die Kapazität Ihres Teams zur Verwaltung der Infrastruktur gegen Ihre Performance-Anforderungen abwägen.
Kleine Startup-Teams (1 bis 10 Entwickler)
Wenn Sie ein kleines Team haben, sollten Sie einen geringen Betriebsaufwand priorisieren. Nutzen Sie das verwaltete Gateway Ihres Cloud-Anbieters (wie AWS API Gateway), um Ihre Dienste schnell zum Laufen zu bringen. In dieser Größenordnung überwiegen die einfache Einrichtung und das wartungsfreie Modell die geringen Latenznachteile.
Mittlere Plattform-Teams (10 bis 50 Entwickler)
Mit dem Wachstum Ihres Service Mesh steigen die Kosten für Cloud-Gateways linear mit dem Anfragevolumen. In dieser Phase wird das Self-Hosting finanziell und betrieblich sinnvoll.
Betrachten wir einen realistischen Kostenvergleich:
- Verwaltetes Szenario (Beispiel): Eine mittlere Anwendung verarbeitet 100.000.000 interne Anfragen pro Tag. Bei einem beispielhaften Cloud-Gateway-Preis von 3,50 $ pro Million Anfragen belaufen sich die Routing-Kosten allein auf 350 $ pro Tag – oder rund 10.500 $ pro Monat.
- Selbst gehostetes Szenario (Beispiel): Dasselbe Team stellt Kong oder Tyk auf seinem bestehenden Kubernetes-Cluster bereit. Sie betreiben drei kleine Compute-Instanzen für Hochverfügbarkeit, was insgesamt 150 $ pro Monat an Compute-Ressourcen kostet.
Die selbst gehostete Option spart erheblich Budget – erfordert jedoch, dass das Plattform-Team jeden Monat einige Stunden für die Verwaltung von Updates, die Überwachung von Redis oder PostgreSQL und die Konfiguration von Deployment-Pipelines aufwendet.
Enterprise-Plattform-Teams (50+ Entwickler)
Für große Organisationen mit strengen Compliance- und Sub-Millisekunden-Latenzanforderungen sind selbst gehostete Gateways fast immer erforderlich. Diese Teams stellen Kong oder Tyk in der Regel in einer hybriden oder Multi-Regionen-Konfiguration bereit, um den Datenverkehr vollständig innerhalb lokaler Rechenzentren oder VPCs zu halten.
| Auswahlkriterium | Kong | Tyk | AWS API Gateway |
|---|---|---|---|
| Hauptsprache | Lua / C | Go | Proprietär |
| Datenbank-Abhängigkeit | PostgreSQL oder DB-los | Redis | Keine (Verwaltet) |
| Erweiterbarkeit | Lua-Plugins | Go, Python, gRPC | AWS-Integrationen |
| Latenzprofil | Sub-Millisekunde | Niedrig (Mikrosekundenbereich) | Moderat (Network Hops) |
| Beste Eignung | Hochleistungs-Nginx-Umgebungen | Go-zentrierte Teams, die direkt einsatzbereite Funktionen wünschen | Serverlose und reine AWS-Architekturen |
Evaluieren Sie Ihre API-Infrastrukturoptionen auf StackMatch
Die Wahl des richtigen API-Gateways ist eine kritische architektonische Entscheidung, die sich auf die Latenz, die Kosten und die betriebliche Komplexität Ihres Systems auswirkt. Sie können weitere Optionen erkunden und diese Tools auf StackMatch eingehend vergleichen. StackMatch bietet kuratierte Tool-Listen, direkte Vergleichsseiten und redaktionelle Bewertungen basierend auf Benutzerfreundlichkeit, Preistransparenz und Integrationen, um Plattform-Engineers dabei zu helfen, die passende Lösung für ihren spezifischen Tech-Stack zu finden.
FAQs
Ist Kong für internes Routing schneller als AWS API Gateway?
Ja, Kong bietet im Allgemeinen eine deutlich geringere Latenz als AWS API Gateway. Da Kong auf Nginx läuft und innerhalb Ihrer privaten VPC in der Nähe Ihrer Microservices bereitgestellt werden kann, vermeidet es die Network Hops und Kaltstarts, die mit dem vollständig verwalteten Dienst von AWS verbunden sind.
Kann ich Tyk ohne Datenbank betreiben?
Tyk benötigt Redis für Caching, Ratenbegrenzung und Sitzungsspeicherung. Obwohl Sie es ohne Redis nicht völlig zustandslos betreiben können, ermöglicht diese Architektur Tyk, Datenverkehr mit hohem Durchsatz und minimaler Latenz im Vergleich zu Gateways zu verarbeiten, die auf relationale Datenbanken angewiesen sind.
Wann sollte ein Team von einem cloud-nativen Gateway zu einem selbst gehosteten Gateway wechseln?
Teams wechseln in der Regel, wenn die Rechnungen für cloud-native Gateways linear mit dem API-Aufrufvolumen steigen oder wenn die zusätzliche Latenz des WAN-Routings die Performance der internen Microservices beeinträchtigt. Wenn Ihre internen Dienste Antwortzeiten von unter 10 ms erfordern, ist das Self-Hosting von Kong oder Tyk auf Kubernetes meist erforderlich.
Wie gehen Kong und Tyk mit gRPC und GraphQL um?
Beide Gateways unterstützen das Routing von gRPC und GraphQL, gehen jedoch unterschiedlich damit um. Kong verwendet Plugins für gRPC-Transcodierung und GraphQL-Schema-Validierung – während Tyk direkt einsatzbereite native GraphQL-Engine-Funktionen bietet, um mehrere Schemata in einem einzigen Graphen zusammenzuführen.