阿里巴巴在 Envoy Gateway 的演进历程浅析

简介：最近阅读《Envoy Gateway 来了》这篇文章，深感 Envoy 强大的可扩展性和基于 Envoy Gateway 带来的易用性，在 K8s 架构下，Envoy 重新定义了网关的定位和能力，被誉为云原生网关，甚至被称之为下一代网关。阿里巴巴早在2018年就启动了下一代网关的探索之路，本文将对这个探索历程做一个简单介绍。

作者：耿蕾蕾(如葑)：阿里云研发工程师，从 2020 年 5 月负责 Envoy Gateway 的构建到推出 3.0，作为技术负责人主导了整个演进过程，在云原生网关领域有着丰富的实践。

最近阅读《Envoy Gateway 来了》这篇文章，深感 Envoy 强大的可扩展性和基于 Envoy Gateway 带来的易用性，在 K8s 架构下，Envoy 重新定义了网关的定位和能力，被誉为云原生网关，甚至被称之为下一代网关。阿里巴巴早在2018年就启动了下一代网关的探索之路，本文将对这个探索历程做一个简单介绍。

阿里巴巴早在 2018 年，就开启了云原生上云的序幕，将容器、服务网格作为核心技术点进行演进，并尝试阿里巴巴和蚂蚁通过这次技术演进，来统一双方的中间件技术栈，让业务更聚焦业务开发，屏蔽底层分布式复杂度。作为服务网格一个重要方向，我们开启了下一代网关的探索之路。

Envoy Gateway 1.0（孵化期）

上云过程中，我们期望统一应用架构技术栈，但是蚂蚁和阿里巴巴的 RPC 协议不同，存在互调链路长、协议转换消耗大、Tengine Reload 访问有损（接入生效快就需要不断 reload 有损，如果控制 reload 影响，就要减少 reload 次数，接入服务生效慢）、Nginx 内核服务治理能力较弱等问题。因此，需要一个面对未来的网关解决方案。

当时，我们有两个技术演进思路，一个是基于 Tengine 进行优化，一个是基于 Envoy 内核来扩展网关场景，考虑到 Tengine 解决这些场景架构变动太大，Envoy 作为网关的第二选项，能够简单的解决上述痛点，因此，我们选择了 Envoy 内核作为下一代的网关演进方向，而且从 CNCF Ingress Provider 的统计数据来看，Envoy 也是增长最快的，社区接受度高。

在 2020 年 5 月，我们启动了 Envoy Gateway 1.0 的研发，同年成功支撑了双 11 大促，且成为核心重保的业务链路。

Envoy Gateway 1.0 主要是应用于东西向流量的 RPC 互通，其架构部署如下图：

这个时期，我们面对未来演进了 Dubbo3.0 的 Triple 协议，基于 Envoy，演进了网关的服务管理能力，支撑了当年双十一本地生活战役数十万 TPS 的流量洪峰。

Envoy Gateway 2.0（成长期）

随着阿里巴巴上云战役的推进，越来越多的场景找到我们，如云上云下业务互通，由于 Tengine 服务管理弱导致阿里内部大量二层微服务网关需要收敛，因此从业务上我们需要做 Tengine+Envoy 两层网关的演进，承担南北向网关流量。在 2020 年 12 月份我们开始了 2.0 架构的演进，下面以优酷场景为例说明演进过程如下图：

Envoy Gateway 2.0 南北向的架构图如下：

在两层架构中，Envoy 网关更多承担了微服务网关和微服务治理的需求，和 Tengine 流量网关完成了整合。在这个过程中，我们提升了服务治理和高可用能力，并且支撑优酷内部多个二层微服务网关统一，大幅提升性能和运维效率。

2.0 阶段，Envoy Gateway 完成了东西向、南北向全域流量的调度分发，东西向上不仅支持跨业务域的蚂蚁 RPC 互通，更是扩展到了混合云的云上云下的 RPC 互通场景，包括钉钉文档、阿里视频云、达摩院的店小蜜、智慧数字人等，2.0 阶段的业务大图如下（云上云下互通场景，以钉钉为例说明）：

随着 Envoy Gateway 业务的快速铺开，在跟优酷持续合作时大家不约而同的提出了一个问题：Tengine Gateway（承担流量网关角色） + Envoy Gateway（承担微服务网关角色）的两层网关是否可以合并，使用 Envoy Gateway？答案是肯定的，而且我们也合作设计了新的架构图，如下：