TL;DR
L7-Routing verteilt API-Anfragen nicht nur nach IP-Adresse oder Port, sondern nach Merkmalen der Anwendung. Pfad, Hostname, HTTP-Methode oder Header können unterschiedliche Backend-Pools ansprechen. Entscheidend sind klare Regeln, definierte Prioritäten und eine saubere Grenze zwischen Edge-Routing und anwendungsinterner Logik.
Einleitung
Ein gemeinsamer Backend-Pool für sämtliche API-Anfragen ist einfach zu konfigurieren, führt aber schnell zu unnötiger Kopplung. Versionierte APIs, administrative Endpunkte und öffentliche Ressourcen haben oft unterschiedliche Skalierungs-, Sicherheits- und Betriebsanforderungen. Werden sie pauschal an dieselben Backends weitergeleitet, muss die Anwendung diese Unterschiede selbst auswerten.
L7-Routing verlagert einen Teil dieser Entscheidung an den öffentlichen Eingang. Die Edge analysiert HTTP-Merkmale und ordnet Requests passenden Services oder Backend-Pools zu. Damit entsteht eine klare Trennung: Die Edge entscheidet über die grobe Zielrichtung des Traffics, während die Anwendung ihre fachliche Logik weiterhin selbst verantwortet.
1. L7-Routing beginnt mit einer expliziten Regelstruktur
Eine Routingregel besteht fachlich aus drei Teilen: einem Match-Kriterium, einem Ziel und einer definierten Reihenfolge. Das Match-Kriterium beschreibt, für welche Requests die Regel gilt. Typische Merkmale sind Hostname, URL-Pfad, HTTP-Methode oder ausgewählte Header. Das Ziel verweist auf einen Service beziehungsweise einen Backend-Pool, der die Anfrage verarbeiten soll.
Die Reihenfolge ist entscheidend. Eine allgemeine Regel wie /api/* darf keine spezifischere Regel für /api/v2/* überdecken. Deshalb sollten Regeln von spezifisch nach allgemein angeordnet oder durch eine eindeutig definierte Priorität bewertet werden. Eine abschließende Default-Regel verhindert, dass nicht gematchte Requests unkontrolliert an ein beliebiges Backend gelangen.
Für die ayedo Edge Cloud bedeutet L7-Loadbalancing, dass HTTP- und HTTPS-Traffic anhand solcher Anwendungsmerkmale auf unterschiedliche Ziele verteilt werden kann. Die konkrete Regelstruktur sollte dabei als Teil der Architektur dokumentiert werden, nicht nur als Konfiguration einzelner Teams.
2. Backend-Pools bilden technische Verantwortungsgrenzen
Ein Backend-Pool ist mehr als eine Liste von Servern. Er beschreibt eine Gruppe von Backends, die denselben API-Traffic fachlich und betrieblich verarbeiten soll. Ein Pool für /api/v1 kann beispielsweise von einem anderen Deployment bedient werden als ein Pool für /api/v2. Ebenso können öffentliche und administrative Endpunkte getrennt werden.
Diese Trennung wirkt sich auf Skalierung, Release-Prozesse und Fehlerbilder aus. Wird ein Pool für eine neue API-Version unabhängig skaliert, beeinflusst das nicht automatisch die Last der alten Version. Ein fehlerhaftes Deployment bleibt auf den zugeordneten Traffic begrenzt, sofern die Routingregeln keine gemeinsame Abhängigkeit erzeugen.
Health Checks und Failover ergänzen diese Struktur. Sie prüfen, ob Backends grundsätzlich erreichbar und dienstfähig sind. Sie ersetzen jedoch keine fachliche Fehlerbehandlung: Ein Backend kann HTTP 200 liefern und trotzdem falsche Daten zurückgeben. Die Edge entscheidet über Verfügbarkeit und Weiterleitung, nicht über die Korrektheit der API-Antwort.
3. API-Routing muss mit Versionierung und Releases zusammenpassen
L7-Routing eignet sich besonders für kontrollierte Übergänge zwischen API-Versionen oder Deployments. Ein Pfad wie /v1/ kann dauerhaft auf einen stabilen Pool zeigen, während /v2/ an eine neue Implementierung weitergeleitet wird. Alternativ können Header oder Hostnamen genutzt werden, wenn Versionen oder Mandanten nicht im Pfad sichtbar sein sollen.
Wichtig ist, die Routingentscheidung nicht mit vollständiger Anwendungslogik zu verwechseln. Die Edge kann Requests anhand sichtbarer Protokollmerkmale einordnen. Sie sollte jedoch nicht die fachliche Autorisierung, komplexe Mandantenlogik oder die Konsistenz von Geschäftsprozessen übernehmen. Diese Aufgaben bleiben im API-Service.
Auch bei Canary-Releases braucht es klare Grenzen. Eine Aufteilung nach einem stabilen technischen Merkmal ist nachvollziehbarer als eine Vielzahl schwer prüfbarer Sonderregeln. Werden beispielsweise nur bestimmte Header für Testzugriffe verwendet, müssen Clients, Monitoring und Rollback-Prozess diese Konvention unterstützen. Sonst wird die Edge-Konfiguration selbst zum versteckten Release-System.
4. Die Übergabe an das Backend definiert die Betriebsgrenze
Zwischen Edge und Anwendung müssen Header, TLS und Quellinformationen eindeutig behandelt werden. Bei TLS-Termination an der Edge muss das Backend erkennen können, dass der ursprüngliche Request über HTTPS eingegangen ist. Für Logging, Zugriffskontrolle und Diagnose ist außerdem relevant, welche Client- und Proxy-Informationen an die Anwendung weitergegeben werden.
Proxy Protocol kann hierfür in passenden Architekturen die Verbindung zwischen Edge und Backend um Informationen zur ursprünglichen Verbindung ergänzen. Das Backend muss dieses Protokoll allerdings explizit erwarten. Eine inkonsistente Konfiguration führt nicht zu einem bloßen Routingfehler, sondern kann den Verbindungsaufbau zwischen Edge und Service verhindern.
Backend Cloaking verschiebt die öffentliche Sichtbarkeit vollständig zur Edge: Clients müssen die internen Backend-Adressen nicht kennen. Das reduziert die direkte Angriffsfläche und verhindert, dass sich API-Clients an einzelne Workload-Adressen koppeln. In der ayedo Edge Cloud liegt damit der öffentliche Zugang vor den eigentlichen Backends; die Anwendung bleibt für die fachliche Verarbeitung zuständig.
Praxis: Zwei API-Versionen mit getrennten Pools
Ein Unternehmen betreibt /api/v1 und /api/v2 parallel. Beide Versionen sind unter demselben Hostnamen erreichbar, unterscheiden sich aber in Datenmodell und Skalierungsbedarf. Eine allgemeine Weiterleitung auf einen gemeinsamen Pool würde die Versionserkennung in die Anwendung verlagern und erschwert Rollbacks.
Stattdessen wird eine spezifische Regel für /api/v2/* vor einer allgemeineren Regel für /api/v1/* ausgewertet. Beide Regeln verweisen auf getrennte Backend-Pools. Health Checks entfernen nicht erreichbare Backends aus dem jeweiligen Pool. Ein Rollback von Version 2 verändert dann nur die Zuordnung dieses Pfads, während Version 1 unverändert bleibt. Die Edge steuert die Zielrichtung; Authentifizierung und fachliche Validierung verbleiben in den APIs.
FAQ
Welche Merkmale eignen sich für L7-Routing?
Typische Kriterien sind Hostname, URL-Pfad, HTTP-Methode und ausgewählte Header. Entscheidend ist, dass das Merkmal stabil, für Clients nachvollziehbar und für Betrieb sowie Monitoring sichtbar ist.
Ersetzt L7-Routing einen API-Gateway-Service?
Nein. L7-Routing verteilt Requests. Funktionen wie fachliche Autorisierung, Transformationen oder komplexe Quotenlogik gehören weiterhin in dafür vorgesehene API- oder Plattformkomponenten.
Wann reicht ein gemeinsamer Backend-Pool aus?
Ein gemeinsamer Pool kann genügen, wenn API-Versionen, Skalierungsprofile und Releasezyklen identisch sind. Sobald sich diese Eigenschaften unterscheiden, schafft eine getrennte Zuordnung meist klarere Betriebsgrenzen.
Fazit
L7-Routing für APIs ist vor allem eine Frage sauberer Verantwortungsgrenzen. Regeln bestimmen die Zielrichtung, Backend-Pools bündeln vergleichbare Betriebsanforderungen und die Übergabe definiert, welche Informationen ein Service erhält. Die ayedo Edge Cloud kann diese Entscheidungen als öffentlicher Eingang für HTTP- und HTTPS-Services zentral umsetzen – unabhängig davon, ob die Backends in ayedo Managed Kubernetes, einem eigenen Cluster oder bei einem anderen Provider betrieben werden.