Service Mesh最近很火，它的核心组件之一Envoy代理也很火，那么Envoy和其它同类产品相比有哪些优势呢？
英文原文：https://www.envoyproxy.io/docs/envoy/latest/intro/comparison
———————————正文分割线——————————————
总体来说，我们相信Envoy为现代面向服务的架构提供了一套独特和有竞争力的功能集合。接下来我们会把Envoy和其它同类系统做一个对比。和下列一些解决方案相比，尽管在一些特定领域里(比如 边缘代理，软件负载均衡，服务消息传递层)Envoy可能算不上功能完备，但归结起来，也没有其它方案能提供和Envoy相同的整体特性，并把它们放到一个自我包含和高性能的软件包里。
注意：下面列出的大部分工程都处于活跃开发中。所以某些信息可能已过时。如果你发现了请告诉我们，我们会进行修改。

nginx
nginx是现代web server的代表。它支持服务静态内容，7层HTTP反向代理和负载均衡，HTTP/2，以及很多其它特性。nginx作为边缘反向代理，拥有一整套比Envoy完备的多的特性。 尽管我们认为当代大多数面向服务的架构一般用不到这些特性。作为边缘代理，跟nginx比起来Envoy主要有以下优势：

• 完全的HTTP/2透明代理。Envoy在下行和上行通信上都支持HTTP/2。nginx只在下行通信链接上支持HTTP/2（译者：最近nginx好像宣布在上行和下行通信中也都实现了HTTP/2支持，请自行google）。
• 免费的高级负载均衡。和Envoy比起来，只有nginx plus(付费版)才支持类似的高级负载均衡能力。
• 对于同一个软件，在边缘和每个服务节点上都能运行。很多基础设施需要混合运行nginx和haproxy。从运维角度来说，在每一跳上都使用单一代理的方案要更简单一些。

haproxy
haproxy是现代软件负载均衡器的代表。它也支持基本的HTTP反向代理功能。作为负载均衡器，跟haproxy比起来，Envoy主要有以下优势：

• 支持HTTP/2。
• 可插拔架构。
• 可与远程的‘服务发现‘服务集成。
• 可与远程的限流服务集成。
• 更详尽的统计信息。

AWS ELB
亚马逊的ELB是EC2中应用程序服务发现和负载均衡的标准解决方案。作为负载均衡器和服务发现系统，跟ELB比起来，Envoy提供了以下主要优势：

• 统计信息和日志（CloudWatch统计信息有延迟，并且非常不详尽，日志必需从S3上获取，并且只有一种固定格式）。
• 稳定性（在使用ELB时，经常会遇到零星的稳定性问题，最终也无法调试）。
• 高级负载均衡机制和节点直连。Envoy避免了可变的弹性硬件导致的额外一个网络跳跃。负载均衡器可以作出更好的选择，并且可以基于zone和金丝雀状态等，来获取更多有意义的统计信息。负载均衡器还支持一些高级的特性，比如重试。

AWS最近发布了一款新的应用程序负载均衡器产品。这款产品添加了HTTP/2协议支持，也是把7层的HTTP请求路由到后端多个集群。它的功能集跟Envoy比起来还是要小一些，性能和稳定性也是未知，但可以肯定的是AWS将会在未来持续投资这一领域。

SmartStack
SmartStack是个有趣的解决方案，它在haproxy的上层添加了对服务发现和健康检查的支持。从顶层设计来说，SmartStack拥有和Envoy一样的目标（进程外架构，应用平台不可见，等）。作为负载均衡器和服务发现软件包，跟SmartStack比起来，Envoy提供了以下主要优势：

• 所有之前提到的对于haproxy具有的优势。
• 集成了服务发现和主动健康检查。Envoy把所有这些集中到了一个高性能软件包里。

Finagle
Finagle是Twitter为通信库服务的Scala/JVM服务。它被Twitter和其它主要基于JVM架构的公司使用。它拥有很多和Envoy类似的特性，比如服务发现，负载均衡，过滤器，等。作为负载均衡器和服务发现软件包，跟Finagle比起来，Envoy提供了以下主要优势：

• 通过分布式主动健康检查实现的最终一致性服务发现。
• 所有指标在数量级上都有更好表现（内存消耗，CPU占用，P99延迟）。
• 进程外和应用不可见架构。Envoy可与任意程序栈一起工作。

proxygen and wangle
proxygen是Facebook的一个基于C++11开发的高性能HTTP代理库，基于一个叫wangle的类似Finagle的C++库开发。从代码角度来看，Envoy使用与proxygen大部分相同的技术来获取作为HTTP库/代理的高性能。除此之外，两个项目并没有真正的可比性，因为Envoy是一个完全自我包含的服务，拥有庞大的功能集，而proxygen必需由每个项目单独构建。

gRPC
gRPC是一个Google之外的新的跨平台消息传输系统。它使用一个IDL文件来描述一个RPC库，然后为不同的语言实现特定于应用程序的运行时(runtimes)。底层传输用的是HTTP/2协议。尽管gRPC看起来有在未来实现很多类似Envoy功能的目标（负载均衡，等）。但由于编写多个运行时(runtimes)的工作仍处于初级阶段，并且它们主要关注序列化和反序列化，所以我们把gRPC看作是Envoy的伙伴而不是竞争者。Envoy如何和gRPC集成请看这里。

linkerd
linkerd是一款独立的，开源RPC路由代理，构建在Netty和Finagle（Scale/JVM）上。linkerd提供很多Finagle的特性，包括具有延迟感应的负载均衡，连接池，断路器，重试机制，超时，跟踪，细粒度的监控埋点，和为请求级路由(request-level routing)提供的流量路由层(traffic routing layer)。linkerd提供一个可插拔的服务发现接口（为Consul和Zookeeper提供标准支持，也支持Marathon和Kubernetes API）。

linkerd对内存和CPU的要求比Envoy要高很多。与Envoy相反，linkerd提供了一个极简的配置语言，明确不支持热重新加载，而是依靠动态配置和服务抽象。linkerd支持HTTP/1.1, Thrift, ThriftMux, HTTP/2 (实验性质)和gRPC (实验性质).

nghttp2
nghttp2是一个包含了一些不同组件的项目。首先，它包含了一个实现了HTTP/2协议的库(nghttp2)。Envoy使用这个库（在上面做了一层很薄的封装）来实现对HTTP/2协议的支持。该项目还包含了一个非常有用的压力测试工具（h2load），还有一个反向代理（nghttpx）。从对比角度来说，Envoy最像nghttpx。nghttpx是一款透明的HTTP/1 <-> HTTP/2反向代理，支持TLS终止(TLS termination)，正确地支持gRPC代理，还有很多其它特性。如上所说，我们认为nghttpx是一个具有多种代理功能的极好示例，而不是一款健壮的解决方案级产品。Envoy的关注点更多放在可观测性(observability)，通用操作敏捷性(general operational agility)，和高级负载均衡等特性上。