Envoy 是雲原生時代的明星，其本質是反向代理負載均衡類軟體，領域上歸於應用交付， Envoy 又引發了哪些關於傳統應用交付領域的思考？
首先我們看一下 Envoy 官方是如何介紹 Envoy 的：
ENVOY IS AN OPEN SOURCE EDGE AND SERVICE PROXY, DESIGNED FOR CLOUD-NATIVE APPLICATIONS Envoy 是一個開源的邊緣以及服務代理，為雲原生應用而生。
從網站首頁的這一段描述可以清晰的看出官方對 Envoy 的定義，簡單來說就是雲原生時代下東西南北流量的代理。Lfyt 公司是微服務應用架構的先導者，在大量的微服務類文章中我們都可以看到 Lfyt 的身影，在從單體應用大規模轉向微服務架構後，一個嚴重的問題橫更在開發與架構人員面前，一方面 Lyft 的服務採用了多種語言開發，而採用類庫來解決分散式架構下的各種問題需要進行大量的語言適配以及對代碼的侵入，另一方面 Lyft 的業務都是部署在 AWS 上的，大量依賴 AWS 的 ELB 以及 EC2，但是 ELB 以及 AWS 在當時所提供的服務間流量管控、洞察與問題排除都不能滿足 Lyft 的需求，正是基於這樣的背景，Lfyt 於 2015 年 5 月開始了 Envoy 的開發，最早是作為一個邊緣代理進行部署並開始替代 ELB，隨後開始作為 sidecar 方式進行大規模部署。2016 年 9 月 14 日，Lyft 在其 Blog上正式對外宣佈了這一項目：Envoy C++ L7 代理與通信匯流排。一時間 Envoy 得到了大量的關注，Google 等公司開始貢獻到這個項目裡，並在一年後的 2017 年 9 月將專案捐獻給 CNCF。有了 Lyft 這樣一個好媽，又過繼給了 CNCF 這樣一個富爸，再加上同父異母的 Istio 明星兄弟的加持，可以說 Envoy 一時風光無兩，賺足了眼球與開發者的支援，僅一年多點時間便從 CNCF 畢業了。
容器技術助推了企業實踐 DevOps 與進行微服務改造，Kubernetes 容器編排平臺則讓企業能夠更加自信的將更多業務從傳統架構遷移到基於容器的現代基礎架構之上，Kubernetes 解決了容器編排、應用發佈等問題，但是當服務之間的通訊從以前的記憶體之間調用變成了基於 TCP 的網路通信後，網路對應用服務的影響變得更加巨大與不確定，基於傳統的應用架構的維運手段無法適應與解決巨大且複雜的服務間通信洞察、排錯，為了解決這樣的問題，sevice mesh 應用而生，並迅速成為關注的熱。Istio 項目則是此生態中最重要的玩家，Istio 的架構是一個典型的管理平面與資料分離的架構，在資料平面的選擇上是開放的，但是 Istio 預設選擇了 Envoy 作為資料平面。兩大人氣明星強強聯手，讓幾乎同一時期的 linkerd 變得黯然失色。而在這個時間點，NGINX 同樣也曾短暫的進行了 Nginmesh 項目，試圖讓 NGINX 作為 Istio 的資料平面，但最終在 2018 年底放棄了，為什麼會放棄，這個本文後面會提到。
當前除了 Istio 選擇 Envoy 作為資料平面外，以 Envoy 為基礎的專案還有很多，例如 k8s 的多個 Ingress Controller 項目：Gloo, Contour, Ambassador。Istio 自身的 Ingress gateway 與 Egress gateway 同樣選擇的是 Envoy。