Publiziert: Zuletzt aktualisiert:

API-Gateway und Service-Mesh

Verkehr von aussen und Verkehr zwischen Diensten gehören getrennt

Ein API-Gateway steuert den Nord-Süd-Verkehr, also die Anfragen, die von aussen in das System eintreten. Ein Service-Mesh steuert den Ost-West-Verkehr, also die Kommunikation der Dienste untereinander. Beide lösen verschiedene Probleme an verschiedenen Stellen und sind kein Ersatz füreinander.

Sobald eine Anwendung aus mehreren Diensten besteht, tauchen zwei verschiedene Verkehrsarten auf, die gern in einen Topf geworfen werden. Die eine führt von aussen herein: ein Client ruft das System auf. Die andere bleibt im Inneren: ein Dienst ruft einen anderen Dienst auf. Gateway und Mesh adressieren je eine dieser Richtungen. Wer sie gleichsetzt, baut entweder ein Mesh, das es nicht braucht, oder erwartet vom Gateway eine Aufgabe, die es nicht erfüllt. Diese Seite trennt die beiden Muster sauber, ordnet ihren Nutzen ein und benennt den Preis, den ein Mesh kostet.

Zwei Verkehrsrichtungen

Die Begriffe Nord-Süd und Ost-West stammen aus dem Netzwerkdiagramm, in dem der externe Verkehr oben und unten, der interne links und rechts gezeichnet wird.

  • Nord-Süd. Verkehr, der die Systemgrenze überquert: Browser, Mobile-App oder ein fremdes System rufen eine API auf. Hier geht es um Eintritt, Authentifizierung, Drosselung und das Bündeln vieler interner Schnittstellen zu einer nach aussen.
  • Ost-West. Verkehr zwischen den eigenen Diensten, der die Systemgrenze nie verlässt. Hier geht es um Wiederholungen, Zeitlimits, Verschlüsselung zwischen Diensten und die Sichtbarkeit, welcher Dienst mit welchem spricht.

Ein Gateway sitzt am Nord-Süd-Punkt, ein Mesh legt sich über die Ost-West-Ebene. Sie überschneiden sich an genau einer Stelle, dem Eintritt in das Mesh, aber sie sind nicht austauschbar.

Das API-Gateway

Ein API-Gateway ist der einzige Eintrittspunkt für externe Anfragen. Es nimmt den Aufruf entgegen, klärt die Identität und leitet ihn an den richtigen internen Dienst weiter. Statt dass jeder Dienst seine eigene Authentifizierung, Drosselung und Protokollierung mitbringt, wandern diese Querschnittsaufgaben an eine Stelle. Typische Aufgaben sind:

  • Weiterleitung. Eine externe Anfrage wird auf einen oder mehrere interne Dienste verteilt, oft auf mehrere gefächert und das Ergebnis zusammengeführt.
  • Eintrittskontrolle. Authentifizierung und Autorisierung, bevor eine Anfrage überhaupt einen internen Dienst erreicht.
  • Drosselung und Kontingente. Schutz vor Überlastung und faire Verteilung der Kapazität auf die Aufrufer.
  • Übersetzung. Ein einheitliches externes Protokoll nach aussen, während intern unterschiedliche Protokolle erlaubt bleiben.

Das Gateway ist damit die natürliche Heimat für alles, was am Rand einer API-First-Architektur passiert. Eine Variante, das Muster Backends for Frontends, stellt je Client-Typ ein eigenes Gateway bereit, damit eine Mobile-App nicht dieselbe Antwortform bekommt wie ein Webshop.

Das Service-Mesh

Ein Service-Mesh verlagert die Logik der Dienst-zu-Dienst-Kommunikation aus dem Anwendungscode in eine eigene Infrastrukturebene. In der klassischen Bauweise läuft neben jedem Dienst ein kleiner Stellvertreter, der Sidecar-Proxy, durch den der gesamte Verkehr dieses Dienstes läuft. Diese Proxies bilden die Datenebene, eine zentrale Steuerebene konfiguriert sie einheitlich. Damit lassen sich quer über alle Dienste und ohne Codeänderung einbauen:

  • Verschlüsselung zwischen Diensten. Gegenseitige TLS-Authentifizierung (mTLS), sodass auch interner Verkehr verschlüsselt und beidseitig ausgewiesen ist. Das passt zur Logik von Zero Trust, die auch dem internen Netz nicht vertraut.
  • Resilienz. Wiederholungen, Zeitlimits und das Abschotten ausfallender Dienste, damit ein Fehler nicht die ganze Aufrufkette mitreisst.
  • Verkehrslenkung. Feine Steuerung, etwa schrittweise Ausrollvarianten oder das Spiegeln von Verkehr auf eine neue Version.
  • Sichtbarkeit. Einheitliche Metriken und Ablaufverfolgung für jeden Dienst-zu-Dienst-Aufruf, die der Observability zuarbeiten, ohne dass jeder Dienst sie selbst erzeugen muss.

Diese Fähigkeiten sind kein Selbstzweck. Sie zahlen sich vor allem dann aus, wenn viele Dienste existieren und dieselben Querschnittsthemen sonst in jedem Dienst einzeln gelöst werden müssten.

Wo sie sich treffen

architecture-beta
    group clients(cloud)["Clients"]
    group edge(cloud)["Nord-Süd"]
    group mesh(server)["Service Mesh Ost-West"]
    service browser(cloud)["Browser und Mobile"] in clients
    service gateway(server)["API Gateway"] in edge
    service svcA(server)["Dienst A"] in mesh
    service svcB(server)["Dienst B"] in mesh
    service svcC(server)["Dienst C"] in mesh
    browser:R -- L:gateway
    gateway:R -- L:svcA
    svcA:R -- L:svcB
    svcA:B -- T:svcC
    svcB:R -- L:svcC

Das Diagramm zeigt die Arbeitsteilung. Der externe Aufruf trifft zuerst auf das Gateway, das ihn an einen ersten Dienst übergibt. Ab dort übernimmt das Mesh: jeder weitere Aufruf zwischen den Diensten läuft über die Proxies, die Verschlüsselung, Wiederholung und Telemetrie beisteuern. Manche Mesh-Implementierungen können den Eintritt mit einem eigenen Ingress-Gateway selbst abdecken; das ersetzt aber nicht die Verwaltungsfunktionen eines vollwertigen API-Gateways wie Kontingente oder ein Entwicklerportal.

Der Preis des Mesh

Ein Mesh ist nicht gratis, und der Aufwand wird oft unterschätzt. Die ehrliche Bilanz:

  • Laufzeit-Overhead. Im Sidecar-Modell durchläuft jeder Aufruf zwei zusätzliche Proxies, was eine kleine Latenz je Sprung und einen Ressourcenbedarf je Dienst hinzufügt. Bei vielen Diensten summiert sich das.
  • Betriebskomplexität. Steuerebene, Proxy-Konfiguration und Zertifikatsverwaltung sind eine zusätzliche Schicht, die betrieben, beobachtet und aktualisiert werden will. Sie verlangt eine gewisse Cloud-Native-Reife im Betrieb.
  • Fehlersuche. Ein zusätzlicher Stellvertreter im Pfad bedeutet eine zusätzliche Stelle, an der ein Aufruf scheitern kann.

Auf den Overhead-Punkt antworten neuere Architekturen mit einem sidecarlosen Ansatz: statt eines Proxys je Dienst wird die Datenebene auf Knotenebene gebündelt, ein Layer-7-Proxy kommt nur dort hinzu, wo seine Funktionen gebraucht werden. Das senkt den Ressourcenbedarf spürbar, verschiebt aber die Betriebskomplexität, statt sie aufzulösen.

Gateway zuerst, Mesh erst ab Skalierung

Die Trennung der beiden Muster führt zu einer klaren Reihenfolge:

  • Ein Gateway braucht fast jedes System mit externen Schnittstellen. Sobald mehr als ein Dienst nach aussen erreichbar ist, lohnt sich der einzelne Eintrittspunkt für Authentifizierung, Drosselung und Bündelung. Das gilt schon für einen Modulith mit wenigen Microservices.
  • Ein Mesh lohnt sich erst ab einer gewissen Anzahl Dienste. Bei einer Handvoll Diensten lösen ein paar Programmbibliotheken dieselben Probleme mit weniger Aufwand. Der Punkt, an dem ein Mesh den Aufwand wert ist, liegt dort, wo mTLS, einheitliche Resilienz und durchgängige Sichtbarkeit über viele Dienste sonst zur wiederholten Handarbeit in jedem Dienst werden.
  • Erst die Betriebsreife, dann das Mesh. Ein Mesh setzt funktionierende Automatisierung, Observability und Auslieferung voraus. Ein Team, das diese Grundlagen noch aufbaut, sollte ein Mesh aufschieben, statt die Komplexität zu verdoppeln.

Die Faustregel: das Gateway klärt den Eintritt, das Mesh klärt die Skalierung der internen Kommunikation. Wer beide Fragen verwechselt, baut die falsche Schicht zuerst.

Verwandte Leistungen

Welche Schicht ein Team zuerst braucht und ab wann sich ein Mesh rechnet, ist eine Frage der Plattformreife. Die Bereitstellung dieser internen Plattform samt Selbstbedienung und Golden Paths behandelt Platform Engineering (IDP); die Mess- und Telemetrie-Ebene, auf die ein Mesh einzahlt, behandelt Observability und Telemetrie.

Referenzen

Verwandte Themen

  • API-First, die Schnittstellenstrategie, an deren Rand das Gateway sitzt.
  • Microservices, die Architektur, die den Ost-West-Verkehr überhaupt erzeugt.
  • Zero Trust, die Sicherheitslogik hinter der Verschlüsselung zwischen Diensten.
  • Observability, die Transparenzebene, der ein Mesh zuarbeitet.
  • Cloud Native, die Betriebsreife, die ein Mesh voraussetzt.
  • Platform Engineering (IDP), der Plattformkontext für interne Selbstbedienung.

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.