简介：三位一体是阿里巴巴“自研”、“开源”、“商业化”采纳的对立技术体系，心愿以开源做内核、联合阿里巴巴外部丰盛的业态和业务需要，通过自研进一步打磨软件的性能与高可用性，最终造成三位一体的旋转飞轮。

作者 | 如葑

三位一体是阿里巴巴“自研”、“开源”、“商业化”采纳的对立技术体系，心愿以开源做内核、联合阿里巴巴外部丰盛的业态和业务需要，通过自研进一步打磨软件的性能与高可用性，而后以云上商业化服务的模式，向所有用户凋谢，同时也会向开源社区继续奉献，最终造成三位一体的旋转飞轮。阿里云云原生团队所撑持的团体业务，分为三层：BaaS、Runtime、Serverless，各层以开源软件为内核，在开源内核上进行集成和扩大，经大规模生产验证后，推向商业化。

开源具备生态、凋谢的劣势，自研具备性能高、可用性强的劣势，而商业化则具备易用、平安的劣势，基于三位一体的技术体系，能够将开源、自研与商业化都有其各自的长处联合在一起，施展出最大的劣势。

云原生网关在阿里巴巴的倒退轨迹

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，到经验阿里巴巴外部的自研扩大，再到大规模生成验证，最初实现商业化产品的公布，其整个过程介绍如下：

这个过程中，咱们也正继续的、动摇的向开源社区奉献本人的力量，例如向 Envoy 社区提交了 Dubbo 反对、RocketMQ 反对，并解决了一些社区 issue 等。

云原生网关为何被称为下一代网关

1、传统网关分类及部署模式

行业中通常把网关分为两个大类：流量网关与业务网关。

流量网关，次要提供全局性的、与后端业务无关的策略配置，例如，阿里外部的的对立接入网关 Tengine 就是典型的流量网关；业务网关，顾名思义次要提供独立业务域级别的、与后端业务紧耦合策略配置。随着利用架构模式从单体演进到当初的散布式微服务，业务网关也有了新的叫法 – 微服务网关（图示阐明如下）。

2、下一代网关应该具备哪些外围因素

在容器技术与 K8s 主导的云原生时代，下一代的网关模式依然会是传统的流量网关与微服务网关的两层架构吗？

带着这个问题，并联合阿里巴巴外部积淀的网关技术与运维教训，咱们尝试来答复下，什么是下一代网关。

咱们对其中几个十分外围的因素开展阐明下：

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

基于以上的剖析和实际，咱们认为，在虚拟化期间的微服务架构下，业务通常采纳流量网关 + 微服务网关的两层架构，流量网关负责南北向流量调度和平安防护，微服务网关负责东西向流量调度和服务治理，而在容器和 K8s 主导的云原生时代，Ingress 成为 K8s 生态的网关规范，赋予了网关新的使命，使得流量网关 + 微服务网关合二为一成为可能。

MSE – 云原生网关的劣势

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

MSE – 云原生网关在能力不打折的状况下，将两层网关变为一层，不仅能够节俭 50% 的资源老本，还能够升高运维及应用老本。部署构造示意图如下，右边为传统网关模式，右图为下一代云原生网关模式。

在微服务的大背景下，丰盛的可观测能力也是用户的根底外围诉求，MSE – 云原生网关基于此默认集成了阿里云利用实时监控服务 ARMS，提供丰盛的可观测数据，且该性能对用户收费。

2、更平安：提供丰盛的认证鉴权能力，升高客户的平安接入老本

认证鉴权是客户对网关的刚需，MSE – 云原生网关不仅提供惯例的 JWT 认证，也提供基于受权凋谢网络规范 OAuth 2.0 的 OIDC 认证。同时，MSE – 云原生网关 人造反对阿里云的利用身份服务  IDaaS 帮忙客户实现支付宝、淘宝、天猫等第三方认证登陆，并以插件的形式反对来扩大认证鉴权性能，以升高客户的平安接入老本。现有认证鉴权性能如下图：

3、更对立：网关直连后端服务，买通 Nacos/Eureka/K8s 多种服务起源，并且率先反对 Apache Dubbo3.0 协定

开源曾经成为推动软件倒退的源能源之一，面向社区规范、凋谢的商业产品更有生命力。

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

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

商用产品并非久而久之。

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

云原生网关目前能够涵盖南北向、东西向全业务场景，即能够反对传统的注册核心，例如 Nacos，也能够反对 K8s Service，同时也能够反对传统 ECS，上面通过图示阐明如下：

Nginx 网关迁徙云原生网关实际案例

1、优酷 Nginx 网关迁徙案例

优酷业务外部有三个利用 Nginx 构建的网关，应用 Lua 脚本做了一些业务扩大，然而随着人员迭代，网关的运维变得越来越艰难，次要包含 Lua 脚本保护难、配置变更不实时、多网关运维难以及配置变更 reload 与业务疾速迭代的矛盾越来越多。因而，咱们配合业务一起实现了 Nginx 网关到云原生网关的平滑迁徙，为了保障迁徙平滑、低成本，在云原生网关中专门针对 Nginx 的 error page 等性能做了扩大。如下图：

看到下面这幅图读者可能问为什么采纳了两层网关构造？即 AServer（流量网关）+ 业务自建网关。

这是因为对于阿里巴巴这种超大流量的业务，采纳两层架构，由流量网关对立负责平安防护、全局流量调度老本会更低，不须要每个业务 BU 都做反复的事件，业务自建网关挂在流量网关之后，又能够满足业务本身疾速迭代的要求；然而对于非超大规模的业务，应用两层架构反而会带来运维复杂度的回升。

2、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 外，咱们也正在逐渐的反对转换，指标就是做到零老本的迁徙。转换流程简图如下：

写在最初

MSE – 云原生网关，旨在为用户提供更牢靠的、老本更低、效率更高的，合乎 K8s Ingress 规范的企业级网关产品，更多公布详情移步直播间观看：https://yqh.aliyun.com/live/detail/26484

MSE – 云原生网关提供后付费和包年包月两类付费模式，反对杭州、上海、北京、深圳 4 个 region，并会逐渐凋谢其余 region。

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。