## 業界對比 總的來說，我們相信Envoy為現代服務導向架構提供了獨特且引人注目的功能。下面我們比較一下Envoy和其他相關的系統。盡管在任何特定的領域（邊緣代理，軟件負載平衡器，服務消息傳遞層），Envoy可能不像下面的一些解決方案那樣具有豐富的功能，但總體而言，沒有其他解決方案將相同的整體特征提供到單個自包含的高性能套餐。 注：以下大部分項目也都正在積極開發中。因此，一些信息可能會過時。如果是這種情況，請讓我們知道，我們會解決它。 ### [nginx](https://nginx.org/en/) nginx是規范的現代Web服務器。它支持靜態內容服務，HTTP L7反向代理和負載均衡，HTTP/2和許多其他功能。盡管我們認為大多數現代的面向服務的體系結構通常不使用它們，但nginx比Envoy更具有整體特性作為前端反向代理。與nginx相比，Envoy提供了以下主要優勢作為前端代理： - 完整的HTTP/2透明代理。Envoy支持下行和上行通信的HTTP/2。nginx僅支持HTTP/2用于下游連接。 - 自由提供高級負載均衡。只有nginx plus（付費服務器）支持與Envoy類似的高級負載均衡功能。 - 能夠在前端以及每個服務節點上運行相同的軟件。許多基礎設施運行nginx和haproxy的混合。從操作的角度來看，每一跳的單一代理解決方案都要簡單得多。 ### [HAProxy](http://www.haproxy.org/) haproxy是規范的現代負載平衡器軟件。它也支持基本的HTTP反向代理功能。作為負載均衡器，Envoy提供了比haproxy更多的主要優勢： - HTTP/2支持。 - 可插拔的架構。 - 多線程架構。當每臺機器部署單個進程而不是多個進程時，操作和配置電路中斷設置要容易得多。 - 與遠程服務發現服務集成。 - 與遠程全球限速服務集成。 - 能夠熱重啟。 - 更詳細的統計。 ### [AWS ELB](https://aws.amazon.com/elasticloadbalancing/) Amazon的ELB是用于EC2應用程序服務發現和負載平衡的標準解決方案。Envoy相比ELB作為負載平衡器和服務發現系統，主要提供了以下優勢： - 統計和日志記錄（CloudWatch統計信息滯后，并且極其缺乏細節，日志必須從S3中檢索，并具有固定格式）。 - 穩定性（使用ELB時偶爾會出現不穩定情況，最終無法調試）。 - 先進的負載平衡，并且與節點之間的直接連接。Envoy網格通過硬件的可伸縮性，避免了額外的網絡跳躍。負載平衡器可以做出更好的決策，并根據區域，灰度狀態等收集更有價值的統計信息。負載平衡器還支持諸如重試等高級功能。 AWS最近發布了應用程序負載均衡器產品。該產品將支持HTTP/2以及基本HTTP L7請求路由，并添加到多個后端群集。與Envoy相比，這個功能還是很小的，性能和穩定性是未知的，但顯然AWS將來會繼續在這個領域進行投資。 ### [SmartStack](http://nerds.airbnb.com/smartstack-service-discovery-cloud/) SmartStack是一個有趣的解決方案，它提供了haproxy之上，額外的支持了服務發現和健康檢查。在高層次上，SmartStack與Envoy（外置進程架構，應用程序平臺不感知等）具有大部分相同的目標。作為負載平衡器和服務發現軟件包，Envoy相對于SmartStack提供了以下主要優勢： - 與haproxy相比，包括前面提到的所有優點。 - 集成服務發現和主動健康檢查。Envoy在一個單一的高性能組件中提供了一切。 ### [Finagle](https://twitter.github.io/finagle/) Finagle是Twitter的Scala/JVM服務，用于服務通信庫。Twitter和許多其他公司主要使用基于JVM的體系架構。它具有許多與Envoy相同的功能，例如服務發現，負載平衡，過濾器等。與Finagle相比，Envoy作為負載平衡器和服務發現軟件包提供了以下主要優勢： - 通過分布式主動健康檢查實現最終一致的服務發現。 - 所有度量標準（內存消耗，CPU使用率和P99延遲屬性）的性能級別都較好。 - 外置進程和應用程序平臺不感知的架構。Envoy可以與任何應用程序工作。 ### [proxygen](https://github.com/facebook/proxygen)和[wangle](https://github.com/facebook/wangle) proxygen是Facebook的高性能C++11 HTTP代理庫，寫在一個叫做wangle的Finagle之類的C++庫之上。從代碼角度來看，Envoy使用與proxygen大部分相同的技術來獲得作為HTTP 庫/代理的高性能。除此之外，這兩個項目并沒有真正的可比性，因為Envoy是一個完整的包含大型功能的獨立服務，而不是每個項目都需要單獨構建的庫。 ### [gRPC](http://www.grpc.io/) gRPC是一種新的多平臺消息傳遞系統。它使用IDL來描述RPC庫，然后為各種不同的語言實現特定于應用程序的運行時。底層傳輸是HTTP/2。盡管gRPC可能有將來實現許多類似于Envoy的特性（負載平衡等）的目標，但是到目前為止，各種運行時并不成熟，主要關注于序列化/反序列化。我們認為gRPC和Envoy是合作伙伴，并非競爭對手。這里描述了Envoy如何與gRPC集成。 ### [linkerd](https://github.com/BuoyantIO/linkerd) linkerd是一個基于Netty和Finagle（Scala/JVM）的獨立開源RPC路由代理。linkerd提供了許多Finagle的功能，包括延遲感知負載平衡，連接池，斷路，重試閾值，截止期限，跟蹤，細粒度檢測以及用于請求級路由的流量路由層。linkerd提供了一個可插拔的服務發現接口（標準支持Consul和ZooKeeper以及Marathon和KubernetesAPI）。 linkerd的內存和CPU要求明顯高于Envoy的。與Envoy相比，linkerd提供了極簡配置語言，并且明確地不支持熱重啟，而是依賴于動態配置和服務抽象。linkerd支持HTTP/1.1，Thrift，ThriftMux，HTTP/2（試驗階段）和gRPC（試驗階段）。 ### [nghttp2](https://nghttp2.org/) nghttp2是一個包含幾個不同東西的項目。它主要包含一個實現HTTP/2協議的庫（nghttp2）。Envoy使用這個庫（在頂層簡單封裝）來支持HTTP/2。該項目還包含一個非常有用的負載測試工具（h2load）以及一個反向代理（nghttpx）。從比較的角度來看，Envoy與nghttpx最為相似。nghttpx是一個透明的HTTP/1、HTTP/2反向代理，支持TLS終止代理，正確支持gRPC代理以及其他各種功能。有了這個說法，我們認為nghttpx是各種代理功能的一個很好的例子，而不是一個強大的生產就緒解決方案。Envoy的重點更多地集中在可觀察性，一般操作敏捷性和高級負載平衡功能上。 ## 返回 - [簡介](../Introduction.md) - [首頁目錄](../README.md)