阿里巴巴云原生网关三位一体的选择与实践

作者：如葑

审核&校对：彦林、望宸

编辑&排版：酒圆

三位一体是阿里巴巴“自研”、“开源”、“商业化”采用的统一技术体系，希望以开源做内核、结合阿里巴巴内部丰富的业态和业务需求，通过自研进一步打磨软件的性能与高可用性，然后以云上商业化服务的形式，向所有用户开放，同时也会向开源社区持续贡献，最终形成三位一体的旋转飞轮。阿里云云原生团队所支撑的集团业务，分为三层：BaaS、Runtime、Serverless，各层以开源软件为内核，在开源内核上进行集成和扩展，经大规模生产验证后，推向商业化。

开源具有生态、开放的优势，自研具有性能高、可用性强的优势，而商业化则具有易用、安全的优势，基于三位一体的技术体系，可以将开源、自研与商业化都有其各自的优点结合在一起，发挥出最大的优势。

云原生网关在阿里巴巴的发展轨迹

Aliware

1

诞生背景

云原生网关的创建，源于集团内部的“本地生活战役”，该战役始于“支付宝 2020 合作伙伴大会”，在此大会上支付宝宣布升级为数字生活开放平台。该战役的核心技术目标，是实现阿里巴巴业务域与蚂蚁业务域之间 RPC 直接调用，但因阿里巴巴与蚂蚁业务域网络是隔离的，即网络是不通的，很自然想到利用网关来解决此问题。

2

技术选型

利用网关来解决阿里巴巴与蚂蚁跨业务域 RPC 互通问题，首先要对网关做技术选型。

相信大家也都或多或少知道，阿里巴巴开源的反向代理程序 Tengine。Tengine 在阿里内部统一接入网关 AServer 中被使用，我们团队当时就是负责开发运维 AServer 的，同时我们团队也在负责阿里巴巴 Service Mesh 的落地，不管是对 Tengine 还是对 Istio + Envoy 这套架构都比较熟悉。

在选型时，虽然也调研过一些其他的软件，但考虑到网关对性能、可靠性的高要求，在结合我们自身的网关运维经验，决定看看 Tengine 与 Envoy 是否可以满足我们的业务需求，在对比时我们罗列了四个关键要点，其对比如下：

这里提一下“为什么我们认为配置的热更新，是非常重要的”？

Tengine/Nginx 的配置更新需要 reload，reload 需要重启 worker 进程，重启时会引起流量抖动，对长连接影响尤为明显。在网关的集群规模非常大时，更是不能随意的做 reload，这时就会引发一个矛盾点：业务向网关提交配置后，希望能快速验证，但受限于 reload 机制和稳定性要求，无法满足业务快速验证与快速试错的诉求。

如何解决这点呢？

一是采用两层网关，即流量网关 + 业务网关；二是实现网关原生支持配置热更新。除了对比不同方案的优劣势，我们也调研了 Envoy 作为网关在业界的趋势，结论是目前 Envoy 作为 K8s 中的 Ingress Provider 增长最快的事实（Ingress Provider 指 K8s Ingress 规范具体实现，因 K8s Ingress 自身只是规范定义，是 K8s 下外部流量进入集群内部的网关规范定义），我们最终选择了 Envoy 来实现两层网关。

3

发展历程

云原生网关从最初社区的 Istio + Envoy，到经历阿里巴巴内部的自研扩展ÿ