* 作者：如葑

阿里巴巴三位一体策略解读之云原生网关开源、自研、商业化，目前云原生网关已正式商业化，旨在为用户提供更牢靠的、老本更低、效率更高的合乎 K8s Ingress 规范的企业级网关产品，更多详情将在 10 月 26 日下午 15:00 直播间具体为您解说，详情戳：https://yqh.aliyun.com/live/d…

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

目前开源软件曾经成为企业软件翻新倒退的次要平台，在此大背景下阿里巴巴云原生提出了三位一体策略，即开源、自研与商业化，心愿以开源做内核、联合阿里团体外部业务需要做自研进一步打磨软件的性能与高可用、而后以商业化产品的形式向所有用户凋谢，同时也会向开源社区继续奉献，最终造成三位一体的旋转飞轮。整体策略简介如下图：

云原生团队业务整体上分为三层：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 可退出用户群交换、答疑。