介绍 | Envoy | Nginx | HAproxy |
|---|---|---|---|
HTTP/2 | 对HTTP/2有最完整的支持,同时支持upstream和downstream的HTTP/2 | 1.9.5以后有限支持HTTP/2,只在upstream server支持,downstream依然是1.1 | 不支持 |
Rate Limit | 通过插件进行限流 | 支持基于配置的限流,只支持基于源IP的限流 | |
ACL | 给予插件实现四层的ACL | 给予源/目的地址实现ACL | |
Connection draining | 支持hot reload,并且通过share memory实现connection draining功能 | Plush版本才支持 | 支持热启动,但是不保证丢弃链接 |
- 性能优势：在具备大量特性的同时,
Envoy提供极高吞吐量和低尾部延迟差异,而CPU和RAM消耗相对减少。 - 可扩展性：
Envoy在L4和L7都提供了丰富的可查吧过滤器能力,使用户可以轻轻松松添加开源版本中的功能 - API的可配置性：
Envoy提供了一组可以通过控制平面实现的管理API,如果控制平面所有的API则可以使用通用的配置在基础架构上运行Envoy,因为它从来不许要重新启动,这样使得Envoy极大的降低了整体运维的复杂性.
Envoy线程模式
Envoy采用单进程多线程模式- 主线程负责协调
- 子线程负责监听过滤和转发
- 当某连接被监听器接受,那么该链接的全部生命周期就会与该线程进行绑定
- Envoy基于非阻塞模式(Epoll模型)
- 建议
Envoy配置的worker数量与Envoy所在的硬件线程数一致
XDS-Envoy的发现机制
-
Endpoint Discovery Service (EDS): 这是v1 SDSAPI的替代品,此外,gRPC的双向流性质将允许负载/健康信息报告回管理服务器,未将来的全局负载均衡开机大门。 -
Cluster Discovery Service (CDS): 跟v1没有实质性变化 -
Route Discovery Service (RDS)： 没有实质变化 -
Listener Discovery Service (LDS)： 和v1的唯一主要变化是：现在允许监听器定义多个并发过滤栈,这些过滤可以基于监听器路由规则(例如 SNI,源地址/目的地址)来进行选择 -
Secret Discovery Service (SDS)：一个专用API来传递TLS密钥材料。这将解耦通过LDS/CDS发送监听器,集群配置通过专用的密钥管理系统来发送。 -
Health Discovery Service (HDS):该API将允许Envoy成为分布式健康检查网络的成员,中央健康检查服务可以使用一组Envoy作为健康检查终点,并将状态报告回来。 -
Aggregated Discovery Service (ADS)： 总的来说,Envoy的设计是最终一致的。这意味着默认情况下,每个管理API都并发运行,并且不会相互交互。一次一个管理服务器处理单个Envoy的所有更新都是有益的。此API允许通过单个管理服务器的单个gRPC双向流对所有其他API进行编组。
