Envoy Gateway 云原生时代的流量入口

流量入口代理作为互联网系统的门户组件，具备众多选型：从老牌代理 HAProxy、Nginx，到微服务 API 网关 Kong、Zuul，再到容器化 Ingress 规范与实现，不同选型间功能、性能、可扩展性、适用场景参差不齐。当云原生时代大浪袭来，Envoy 这一 CNCF 毕业数据面组件为更多人所知。那么，优秀“毕业生”Envoy 能否成为云原生时代下流量入口标准组件？

背景 —— 流量入口的众多选型与场景

在互联网体系下，凡是需要对外暴露的系统几乎都需要网络代理：较早出现的 HAProxy、Nginx 至今仍在流行；进入微服务时代后，功能更丰富、管控能力更强的 API 网关又成为流量入口必备组件；在进入容器时代后，Kubernetes Ingress 作为容器集群的入口，是容器时代微服务的流量入口代理标准。关于这三类典型的七层代理，核心能力对比如下：

从上述核心能力对比来看：

HAProxy&Nginx 在具备基础路由功能基础上，性能、稳定性经历多年考验。Nginx 的下游社区 OpenResty 提供了完善的 Lua 扩展能力，使得 Nginx 可以更广泛的应用与扩展，如 API 网关 Kong 即是基于 Nginx+OpenResty 实现。API 网关作为微服务对外 API 流量暴露的基础组件，提供比较丰富的功能和动态管控能力。Ingress 作为 Kubernetes 入口流量的标准规范，具体能力视实现方式而定。如基于 Nginx 的 Ingress 实现能力更接近于 Nginx，Istio Ingress Gateway 基于 Envoy+Istio 控制面实现，功能上更加丰富（本质上 Istio Ingress Gateway 能力上强于通常的 Ingress 实现，但未按照 Ingress 规范实现）。那么问题来了：同样是流量入口，在云原生技术趋势下，能否找到一个能力全面的技术方案，让流量入口标准化？

Envoy 核心能力介绍

Envoy 是一个为云原生应用设计的开源边缘与服务代理（ENVOY IS AN OPEN SOURCE EDGE AND SERVICE PROXY, DESIGNED FOR CLOUD-NATIVE APPLICATIONS，@envoyproxy.io），是云原生计算基金会（CNCF）第三个毕业的项目，GitHub 目前有 13k+ Star。

Envoy 有以下主要特性：

基于现代 C++ 开发的 L4/L7 高性能代理。

透明代理

流量管理。支持路由、流量复制、分流等功能

治理特性。支持健康检查、熔断、限流、超时、重试、故障注入

多协议支持。支持 HTTP/1.1，HTTP/2，GRPC，WebSocket 等协议代理与治理。

负载均衡。加权轮询、加权最少请求、Ring hash、Maglev、随机等算法支持。支持区域感知路由、故障转移等特性。

动态配置 API。提供健壮的管控代理行为的接口，实现 Envoy 动态配置热更新。

可观察性设计。提供七层流量高可观察性，原生支持分布式追踪。

支持热重启。可实现 Envoy 的无缝升级。

自定义插件能力。Lua 与多语言扩展沙箱 WebAssembly。

总体来说，Envoy 是一个功能与性能都非常优秀的“双优生”。在实际业务流量入口代理场景下，Envoy 具备先天优势，可以作为云原生技术趋势流量入口的标准技术方案：

1. 较 HAProxy、Nginx 更丰富的功能

相较于 HAProxy、Nginx 提供流量代理所需的基本功能（更多高级功能通常需要通过扩展插件方式实现），Envoy 本身基于 C++ 已经实现了相当多代理所需高级功能，如高级负载均衡、熔断、限流、故障注入、流量复制、可观测性等。更为丰富的功能不仅让 Envoy 天生就可以用于多种场景，原生 C++ 的实现相较经过扩展的实现方式性能优势更为明显。

2. 与 Nginx 相当，远高于传统 API 网关的性能

在性能方面，Envoy 与 Nginx 在常用协议代理（如 HTTP）上性能相当。与传统 API 网关相比，性能优势明显。如下为 Envoy 与几种业务常用的 API 网关选型在 8 核物理机容器运行环境下，简单路由代理性能对比数据：

Envoy Gateway：

 

基于 Java 的异步化 API 网关：

 

Kong：

APISIX： 

 

 

从以上性能数据可以看出，相同条件下：

Envoy 的 TPS 可以达到 12W 左右；

基于 Java 的异步化 API 网关最高可到 2.8W 左右；

基于 Nginx 的 Kong，TPS 可以到 5W 左右；

基于 Nginx 并相较 Kong 有一定优化的 APISIX 可以到 9W 左右。可以看出：

简单路由代理场景下，Envoy 性能优势已经比较明显；

复杂路由与治理功能场景下，Envoy 原生 C++ 实现功能的性能较通过 Java Filter、OpenResty 等扩展相比，优势会更加明显。

3. 动态管控能力强，具备数据面标准 xDS 协议

Envoy 具备静态配置与动态 API 两种配置模式。动态 API 方式灵活性更强，作为 Envoy 推荐的配置方式。Envoy 以 xDS（x Discovery Service）作为动态 API 的标准协议，其中包括了多种维度资源的发现协议：

LDS(Listener Discovery Service)

RDS(Route Discovery Service)

CDS(Cluster Discovery Service)

EDS(Endpoint Discovery Service)

ADS(Aggregated Discovery Service)

xDS 的多种协议覆盖了包括监听器（Listener）、路由（Route）、后端集群（Cluster）、后端实例（Endpoint），可以通过协议对代理所需所有配置进行动态管控。其中 ADS 不是一个实际意义上的 xDS，它提供了一个汇聚的功能，以实现需要多个同步 xDS 访问的时候可以在一个 stream 中完成的作用。

由于 Envoy 已经以 CNCF 毕业项目的姿态成为了云原生数据面的事实标准组件，xDS 也相应成为云原生数据面事实动态 API 标准。这里不对 xDS 协议进行深入的介绍，感兴趣的同学可以通过社区与博客深入了解。

4. 天然亲和容器环境

Envoy 作为云原生社区的数据面标准组件，其本身并没有直接与 Kubernetes 或容器耦合。通过 xDS 协议的对接，Istio Pilot 等容器亲和的控制面组件可以将服务、实例、路由等配置信息推送至 Envoy。即使是在容器环境，Envoy 也很快能实现服务发现，即实现容器环境服务的代理和治理。所以，Envoy 天然亲和容器环境，可以作为容器环境 API 网关和 Ingress 的数据面选型。

5. 多语言扩展沙箱——WASM

WASM，即 WebAssembly，是由主流浏览器厂商组成的 W3C 社区团体制定的一个新的规范，首先看下来自 Mozilla 的官方定义：WebAssembly 是一种新的编码方式，可以在现代的网络浏览器中运行

它是一种低级的类汇编语言，具有紧凑的二进制格式，可以接近原生的性能运行，并为诸如 C/C ++ 等语言提供一个编译目标，以便它们可以在 Web 上运行。它也被设计为可以与 JavaScript 共存，允许两者一起工作

使用 WebAssembly 扩展 Envoy 的好处是：

避免修改 Envoy；

避免网络远程调用（check & report）；

通过动态装载（重载）来避免重启 Envoy；

隔离性；

实时 A/B 测试；

WASM 为 Envoy 带来了使用多语言扩展数据面的能力，即可以不局限地通过 C++、Java、Lua、JS 等语言进行数据面扩展，这对于流量代理数据面将是一个巨大的彩蛋。该特性已在 2020 年正式发布落地。相信在不远的未来，开发者使用自己最为擅长的语言进行流量入口能力扩展不再是梦想！