Loading content
Envoy ist ein quelloffener Edge- und Service-Proxy für Cloud-native Anwendungen. Er bietet fortgeschrittenes L3–L7-Traffic-Management, Observability und Erweiterbarkeit über Filter und unterstützt dynamische Service-Discovery, TLS sowie HTTP/2 und gRPC. Envoy wird häufig als Sidecar, Gateway oder Load Balancer eingesetzt, um Routing, Resilienz und Telemetrie…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und verwandte Bausteine zu öffnen.
Technischer Baustein: kann automatisiert, integriert oder betrieben werden.
Konkretes Rädchen im System, das in größeren Zusammenhängen wirkt.
Envoy ist ein quelloffener Edge- und Service-Proxy für cloud-native Anwendungen. Er steuert L3–L7-Traffic, macht Kommunikation beobachtbar und lässt sich über Filter für Routing, Sicherheit und Resilienz erweitern.
Envoy entstand bei Lyft, um den Übergang von einer monolithischen Architektur zu verteilten Diensten zu unterstützen und Netzwerkverkehr für Anwendungen transparenter zu machen. Lyft stellte das Projekt 2017 der Cloud Native Computing Foundation zur Verfügung. Daraus wurde ein offener Proxy, der sich als Baustein für Service-Mesh-, Gateway- und Edge-Setups etabliert.
Stell dir Envoy als programmierbares Verkehrstor vor. Ein Request trifft auf einen Listener, wird per Routingregel einem Upstream zugeordnet und läuft durch eine Filterkette, die prüfen, anreichern, begrenzen oder messen kann. Dynamische Service-Discovery liefert Ziele zur Laufzeit; dieselbe Instanz kann als Sidecar, Gateway oder Load Balancer arbeiten.
Eine Infrastrukturschicht steuert die Kommunikation zwischen Microservices.
Eine Folge von Filtern kann Requests prüfen, anreichern, begrenzen oder messen.
Ziele und Upstreams lassen sich zur Laufzeit ermitteln und in die Weiterleitung übernehmen.
Metriken, Logs und Traces machen Verhalten, Latenzen und Fehler sichtbar.
Envoy kann nah am Workload, am Rand oder vor einer Dienstgruppe eingesetzt werden.
Envoy ist nützlich, wenn Verkehr zentral geroutet, abgesichert und beobachtbar werden soll, ohne Anwendungen stark umzubauen. Besonders stark ist er in Service-Mesh- und Gateway-Architekturen, bei TLS-Terminierung und einheitlicher Telemetrie. Der Preis sind mehr Betriebs- und Konfigurationsaufwand sowie die Abhängigkeit von sauberem Routing und gepflegten Upstream-Daten.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.