MSE | 阿里巴巴云原生网关三位一体的选择与实践阿里云开发者

简介：三位一体是阿里巴巴“自研”、“开源”、“商业化”采用的统一技术体系，希望以开源做内核、结合阿里巴巴内部丰富的业态和业务需求，通过自研进一步打磨软件的性能与高可用性，最终形成三位一体的旋转飞轮。

作者 | 如葑
三位一体是阿里巴巴“自研”、“开源”、“商业化”采用的统一技术体系，希望以开源做内核、结合阿里巴巴内部丰富的业态和业务需求，通过自研进一步打磨软件的性能与高可用性，然后以云上商业化服务的形式，向所有用户开放，同时也会向开源社区持续贡献，最终形成三位一体的旋转飞轮。阿里云云原生团队所支撑的集团业务，分为三层：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，到经历阿里巴巴内部的自研扩展，再到大规模生成验证，最后完成商业化产品的发布，其整个过程介绍如下：
【MSE | 阿里巴巴云原生网关三位一体的选择与实践】

文章图片

这个过程中，我们也正持续的、坚定的向开源社区贡献自己的力量，例如向 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。

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