Begriff
Envoy Proxy
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Früher war der Proxy (Nginx) ein großer Türsteher am Eingang des Rechenzentrums (Edge). In der Cloud (Microservices) braucht man Türsteher überall. Vor jedem kleinen Service steht ein Proxy (Sidecar). Warum? Weil der Service sich nicht um Netzwerk-Kram kümmern soll. "Service A, rede mit Service B!" Envoy kümmert sich um: "Ist B überhaupt da? Wenn nicht, versuche ich es nochmal (Retry). Ist die Leitung verschlüsselt (MTLS)? Wie lange hat es gedauert (Metrics)?" Envoy ist der universelle Netzwerk-Adapter für die Cloud.
Merksatz: Ein hochleistungsfähiger Open-Source-Edge- und Service-Proxy, der für Cloud-Native-Anwendungen entwickelt wurde, um Netzwerkverkehr zu verwalten, zu beobachten und abzusichern.
Das Herz von Istio (Service Mesh). Du konfigurierst Envoy nicht per Datei (static), sondern per API (dynamic via xDS). Wenn ein neuer Service startet, weiß Envoy in Millisekunden Bescheid.
1. Sidecar Pattern
Envoy läuft als Prozess neben deiner App (im selben Pod). Deine App redet nur mit "localhost". Envoy fängt das ab und routet es in die Welt. Deine App muss null Ahnung von IPs, DNS oder Zertifikaten haben. "The Network is abstracted away."
2. Observability
Envoy spuckt unfassbar viele Daten aus. "Wie viele 500er Fehler pro Sekunde? Latenz p99? Bandbreite?" Das macht es zur besten Quelle für Monitoring in Microservices.
1. Threading Model und Zero-Copy Abstraction
Warum ist Envoy gigantisch viel effizienter als klassische Java/NodeJS Gateways? Es reißt den Linux-Speicher voll aus. Envoy ist strikt Single-threaded pro Logical-Core (Event-Loop basierend auf libevent/epoll), um Kontext-Switches zu vermeiden. Das Meisterstück ist Envys Puffer-Design (Zero-Copy). Ein HTTP-Paket, das reinkommt, wird in den Worker-Memory gelesen. Die Header-Parser werten das Routing aus, aber der riesige JSON-Body (Payload) wird nicht kopiert, nicht bewegt und nicht in der API umhergereicht. Die Pointer verweisen durch alle Filter-Chains konstant auf das gleiche Byte-Array, bis es ins Zielsocket gepusht wird. Das senkt Host-Latency dramatisch bei High-Throughput-Clustern.
2. xDS (Discovery Services) Protokolle
Das Herzstück, weshalb Istio Envoy überhaupt lenken kann. Envoy zieht sich Config über gRPC Streams, asynchron. Die Suite (EDS - Endpoint, CDS - Cluster, RDS - Route, LDS - Listener) schiebt Updates "Eventuell Konsistent" rein. Fällt in Kubernetes ein Pod um, funkt der K8s-Apiserver das an Istiod. Istiod rechnet xDS Diff aus und feuert ein Delta-Update an Envoy. Envoy manipuliert den Memory-State des Load-Balancers nahtlos, ohne aktive TCP-Verbindungen zu crashen (Hot-Restart), und routet Request X sofort am toten Pod vorbei.
3. Wasm Filter Extensibility
Braucht ein Unternehmen eine bizarre Authentifizierung (z. B. einen exotischen Legacy-Token-Checker am Firmennetz-Eingang), musste es früher Nginx in C umschreiben (Risiko für Segfaults).
Envoy bietet eine WebAssembly (Wasm) Sandbox.
Man baut einen HTTP-Filter in Rust, Go oder AssemblyScript, kompiliert auf .wasm und injiziert das Modul live in den Proxy. Beim Eintreffen eines HTTP-Requests feuert Envoy ins Wasm, die eigene Rust-Logik stoppt den Stream oder mutiert Header, und gibt an den Envoy-Core zurück. Memory-Leaks oder C-Crashes im Filter fetzen dank dem Wasm-V8-Ring nicht das Haupt Gateway down.
Quick-Check
Warum nicht Nginx?
Nginx ist super, aber älter ("Config Reload" bei Änderungen ist teuer). Envoy wurde von Lyft (dem Uber-Konkurrenten) gebaut, um dynamisch zu ein. Keine Reloads, alles per API.Ist es langsam?
Nein. Geschrieben in C++. Fügt < 1ms Latenz hinzu.Muss ich C++ können?
Nein. Du konfigurierst es meistens über YAML oder über eine Control Plane (wie Istio), die das für dich macht.