Envoy 是云原生時代的明星，其本質是反向代理負載均衡類軟件，領域上歸于應用交付，那么作為應用交付領域的老兵如何看待 Envoy，Envoy 又引發了哪些關于傳統應用交付領域的思考？

關于作者

林靜，F5 軟件方向解決方案架構師，歷任 F5 Global Service ENE，APAC Professional Service 顧問，技術專家。擁有超過 10 多年的應用交付領域工作經驗，秉承持續學習和反饋的理念，致力于現代應用體系下的應用服務研究。CNCF Kubernetes CKA 664 號認證獲得者，中國首位 F5 Security Solution Expert 認證獲得者。

感謝邱世達對本文的審閱。

前言

Envoy，使者，使節，代表！就像其單詞含義本身一樣，帶著一種權威感，一種全代理的神圣感。結合其本身用途與角色，真是 “人如其名”，不禁為 Lyft 點贊，不知是得到了哪位大師的指點來起這個名字。在當前火熱的微服務時代下，Envoy 是個絕對的明星，用眾人皆知來形容可以說一點也不為過。曾有人問我如何看 Envoy 以及在云原生時代下是否 Enovy 將取代 F5 取代 NGINX，作為一個經歷了兩次應用交付技術領域更迭浪潮的老兵，在本文中我將來淺談一下 Envoy，以及試圖從個人角度來理解與回答一下這個問題。為什么說淺談一下，這真的不是謙虛，而是客觀上真的沒有那么深入的大規模長時間使用和研究 Envoy 的所有技術細節，因此我將結合我的從業經歷與經驗來對 Envoy 做一個淺談。

Envoy，使者，使節，代表！就像其單詞含義本身一樣，帶著一種權威感，一種全代理的神圣感。結合其本身用途與角色，真是 “人如其名”，不禁為 Lyft 點贊，不知是得到了哪位大師的指點來起這個名字。在當前火熱的微服務時代下，Envoy 是個絕對的明星，用眾人皆知來形容可以說一點也不為過。曾有人問我如何看 Envoy 以及在云原生時代下是否 Enovy 將取代 F5 取代 NGINX，作為一個經歷了兩次應用交付技術領域更迭浪潮的老兵，在本文中我將來淺談一下 Envoy，以及試圖從個人角度來理解與回答一下這個問題。為什么說淺談一下，這真的不是謙虛，而是客觀上真的沒有那么深入的大規模長時間使用和研究 Envoy 的所有技術細節，因此我將結合我的從業經歷與經驗來對 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 在其博客上正式對外宣布了這一項目：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。來看下其官方首頁列出的 ?Envoy ?用戶，說星光熠熠一點也不為過。注意列表里的 ?F5，是不是很有意思。

（Envoy 最終用戶列表）

后浪：為時代而生

下面我將從技術方面來看看為何 Envoy 能夠得到社區的如此重視。將從以下幾個方面來總結：

??技術特征??部署架構??軟件架構

技術特征

??接口化與 API??動態性??擴展性??可觀測性??現代性

接口化與 API

當我第一次打開 Envoy 的配置時候，我的第一感覺是，天啊，這樣一個產品用戶該怎么配置和使用。先來直觀的感受下，在一個并不復雜的實驗環境下，一個 Envoy 的實際配置文件行數竟然達到了 20000 行。

# kubectl exec -it productpage-v1-7f4cc988c6-qxqjs -n istio-bookinfo -c istio-proxy -- sh $ curl http://127.0.0.1:15000/config_dump | wc -l% Total % Received % Xferd Average Speed Time Time Time CurrentDload Upload Total Spent Left Speed 100 634k 0 634k 0 0 10.1M 0 --:--:-- --:--:-- --:--:-- 10.1M 20550

盡管這是 Istio 環境下的動態配置，雖然還有方式去優化使得實際配置量減少，或者說當完全使用靜態配置方式進行配置的時候我們不會做如此大量的配置，但是當我們看到以下實際的配置結構輸出就會感覺到對于這樣一個軟件，如果以普通方式進行配置與維護顯然是不切實際的，其配置完全 json 結構化，并擁有大量的描述性配置，相對于 NGINX 等這些反向代理軟件來說，其配置結構實在是過于復雜。

(復雜的配置結構)

顯然，Envoy 的設計天生就不是為手工而設，因此 Envoy 設計了大量的 xDS 協議接口，需要用戶自行設計一個 xDS 的服務端實現對所有配置處理，Envoy 支持 gRPC 或者 REST 與服務端進行通信從而更新自身的配置。xDS 是 Envoy DS（discover service）協議的統稱，具體可分為 Listener DS（LDS), Route DS (RDS), Cluster DS (CDS), Endpoint DS (EDS), 此外還有 Secret DS，為了保證配置一致性的聚合 DS-ADS 等，更多的 xDS 可查看這里。這些接口用于自動化產生各種具體不同的配置對象。可以看出，這是一個高度動態性的運行時配置，要想用好它則必須開發一個具有足夠能力的 server 端，顯然這不是傳統反向代理軟件的設計思維。

(圖片來自 https://gist.github.com/nikhilsuvarna/bd0aa0ef01880270c13d145c61a4af22)

動態性

正如前面所述，Envoy 的配置高度依賴接口自動化產生各種配置，這些配置是可以進行 Runtime 修改而無需 reload 文件，在現代應用架構中，一個服務端點的生命周期都變得更短，其運行的不確定性或彈性都變得更大，所以能夠對配置進行 runtime 修改而無需重新 reload 配置文件這個能力在現代應用架構中顯得尤其珍貴，這正是 Istio 選擇 Envoy 作為數據平面的一個重要考慮。Envoy 同時還具備熱重啟能力，這使得在升級或必須進行重啟的時候變得更加優雅，已有連接能夠得到更多的保護。

在 Istio 場景下，Envoy 的容器里運行兩個進程，一個叫 pilot-agent，一個是 envoy-proxy 本身，pilot-agent 負責管理與啟動 Envoy，并產生一個位于 /etc/istio/proxy/ 下的 envoy-rev0.json 初始配置文件，這個文件里定義了 Envoy 應該如何與 pilot server 進行通信以獲取配置，利用該配置文件最終啟動 Enovy 進程。但是 Envoy 最終運行的配置并不僅僅是 envoy-rev0.json 里的內容，它包含上文所說的通過 xDS 協議發現的所有動態配置。

# kubectl exec -it productpage-v1-7f4cc988c6-qxqjs -n istio-bookinfo -c istio-proxy -- sh $ ps -ef UID PID PPID C STIME TTY TIME CMD istio-p+ 1 0 0 Jun25 ? 00:00:33 /usr/local/bin/pilot-agent proxy sidecar --domain istio-bookinfo.svc.cluster.local --serviceCluster productpage.istio-bookinfo --proxyLogLevel=warning --proxyComp istio-p+ 14 1 0 Jun25 ? 00:05:31 /usr/local/bin/envoy -c etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster productpage.istio-bookin istio-p+ 142 0 0 15:38 pts/0 00:00:00 sh istio-p+ 148 142 0 15:38 pts/0 00:00:00 ps -ef

在下圖的 envoy 整體配置 dump 中可以看到包含了 bootstrap 的內容以及其它靜態以及動態配置：

(Envoy 配置結構)

結合下圖可以看出基本的 Envoy 配置結構及其邏輯，無論是入口 listener（類似 F5 的 VS 以及部分 profile 配置，NGINX 的 listener 以及部分 Server 段落配置）還是路由控制邏輯（類似 F5 LTM policy，NGINX 的各種 Locations 匹配等），還是 Clusters（類似 F5 pool， NGINX 的 upstream）、Endpoints（類似 F5 pool member，NGINX 的 upstream 里的 server），乃至 SSL 證書完全可以通過接口從服務側自動化的發現過來

(圖片來自 https://gist.github.com/nikhilsuvarna/bd0aa0ef01880270c13d145c61a4af22)

擴展性

Envoy 的配置中可以看到大量的 filter，這些都是其擴展性的表現，Envoy 學習了 F5 以及 NGINX 的架構，大量使用插件式，使得開發者可以更加容易的開發。從 listener 開始就支持使用 filter，支持開發者開發 L3,L4,L7 的插件從而實現對協議擴展與更多控制。

在實際中，企業在 C++ 的開發儲備方面可能遠不如 JavaScript 等這樣的語言多，因此 Envoy 還支持 Lua 以及 Webassembly 擴展， 這一方面使得無需經常重新編譯二進制并重啟，另一方面降低了企業插件開發難度，讓企業可以使用更多兼容 Webassembly 的語言進行插件編寫，然后編譯為 Webassenmbly 機器碼實現高效的運行。目前來說 Envoy 以及 Istio 利用 Webassembly 做擴展還在早期階段，走向成熟還需一段時間。

(圖片來自 https://www.servicemesher.com/istio-handbook/concepts/envoy.html)

從上面的圖可以看出，這樣的請求處理結構非常的接近于 F5 TMOS 系統的設計思想，也在一定程度上與 NGINX 類似。連接、請求在不同的協議層面與階段對應不同的處理組件，而這些組件本身是可擴展的、可編程的，進而實現對數據流的靈活編程控制。

可觀測性

說 Envoy 生來具備云原生的特質，其中一大特點就是對可觀測性的重視，可以看到可觀測的三大組件：logs，metrics，tracing 默認都被 Envoy 所支持。

Envoy 容許用戶以靈活的方式在靈活的位置定義靈活的日志格式，這些變化可以通過動態配置下發從而實現立即生效，并容許定義對日志的采樣等。在 Metrics 則提供了能夠與 Prometheus 進行集成的諸多指標，值得一提的是 Envoy 容許 filter 本身來擴充這些指標，例如在限流或者驗證等 filter 中容許插件本身定義屬于自己的指標從而幫助用戶更好的使用和量化插件的運行狀態。在 Tracing 方面 Envoy 支持向 zipkin，jaeger，datadog，lightStep 等第三方集成，Envoy 能夠生產統一的請求 ID 并在整個網絡結構中保持傳播，同時也支持外部的 x-client-trace-id，從而實現對微服務之間關系拓撲的描述。

Envoy 生成的每個 span 包含以下數據：

??通過設置?--service-cluster?的原始服務集群信息。??請求的開始時間和持續時間。??通過設置?--service-node?的原始主機信息。??通過?x-envoy-downstream-service-cluster?標頭設置的下游集群。?HTTP 請求 URL，方法，協議和用戶代理。??通過?custom_tags?設置的其他自定義標簽。??上游集群名稱和地址。?HTTP 響應狀態代碼。?GRPC 響應狀態和消息（如果可用）。?HTTP 狀態為 5xx 或 GRPC 狀態不是 “OK” 時的錯誤標記。??跟蹤特定于系統的元數據。

現代性

其實，說 Envoy 具有現代性顯然是正確的廢話，Envoy 天生為現代應用架構而生，這里主要是想從幾個我們最容易能夠感受到的方面來說明一下。首先是其特殊的結構設計，在 Envoy 里它支持利用 iptables 截取流量并做透明處理，其本身能夠利用 getsockopt () 實現對 NAT 條目中原始目的信息的提取，并在 listener 監聽上容許在從被跳轉的端口 listener 中跳躍到實際能匹配原始目的信息的非綁定型 listener，盡管從反向代理角度看這就有點像 F5 的 VS 內部跳轉，NGINX 的 subrequest，但是其最大的特點和能力在于對連接的透明性，這在 Pod sidecar 模式的部署中顯得尤其重要， 具體原理可參考這里。

對于現代應用最愛的灰度發布，流量鏡像，斷路器，全局限流等等功能，其在配置上也非常的簡潔，這一點盡管 F5/NGINX 等軟件也能完成類似的工作，但在原生性上以及配置的難易程度上 Envoy 具有更大優勢。

現代性的另一個表現就是對協議的支持，看看以下支持的協議，熟悉應用交付、反向代理軟件的同學可能會情不自禁的表示贊嘆，而這些協議的支持更從另一方面表現了 Envoy 作為更加面向開發者和 SRE 的一個特質。

?gRPC?HTTP2?MongoDB?DynamoDB?Redis?Postgres?Kafka?Dubbo?Thrift?ZooKeeper?RockeMQ

部署架構

在了解完 Envoy 的技術特征后，再來從部署架構角度看 Enovy。

完整 Sidecar 模型部署，這是 Envoy 最大的部署特征，services 之間的通信完全轉化為 Envoy 代理之間的通信，從而實現將諸多非業務功能從服務代碼中移出到外部代理組件，Envoy 負責網絡通信控制與流量的可觀測。也可以部署為簡化的 sidecar，其僅充當 service 入站方向的代理，無需額外的流量操縱，這個結構在我對外闡述的基于 NGINX 實現業務可觀測性中所使用。

(圖片來自 https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#request-flow)

Hub 型，這與 NGINX 的 MRA 中的 Router-mesh 型理念相同，所有服務使用一個集中的 Envoy 進行通信，這種部署結構一般適用于中小型服務，可通過與服務注冊的適配將服務流量導向到 Envoy。

(圖片來自 https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#request-flow)

Envoy 也可以作為 Ingress edge 網關或 Egress 網關，在這種場景下一般 Envoy 多用于 Ingress controller 或 API 網關，可以看到很多的此類實現喜歡使用 Envoy 作為底層，例如 Gloo, Ambassador 等。

(圖片來自 https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#request-flow)

下面這個部署結構應該是大家比較熟悉的，Envoy 作為一個 Edge 網關，并同時部署額外一層微服務網關（或代理平臺層）。

(圖片來自 https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#request-flow)

最后，這是將所有形態的 Envoy 部署集中到了一起，這種架構可能會在服務從傳統架構向微服務架構遷移過程的中間形態。

(圖片來自 https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#request-flow)

最后，來看一下 Istio 里是如何使用 Envoy 的。

(圖片來自網絡)

總結來看，由于 Envoy 的跨平臺性，使其具有和 NGINX 一樣的靈活部署結構，但是實際上部署結構往往與最終的配置實現機制有著強關系，軟件的能力能否適應在此結構下的靈活與簡單的配置實現是最終考驗。客觀的講，在這方面 Envoy 更具有優勢。

軟件架構

Envoy 采用了單進程多線程的設計結構，主線程負責配置更新，進程信號處理等。請求則是由多個 worker 線程來處理，為了簡化與避免處理復雜，一個連接始終由一個線程處理，這樣可盡量減少線程間的數據共享而引發的一些鎖操作。Envoy 盡可能的避免線程之間的狀態共享，為此設計了 Thread Local Store 機制。在日志的寫入上，實際上是 worker 線程寫入到內存緩存，最后再由文件刷新線程來負責寫入到磁盤，這樣可以在一定程度上提高效率。整體上來說，Envoy 在設計時候還是比較偏重于簡化復雜性，并強調靈活性，因此與 NGINX 不同它并沒有把對性能的追求放在第一位，這一點在 Envoy 的相關官方博客里可以得到驗證。

（圖片來自 https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310）

與 NGINX 類似，Envoy 整體是異步非阻塞的設計，采用的是事件驅動方式。每個線程都負責每一個 listener，可以采用 SO_REUSEPORT 也可以共享 socket，NGINX 也有類似的機制。

（圖片來自 https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request#request-flow）

當請求由 listener 監聽并開始處理后，根據配置連接將會被后續的 L3、4、7 等多個 filter 進行處理。

圖片取自 jimmysong.io

前浪：寶刀未老

在了解完 Envoy 的技術特性及其架構后，我們再回到此文的原點。Envoy 從出生就帶著現代應用架構的基因，是不是說對于 NGINX/F5 等這些前浪就落伍了呢。

記得 NGINX 的作者 Igor 在 F5 中國 520 大會上曾這樣對大家介紹 NGINX 為何如此成功。他說，他沒有想到會如此成功，究其原因是他在正確的時間點開發了一個正確的軟件。我們知道，在 2003 年左右那個時期，還談不上什么分布式架構、微服務，那時候主要要解決的是單機性能問題，正是基于這樣的背景，NGINX 無論從架構設計還是代碼質量都嚴格苛求于性能。在功能上，NGINX 本來是一款 Web Server 軟件，L7 反向代理則是其能力的延伸，而 L4 代理能力的增加則更晚，鑒于這樣的背景，從現代應用架構角度來看，確實有一些能力是較難覆蓋的。同樣，Envoy 誕生和發展于現代應用架構時代，正如 Envoy 自我闡述，其參考了大量已有的軟硬件反向代理、負載均衡產品，從上面的技術分析中也可以看出 Envoy 有很多 NGINX 以及 F5 架構理念，可以說 Envoy 從成熟的反向代理產品中吸取了諸多精華，并在設計時候充分考慮現代應用架構的需求，它也是一個在正確的時間的一個正確軟件。

微服務架構下，很多問題都變成了如何控制服務之間的通信與流量洞察，這是典型的應用交付領域，作為這個領域的前浪一方面需積極擁抱和適應新時代的應用架構，一方面需要創新并繼續引領新的方向。歷史上這個領域發生了兩次技術革新，第一次是在 2006 年左右，當時一度關于 “負載均衡已死” 話題被炒爆，實質是當時市場開始發生變換，大家不再滿足于簡單的負載均衡，需求衍生到應用安全、網絡優化、應用優化、接入控制、流量控制等更多復雜的場景，應用交付概念開始被提出，可以說在 2006 年前，市場的主要概念和技術方向是以四層交換機為核心理念的負載均衡技術，大部分玩家是傳統網絡廠商，思維與概念都是以網絡交換為基礎，而 F5 就像一個奇怪的家伙，產品設計思想完全在另一個維度之上，自 2004 年就開始發布的 TMOS V9 操作系統自此開始引領市場，此后 10 年，無人超越。第二次技術革新發生在 2016 年左右，受云、微服務的影響，軟件化、輕量化變為市場主流，同時 Devops 思想意味著使用者角色發生了變化，傳統的面向網絡運維人員的設計開始變得難以滿足市場需求。以 F5 為主導的這個領域在市場上也發生了新的變化，Gartner 不再對應用交付領域發布魔力象限分析，轉而形成以 Guide 方式的指導。

F5 股價走勢圖

看當下，歷史總是驚人的相似。

現代應用架構飛速發展，大量應用開始微服務化，但從業務訪問的整體鏈條來看，Enovy 還不能解決所有問題，例如應用安全防護，復雜的企業協議，以及不同的組織關系導致的不同需求。可以看到以 F5/NGINX 為代表的應用交付產品在 Devops 大潮下也開始積極的實現產品融入，F5 發布了完整的自動化工具鏈，從產品的 bootstrap 到網絡配置、到應用服務配置，到最后的監控遙測都已經形成了完整的接口，并采用聲明式接口來將產品管理提升到更高角色人群與管理系統中。NGINX 同樣構建了自身的 API 以及 Controller 平面，對外提供聲明式 API 接口，開發者可以更好的利用接口融入自身的控制平面。這些變化都是為了讓開發者或者 SRE 能夠更好的使用 F5/NGINX, 詳細可以參考我的《從傳統 ADC 邁向 Cloud Native ADC》系列文章。

F5 在收購 NGINX 與 Shape 之后，提出了新的 view，將充分利用可廣泛觸達的數據平面能力，借助 AI 進一步挖掘數據潛能幫助用戶更好的掌握和了解應用行為、性能，為業務運營提出參考，并反饋到組件配置與運行管理，從而形成閉環。

現代應用交付依然不能缺少一個重要場景，那就是應用安全，盡管 Istio 等產品在安全通信，身份，策略方面做了不少的嘗試，但是應用安全本身則比較缺乏，F5 作為 WAF 安全領域的領導廠商，通過將安全能力轉移到 NGINX 上形成了新的 NGINX APP Protect，利用其跨平臺的能力幫助用戶更好的管理微服務場景下的應用安全能力，幫助企業更好的落地 DevSecOps。

如果將 Envoy 的那些技術特征與 F5 進行對比的話，我們可以看到 F5 一定程度上欠缺在擴展性與現代性上，F5 具有較好的編程控制能力，但是相對于更大的插件開發來說是不足的，這和現代性往往可以聯系到一起看，比如想針對某個很新的協議做一個類似 Envoy 的復雜 7 層 filter 是無法實現的，盡管 iRule 或者 iRuleLX 可以一定程度上做一些事情。然而無論怎樣，最終 F5 的產品形態本身決定了 F5 的 BIGIP 是無法完全跨平臺的，因為它無法以容器來運行。值得期待的是，這樣的形態限制將會被 F5 下一代 TMOS 系統打破。

Service Mesh 是當前熱門的技術方向，F5 基于 Istio 打造了企業級的 Aspen Mesh 服務網格產品，幫助企業更好、更容易的部署和使用 Istio。Aspen mesh 團隊成員進入僅有 7 個位置的的 Istio Technical Oversight Committee，負責 Istio 的 RFCs/Designs/APIs 等方面的重要職責。盡管 Istio 在 service mesh 領域擁有絕對的生態與熱度，但這并不表示 Istio 是唯一的選擇，在很多時候客戶可能希望采用一種更加簡潔的 Service Mesh 去實現大部分所需功能而不是去部署一整套復雜的 Istio 方案，基于 NGINX 組件打造的 NGINX Service Mesh (NSM) 將為用戶帶來新的選擇，一個更加簡單易用的 Service Mesh 產品，這是我們在文章最開始提到 NGINX 終止 Nginmesh 的原因。

總結

技術發展是一個必然的過程，2006 年從傳統的負載均衡技術演變為應用交付，除了負載均衡之外，引入安全、訪問控制、接入控制、流量控制等諸多方面。2016 年左右，這個領域再次發生新的技術變革，大量新生代反向代理開源軟件的出現對傳統應用交付類產品產生了一次新的沖擊，積極適應與改變并創新是制勝的關鍵。Envoy 作為新代表有著優秀的能力，但它也不是解決所有問題的銀彈，Envoy 擁有更陡峭的學習曲線以及更高開發成本與維護成本，對于企業來說應根據實際情況選擇合適的解決方案與產品來解決架構中的不同問題，避免追趕潮流而讓自己陷入陷阱。

F5 則更加需要讓開發人員了解 TMOS 系統所擁有的巨大潛能（特別是下一代產品在架構以及形態上的顛覆），了解其優秀全代理架構以及可以在任意層面進行的編程控制， 讓開發者、SRE 以 F5 TMOS 作為一種能力平臺和中間件進行開發，更好的利用 F5 自身已經擁有的應用交付能力來快速實現自身需求。

最后，再次引用 Envoy 官方網站首頁的一句話：

正如微服務從業者很快意識到的那樣，當轉移到分布式體系結構時出現的大多數操作問題最終都基于兩個方面：網絡和可觀察性。

而保證更可靠的網絡交付與更好的可觀察性正是前浪們的強項。創新吧，前浪。

寫在最后：無論技術如何更迭，人的因素依舊是核心，不論企業自身還是廠商，在這樣一輪技術浪潮中都應具備足夠的技術儲備，就像傳統金融行業通過建立科技公司尋求轉變一樣，廠商同樣需要轉型，F5 中國的 SE 幾乎 100% 的通過了 CKA 認證，無論相對比例還是絕對數量在業界應該是惟一了，轉型不只在產品，更在于思想。

開源電子書 Istio Handbook

ServiceMesher 社區作為中國最早研究和推廣 Service Mesh 技術的開源技術社區，于今年 2 月重啟了開源電子書 Istio Handbook 的創作，本書側重本書更加注重基礎知識的提煉及實戰經驗分享，當前已有 21 人參與了編寫，創作仍在進行中，歡迎更多人參與進來，參與方式及在線瀏覽地址為?https://www.servicemesher.com/istio-handbook

點擊?閱讀原文?查看更多

總結

以上是生活随笔為你收集整理的应用交付老兵眼中的Envoy, 云原生时代下的思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。