*作者：如葑

阿里巴巴三位一体战略解读之云原生网关开源、自研、商业化，目前云原生网关已正式商业化，旨在为用户提供更可靠的、成本更低、效率更高的符合 K8s Ingress 标准的企业级网关产品，更多详情将在 10 月 26 日下午 15:00 直播间详细为您讲解，详情戳：https://yqh.aliyun.com/live/detail/26605

阿里云云原生三位一体总体战略解读

目前开源软件已经成为企业软件创新发展的主要平台，在此大背景下阿里巴巴云原生提出了三位一体战略，即开源、自研与商业化，希望以开源做内核、结合阿里集团内部业务需求做自研进一步打磨软件的性能与高可用、然后以商业化产品的方式向所有用户开放，同时也会向开源社区持续贡献，最终形成三位一体的旋转飞轮。整体策略简介如下图：

云原生团队业务整体上分为三层：BaaS、Runtime、Serverless，各层以开源软件为内核，并结合阿里业务在开源内核集成商做内部扩展，在经大规模生产验证后推向商业化。

#阿里云三位一体的优势

在三位一体中，开源、自研与商业化都有其各自的侧重点或者特点，先来看一下图示说明：

依托开源作为内核，以阿里巴巴内部庞大且复杂的业务场景为需求驱动自研扩展，在经历大规模生产级验证后推向商业化，同时向开源社区提交适合大众化的自研功能，这就是阿里云三位一体的优势所在。

云原生网关发展轨迹

云原生网关的诞生背景

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

云原生网关的技术选型

利用网关解决阿里巴巴与蚂蚁跨业务域 RPC 互通问题，首先要对网关做技术选型，相信大家也都或多或少知道阿里巴巴开源的反向代理程序 Tengine，Tengine 在阿里内部统一接入网关 AServer 中被使用，我们团队当时就是负责开发运维 AServer 的，同时我们团队也在负责阿里巴巴 Service Mesh 的落地，不管是对 Tengine 还是 Istio + Envoy 这套架构都比较熟悉。在选型时虽然也调研过一些其他的软件，但考虑到网关对性能、可靠性的高要求，在结合我们自身的网关运维经验，决定看看 Tengine 与 Envoy 是否可以满足我们的业务需求，在对比时我们罗列了四个关键要点，其对比如下：

这里提一下“为什么我们认为配置的热更新是非常重要的?”，Tengine/Nginx 的配置更新需要 reload，reload 需要重启 worker 进程，重启时会引起流量抖动，对长连接影响尤为明显。在网关的集群规模非常大时，更是不能随意的做 reload，这时就会引发一个矛盾点：业务向网关提交配置后希望能快速验证、受限于 reload 机制网关考虑到稳定性无法满足业务快速验证与快速试错的诉求。如何解决这点呢？一是采用两层网关，即流量网关 + 业务网关，二是网关原生支持配置热更新。

通过对比初步选型 Envoy 后，我们进一步调研了 Envoy 作为网关在业界的趋势，结论是目前 Envoy 作为 K8s 中的 Ingress Provider 是增长最快的程序（Ingress Provider 指 K8s Ingress 规范具体实现，因 K8s Ingress 自身只是规范定义，是 K8s 下外部流量进入集群内部的网关规范定义），看下图：

云原生网关的发展历程

云原生网关从最初社区的 Istio + Envoy，到经历阿里内部的自研扩展，再到大规模生成验证，最后完成商业化产品的发布，其整个过程介绍如下：

云原生网关三位一体飞轮的形成

在云原生网关正式商业化后，目前云原生网关完成了开源、自研、商业化的完整发展，三位一体的旋转飞轮已经成型。我们也会持续的、坚定的向开源社区贡献自己的力量，例如向 Envoy 社区提交了 Dubbo 支持、云原生消息团队提交了 RocketMQ 支持、以及其他小的 Issue 等。

了解云原生网关三位一体的发展后，接下来我会具体介绍下云原生网关的产品定位及其优势。

云原生网关介绍

传统网关分类及部署模式

行业中通常把网关分为两个大类：流量网关与业务网关，流量网关主要提供全局性的、与后端业务无关的策略配置，例如阿里内部的的统一接入网关 Tengine 就是典型的流量网关；业务网关顾名思义主要提供独立业务域级别的、与后端业务紧耦合策略配置，随着应用架构模式从单体演进到现在的分布式微服务，业务网关也有了新的叫法 - 微服务网关（图示说明如下）。在目前容器技术与 K8s 主导的云原生时代，下一代网关模式依然是这样吗？

下一代网关产品画像

正如上文图中的提问：在容器技术与 K8s 主导的云原生时代，下一代的网关模式仍然会是传统的流量网关与微服务网关两层架构吗？带着这个问题并结合阿里内部沉淀的网关技术与运维经验，我们尝试为下一代网关产品做了产品画像，说明如下：

作为下一代网关产品，我们对其中几个非常核心的要素展开说明下：

• 云原生：要支持标准 K8s Ingress、K8s Gateway API 以及 K8s 服务发现，在云原生时代 K8s 已经成为云 OS，而 K8s 原生集群内外部的网络是隔离的，负责外部流量进入 K8s 集群的规范定义就是 K8s Ingress，K8s Gateway API 是 K8s Ingress 的进一步演化，基于此作为下一代网关势必要支持这种特性。• 拥抱开源：要基于开源生态构建网关，借助开源并助力开源，相信这点大家应该都不陌生。• 高扩展：任何一个网关的能力都不可能覆盖所有的用户诉求，要具备可扩展能力，例如 K8s 的蓬勃发展其开放的扩展能力功不可没。• 服务治理：随着应用架构演进到分布式微服务，网关本身就是为后端业务提供流量调度能力，其支持基本的服务治理能力也就顺其自然了。• 丰富的可观测性：分布式微服务架构带来协同效率提升等益处的同时，对于问题排查及运维带来了更大的挑战，作为流量桥头堡的网关需要具备丰富的可观测数据，帮助用户来定位问题。

云原生网关的定位

基于上述我们对下一代网关的理解，率先在阿里内部推出了云原生网关，并成功在多业务上线部署且经历了双 11 大促的考验，云原生网关图示说明如下：

云原生网关的产品优势

更经济：将流量网关与微服务网关合二为一，用户资源成本直降 50%

在虚拟化时期的微服务架构下，业务通常采用流量网关 + 微服务网关的两层架构，流量网关负责南北向流量调度和安全防护，微服务网关负责东西向流量调度和服务治理，而在容器和 K8s 主导的云原生时代，Ingress 成为 K8s 生态的网关标准，赋予了网关新的使命，使得流量网关 + 微服务网关合二为一成为可能。

此次阿里云 MSE 发布的云原生网关在能力不打折的情况下，将两层网关变为一层，不仅可以节省 50%的资源成本，还可以降低运维及使用成本。部署结构示意图如下，左边为传统网关模式，右图为下一代云原生网关模式。

在微服务的大背景下，丰富的可观测能力也是用户的基础核心诉求，云原生网关基于此默认集成了阿里云应用实时监控服务 ARMS，提供丰富的可观测数据，且该功能对用户免费。

更安全：提供丰富的认证鉴权能力，降低客户的安全接入成本

认证鉴权是客户对网关的刚需，MSE 云原生网关不仅提供常规的 JWT 认证，也提供基于授权开放网络标准 OAuth 2.0 的 OIDC 认证。同时，MSE 云原生网关天然支持阿里云的应用身份服务 IDaaS，帮助客户实现支付宝、淘宝、天猫等的三方认证登陆，并以插件的方式支持来扩展认证鉴权功能，以降低客户的安全接入成本。现有认证鉴权功能如下图：

更统一：网关直连后端服务，打通 Nacos/Eureka/K8s 多种服务来源，并且率先支持 Apache Dubbo3.0 协议

开源已经成为推动软件发展的源动力之一，面向社区标准、开放的商业产品更有生命力。

Envoy 是最受 K8s 社区欢迎的 Ingress 实现之一，正成为云原生时代流量入口的标准技术方案。MSE 云原生网关依托于 Envoy 和 Istio 进行构建，实现了统一的控制面管控，并直连后端服务，支持了 Dubbo3.0、Nacos，打通阿里云容器服务 ACK，自动同步服务注册信息。MSE 云原生网关对 Dubbo 3.0 与 Nacos 的支持，已经率先在钉钉业务中上线，下图是钉钉 Dubbo 3.0 落地的部署简图如下：

更稳定：技术积淀已久，历经 2020 双 11 考验，每秒承载数 10 万笔请求

商用产品并非一朝一夕。

MSE 云原生网关早已在阿里巴巴内部经历千锤百炼。目前已经在支付宝、钉钉、淘宝、天猫、优酷、飞猪、口碑等阿里各业务系统中使用，并经过 2020 双 11 海量请求的考验，大促日可轻松承载每秒数 10 万笔请求，日请求量达到百亿级别。

云原生网关适用场景

云原生网关目前可以涵盖南北向、东西向全业务场景，即可以支持传统的注册中心，例如 Nacos，也可以支持 K8s Service，同时也可以支持传统 ECS，下面通过图示说明如下：

Nginx 网关迁移云原生网关实践案例

优酷 Nginx 网关迁移案例

优酷业务内部有三个利用 Nginx 构建的网关，使用 Lua 脚本做了一些业务扩展，但是随着人员迭代，网关的运维变得越来越困难，主要包括 Lua 脚本维护难、配置变更不实时、多网关运维难以及配置变更 reload 与业务快速迭代的矛盾越来越多，因此我们配合业务一起完成了 Nginx 网关到云原生网关的平滑迁移，为了保障迁移平滑、低成本，在云原生网关中专门针对 Nginx 的 error page 等功能做了扩展。如下图：

看到上面这幅图读者可能问为什么采用了两层网关结构？即 AServer（流量网关） + 业务自建网关，这是因为对于阿里巴巴这种超大流量的业务，采用两层架构，由流量网关统一负责安全防护、全局流量调度成本会更低，不需要每个业务 BU 都做重复的事情，业务自建网关挂在流量网关之后又可以满足业务自身快速迭代的要求；但是对于非超大规模的业务，使用两层架构反而会带来运维复杂度的上升。

Ingress-nginx 迁移方案

在 K8s Ingress Provider 中虽然使用 Envoy 架构的用户增长排在第一位，但不可否认的是目前 Ingress-nginx 仍占据 K8s Ingress Provider 最大的份额，那么云原生网关是否可以兼容 Ingress-nginx 配置，为用户提供低成本甚至零成本的迁移方案呢？带着这个问题我们也做了探索，Ingress-nginx 并没有采用定义新 CRD 的方式来扩展标准 K8s Ingress 能力，而是利用 Annotation 的方式，首先我们分析了 Ingress-nginx 的 Annotation 列表，如下：

依据用户使用度对齐做了优先级排序，其中处于高、中的 Annotation 云原生网关已经支持自动转换，剩余的除了插入代码片段等这些跟 Nginx 内部实现相关的 Annotation 外我们也正在逐步的支持转换，目标就是做到零成本的迁移。转换流程简图如下：

写在最后

云原生网关提供后付费和包年包月两类付费模式，支持杭州、上海、北京、深圳 4 个 region，并会逐步开放其他 region，云原生网关购买链接在这里。

也可钉钉搜索群号 34754806 可加入用户群交流、答疑。