阿里巴巴在 Envoy Gateway 的演进历程浅析
作者:耿蕾蕾(如葑):阿里云研发工程师,从 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?答案是肯定的,而且我们也合作设计了新的架构图,如下:
这个方案的演进,让我们看到了网关新的发展态势,尤其在以 K8s 主导的容器化背景下,K8s 集群内外网络的天然隔离性,用户也需要一款兼顾高性能与安全性、以及强大服务治理能力的入口网关,这也为我们走向 3.0 提供了很好的积累。
Envoy Gateway 3.0(成熟期)
随着阿里巴巴大量场景的打磨,Envoy 网关性能、稳定性都获得了很好的发展。2021 年,阿里巴巴开启了中间件三位一体战役,用云产品支撑集团业务,因此我们也将孵化成熟的技术通过 MSE 云原生网关来服务集团。
点击此处,了解 MSE 更多详情
此时,我们通过 Envoy 将流量网关 + 微服务网关合二为一的同时,还通过硬件加速、内核优化等手段,在性能不打折的情况下,持续优化网关的资源部署成本。
技术架构决定技术优势,Envoy 天然的可扩展性,还能将丰富的安全认证和微服务治理能力进行集成,体现了云原生网关高聚合的优势,例如:
- 网关直连业务 PodIP,不经过传统 Cluster IP,RT 更低
- 支持 HTTPS 硬件加速,QPS 提升 80%
- 支持 Wasm 插件市场,插件热加载,满足多语言自定义插件需求
- 自研 Multi-Ingress Controller 组件支持多集群 Ingress 复用同一个网关实例
- 原生兼容 K8s Ingress 规范,且支持 Nginx Ingress 核心功能注解的无缝转化
回馈社区
我们在对 Envoy Gateway 进行演进的过程中,也提了很多社区 issue,包括:dubbo_proxy、wasm、cryptomb 等,未来我们会陆续回馈社区,作出更多贡献,和社区共同打造下一代网关。