Service Mesh最近很火，它的核心組件之一Envoy代理也很火，那么Envoy和其它同類產品相比有哪些優(yōu)勢呢？
英文原文：https://www.envoyproxy.io/docs/envoy/latest/intro/comparison
---------------------------------正文分割線------------------------------------------
總體來說，我們相信Envoy為現代面向服務的架構提供了一套獨特和有競爭力的功能集合。接下來我們會把Envoy和其它同類系統(tǒng)做一個對比。和下列一些解決方案相比，盡管在一些特定領域里(比如 邊緣代理，軟件負載均衡，服務消息傳遞層)Envoy可能算不上功能完備，但歸結起來，也沒有其它方案能提供和Envoy相同的整體特性，并把它們放到一個自我包含和高性能的軟件包里。
注意：下面列出的大部分工程都處于活躍開發(fā)中。所以某些信息可能已過時。如果你發(fā)現了請告訴我們，我們會進行修改。

nginx
nginx是現代web server的代表。它支持服務靜態(tài)內容，7層HTTP反向代理和負載均衡，HTTP/2，以及很多其它特性。nginx作為邊緣反向代理，擁有一整套比Envoy完備的多的特性。 盡管我們認為當代大多數面向服務的架構一般用不到這些特性。作為邊緣代理，跟nginx比起來Envoy主要有以下優(yōu)勢：

• 完全的HTTP/2透明代理。Envoy在下行和上行通信上都支持HTTP/2。nginx只在下行通信鏈接上支持HTTP/2（譯者：最近nginx好像宣布在上行和下行通信中也都實現了HTTP/2支持，請自行google）。
• 免費的高級負載均衡。和Envoy比起來，只有nginx plus(付費版)才支持類似的高級負載均衡能力。
• 對于同一個軟件，在邊緣和每個服務節(jié)點上都能運行。很多基礎設施需要混合運行nginx和haproxy。從運維角度來說，在每一跳上都使用單一代理的方案要更簡單一些。

haproxy
haproxy是現代軟件負載均衡器的代表。它也支持基本的HTTP反向代理功能。作為負載均衡器，跟haproxy比起來，Envoy主要有以下優(yōu)勢：

• 支持HTTP/2。
• 可插拔架構。
• 可與遠程的‘服務發(fā)現‘服務集成。
• 可與遠程的限流服務集成。
• 更詳盡的統(tǒng)計信息。

AWS ELB
亞馬遜的ELB是EC2中應用程序服務發(fā)現和負載均衡的標準解決方案。作為負載均衡器和服務發(fā)現系統(tǒng)，跟ELB比起來，Envoy提供了以下主要優(yōu)勢：

• 統(tǒng)計信息和日志（CloudWatch統(tǒng)計信息有延遲，并且非常不詳盡，日志必需從S3上獲取，并且只有一種固定格式）。
• 穩(wěn)定性（在使用ELB時，經常會遇到零星的穩(wěn)定性問題，最終也無法調試）。
• 高級負載均衡機制和節(jié)點直連。Envoy避免了可變的彈性硬件導致的額外一個網絡跳躍。負載均衡器可以作出更好的選擇，并且可以基于zone和金絲雀狀態(tài)等，來獲取更多有意義的統(tǒng)計信息。負載均衡器還支持一些高級的特性，比如重試。

AWS最近發(fā)布了一款新的應用程序負載均衡器產品。這款產品添加了HTTP/2協(xié)議支持，也是把7層的HTTP請求路由到后端多個集群。它的功能集跟Envoy比起來還是要小一些，性能和穩(wěn)定性也是未知，但可以肯定的是AWS將會在未來持續(xù)投資這一領域。

SmartStack
SmartStack是個有趣的解決方案，它在haproxy的上層添加了對服務發(fā)現和健康檢查的支持。從頂層設計來說，SmartStack擁有和Envoy一樣的目標（進程外架構，應用平臺不可見，等）。作為負載均衡器和服務發(fā)現軟件包，跟SmartStack比起來，Envoy提供了以下主要優(yōu)勢：

• 所有之前提到的對于haproxy具有的優(yōu)勢。
• 集成了服務發(fā)現和主動健康檢查。Envoy把所有這些集中到了一個高性能軟件包里。

Finagle
Finagle是Twitter為通信庫服務的Scala/JVM服務。它被Twitter和其它主要基于JVM架構的公司使用。它擁有很多和Envoy類似的特性，比如服務發(fā)現，負載均衡，過濾器，等。作為負載均衡器和服務發(fā)現軟件包，跟Finagle比起來，Envoy提供了以下主要優(yōu)勢：

• 通過分布式主動健康檢查實現的最終一致性服務發(fā)現。
• 所有指標在數量級上都有更好表現（內存消耗，CPU占用，P99延遲）。
• 進程外和應用不可見架構。Envoy可與任意程序棧一起工作。

proxygen and wangle
proxygen是Facebook的一個基于C++11開發(fā)的高性能HTTP代理庫，基于一個叫wangle的類似Finagle的C++庫開發(fā)。從代碼角度來看，Envoy使用與proxygen大部分相同的技術來獲取作為HTTP庫/代理的高性能。除此之外，兩個項目并沒有真正的可比性，因為Envoy是一個完全自我包含的服務，擁有龐大的功能集，而proxygen必需由每個項目單獨構建。

gRPC
gRPC是一個Google之外的新的跨平臺消息傳輸系統(tǒng)。它使用一個IDL文件來描述一個RPC庫，然后為不同的語言實現特定于應用程序的運行時(runtimes)。底層傳輸用的是HTTP/2協(xié)議。盡管gRPC看起來有在未來實現很多類似Envoy功能的目標（負載均衡，等）。但由于編寫多個運行時(runtimes)的工作仍處于初級階段，并且它們主要關注序列化和反序列化，所以我們把gRPC看作是Envoy的伙伴而不是競爭者。Envoy如何和gRPC集成請看這里。

linkerd
linkerd是一款獨立的，開源RPC路由代理，構建在Netty和Finagle（Scale/JVM）上。linkerd提供很多Finagle的特性，包括具有延遲感應的負載均衡，連接池，斷路器，重試機制，超時，跟蹤，細粒度的監(jiān)控埋點，和為請求級路由(request-level routing)提供的流量路由層(traffic routing layer)。linkerd提供一個可插拔的服務發(fā)現接口（為Consul和Zookeeper提供標準支持，也支持Marathon和Kubernetes API）。

linkerd對內存和CPU的要求比Envoy要高很多。與Envoy相反，linkerd提供了一個極簡的配置語言，明確不支持熱重新加載，而是依靠動態(tài)配置和服務抽象。linkerd支持HTTP/1.1, Thrift, ThriftMux, HTTP/2 (實驗性質)和gRPC (實驗性質).

nghttp2
nghttp2是一個包含了一些不同組件的項目。首先，它包含了一個實現了HTTP/2協(xié)議的庫(nghttp2)。Envoy使用這個庫（在上面做了一層很薄的封裝）來實現對HTTP/2協(xié)議的支持。該項目還包含了一個非常有用的壓力測試工具（h2load），還有一個反向代理（nghttpx）。從對比角度來說，Envoy最像nghttpx。nghttpx是一款透明的HTTP/1 <-> HTTP/2反向代理，支持TLS終止(TLS termination)，正確地支持gRPC代理，還有很多其它特性。如上所說，我們認為nghttpx是一個具有多種代理功能的極好示例，而不是一款健壯的解決方案級產品。Envoy的關注點更多放在可觀測性(observability)，通用操作敏捷性(general operational agility)，和高級負載均衡等特性上。