Envoys Design folgt direkt aus seinem Gründungsziel: das Netzwerk für Anwendungen transparent machen und schnell erkennbar machen, ob ein Problem im Netzwerk oder in der Anwendung liegt. Dieses Ziel prägt das Vokabular – Listener, Cluster, Filter –, aus dem jede Envoy-Konfiguration besteht. Diese Anleitung behandelt, was jedes davon tut und wie eine Anfrage durch sie hindurchläuft.

Downstream und Upstream

Envoy nennt alles, was ihm eine Anfrage sendet, Downstream, und alles, wohin er diese Anfrage weiterleitet, Upstream. Downstream kann der Browser eines Endnutzers sein, ein anderer Service im Mesh, alles, was eine Verbindung zu Envoy öffnet. Upstream ist das, wohin Envoy die Anfrage routet: eine Anwendungsinstanz, ein anderer Service, eine externe API. Jedes Stück Konfiguration in Envoy liegt auf der einen oder der anderen Seite dieser Linie.

Listener: wo Verbindungen hereinkommen

Ein Listener bindet an einen Port und nimmt dort Verbindungen an. Eine einzelne Envoy-Instanz kann mehrere Listener definieren, jeweils mit eigenem Port und eigener Verarbeitungs-Pipeline. So kann eine Instanz zum Beispiel TLS auf 443 terminieren und gleichzeitig unverschlüsselten Traffic auf 8080 mit völlig anderen Regeln behandeln. Was ein Listener mit einer Verbindung tun muss, bevor sie geroutet werden kann – TLS-Terminierung, Protokollerkennung und mehr –, geschieht durch die an ihn angehängten Filter, die die nächste Anleitung dieser Reihe ausführlich behandelt.

Cluster: wohin Verbindungen gehen

Ein Cluster ist eine benannte, logische Gruppe aus einem oder mehreren Upstream-Endpunkten, an die Envoy Traffic routen kann. Wenn du von Kubernetes kommst, hilft folgender Vergleich: Ein Cluster entspricht ungefähr einem Service, und die einzelnen Endpunkte darin entsprechen ungefähr den Pods dahinter. Envoy verfolgt die Gesundheit jedes Endpunkts, wendet die für den Cluster konfigurierte Load-Balancing-Policy an und wählt für jede Anfrage ein Ziel unter den gesunden aus.

Filter und Filter-Ketten

Sobald ein Listener eine Verbindung annimmt, fließen die Daten durch eine Folge von Filtern – kleinen, fokussierten Einheiten, die jeweils eine Aufgabe erledigen und zu einer Filter-Kette zusammengesetzt sind. Die grundlegendsten Filter arbeiten auf Netzwerkebene (TCP oder UDP) auf dem rohen Byte-Strom, bevor etwas als höheres Protokoll geparst wurde. Envoy liefert Netzwerkfilter für Dinge wie die Protokollverarbeitung von MongoDB, Redis und Kafka von Haus aus mit.

Für HTTP-Traffic erledigt ein bestimmter Netzwerkfilter den Großteil der Arbeit: der HTTP Connection Manager. Er parst die rohen Bytes zu HTTP-Anfragen, Headern und Bodys und stellt eine eigene verschachtelte Kette von Filtern auf HTTP-Ebene bereit – Access Logging, Retries, Header-Manipulation und mehr –, die arbeiten, sobald der Traffic HTTP und nicht mehr nur Bytes ist. Die nächste Anleitung dieser Reihe widmet sich ganz ihm.

Routen: einen Cluster auswählen

Sobald der Traffic die HTTP-Ebene erreicht, entscheiden Routen, an welchen Cluster eine bestimmte Anfrage geht, abgeglichen anhand von Merkmalen der Anfrage selbst: Host, Pfad, Header. Eine Anfrage an example.com/api könnte auf eine Route passen, die sie an einen Cluster example-com schickt, während ein anderer Host oder Pfad auf eine ganz andere Route passt. Das Route-Matching macht aus „irgendeine HTTP-Anfrage kam an“ „hier ist der konkrete Cluster, zu dem sie gehört“.

Alles zusammen: der Weg einer Anfrage

Downstream-Client
      │
      ▼
   Listener (an einen Port gebunden)
      │
      ▼
  Filter-Kette (Netzwerkfilter, dann HTTP Connection Manager)
      │
      ▼
   Route-Matching (Host, Pfad, Header)
      │
      ▼
    Cluster (eine benannte Gruppe von Endpunkten)
      │
      ▼
  Load Balancing + Health Checking
      │
      ▼
 Upstream-Endpunkt

Eine Anfrage kommt an einem Listener an, fließt durch dessen Filter-Kette, wird von den Routing-Regeln einem Cluster zugeordnet, und Envoys Cluster Manager wählt innerhalb dieses Clusters einen gesunden Endpunkt aus, an den sie tatsächlich gesendet wird. Alles, was Envoy tut – TLS, Rate Limiting, Retries, Observability –, hängt an einer dieser Stufen, statt als eigenes Anliegen zu existieren. Das ist genau das Design „Netzwerk ist transparent, Probleme sind leicht zu lokalisieren“, das sich das Projekt vorgenommen hat: Weil jede Stufe explizit und inspizierbar ist, lässt sich eine langsame Antwort oder eine fehlgeschlagene Anfrage meist auf einen bestimmten Listener, Filter oder Cluster zurückführen, statt zu raten.

Eine deutlich ausführlichere Darstellung dessen, was auf jeder Stufe passiert – einschließlich der Teile der Architektur (Worker-Threads, Connection Pooling), die diese Anleitung bewusst vereinfacht –, findest du in Envoys eigener Dokumentation “Life of a Request”, die den vollständigen internen Ablauf Schritt für Schritt durchgeht.