统一多层网关好处多，阿里云云原生 API 网关打造全能型网关

近十年，微服务架构愈发流行，为了在网关层实现服务自动发现、灰度、无损上下线、可观测，用户开始使用 Zuul、Spring Cloud Gateway 这样的微服务网关来满足业务需要。而这几年随着容器化、Serverless 化的落地，像 Higress 这种基于 Envoy 技术，能够和 K8s 深度集成的云原生网关，或者是像 AWS API 和 Lambda 的组合，受到广大开发者的推崇。

回顾完历史再面向未来，新一代网关的技术趋势是什么呢？我们认为有以下三点。第一是以开发者为中心，像 K8s CRD 一样，通过标准化、声明式的配置来管理 API 和路由规则，并将它们和应用代码的变更管理统一到一个 CI/CD 流程中，并提供多版本的灰度能力，提高整个业务迭代的效率。第二点是要顺应当今 AI 时代的需求。一方面网关要作为 AI 应用稳定、高性能、高弹性的流量入口，另一方面要激活更多传统应用的 API，让他们可以便捷地被 AI 应用作为插件调用，实现 API 经济。第三，当 AI 自动化席卷一切之后，安全问题会更加突出。网关在入口层面除了要做流量清洗以及认证鉴权之外，也需要针对 API 接口的漏洞、非法篡改、高频访问、暴力破解，进行更加有效地管理和防护。

首先是提高效率，在应用开发初期，当 API 定义好之后，就可以进行前后端分离并行开发，来缩短迭代周期。另外，应用和系统之间可以通过 API 接口进行解耦，只要 API 的约定不变，各系统就可以进行独立的升级和改造。

第二，企业内外部的能力通过 API 进行暴露，就可以实现快速集成，不需要再重复造轮子，降低组织的总体成本。

第三，各个组织之间通过 API 进行功能和数据互访并做有效管控下，可以激发更多的业务创新。特别是在当下，大模型相当于我们人的大脑，让应用有了认知和推理能力。而 API 就像我们的手脚，让应用可以操作周边的系统，使 AI 应用有了无限的想象空间。通过组合跨界应用产生化学反应，让 AI 能够被越来越多的场景使用。

最后，API 可以让企业构建更广泛的生态。很多大公司把 API 看作是核心资产，像 Twitter 和 SaaS 服务巨头 Salesforce 都是通过 API 开放获得了巨大的流量。而当下炙手可热的 OpenAI，据分析他们的 API 服务年度经常收入达到了 5 亿美元，有三百多万开发者围绕他们的 API 创建 AI 应用，这些都是 API 经济的经典案例。

然而，我们也看到，很多企业和组织并没有对 API 这一核心资产进行很好的管理，在放养式的开发模式下，如果API设计随意而且没有管理工具，会导致版本混乱，上下游对接摩擦不断。我们有一个客户的技术总监反馈，公司可能有上万个API接口，但哪些在线上，哪些是测试，哪些废弃不用根本说不清楚，管理成本太高。对技术人员来说，各参与方使用不同的API设计、测试工具，数据互通难，API定义容易不一致，会极大影响协同效率。

而对于运维同学来说，后端应用架构和业务需求是多样的，就需要部署和维护多种网关组件，监控告警、问题诊断都是很大的工作负担，也很难实现全链路的灰度发布。

最后是线上业务看重的性能和稳定性，多层网关会导致访问链路过长，响应时间变慢，在大流量下，开源自建网关的稳定性和性能堪忧，配置或发布变更会造成业务抖动，最终影响业务发展。

2021 年我们推出了 MSE 网关，它以路由为核心，兼容 K8s Ingress 标准，支持多种服务发现方式，提供丰富的认证鉴权、服务治理和插件能力。

今天，我们进一步将两个产品融合为云原生 API 网关，它 MSE 网关的能力之上，叠加了 API 全生命周期管理功能，帮助用户以统一规范进行 API 设计，并支持多版本迭代、多环境发布。近期我们也会提供 API 开放平台，助力用户进行 API 资产的创建、订阅审批、鉴权及配额管理。另外，网关引擎使用的是阿里云基于 Envoy 开发的 Higress 开源项目，多云或混合云用户在阿里云上用商业化网关，在其他环境可以使用 Higress 自建，我们也在规划 API 的统一管理和发布能力，便于用户保持技术栈和 API 管理过程的统一。

上图是融合后云原生 API 网关的功能大图，白框是已发布功能，黄框是开发中即将推出的功能，灰框是未来 3～6 个月内规划中能力。在基本的服务发现、路由配置、域名环境设置、安全认证、监控告警之外，用户可以进行 API 的设计和发布，并通过开放平台与第三方和开发者进行协同。丰富的策略可以定义在 API 接口或路由不同层面，用户也可以通过官方或自定义插件来进行二次扩展。对于有弹性需求的用户，未来我们也会提供定时和基于指标自动伸缩的能力，不需要在日常预留很多机器资源，从而节省成本。最后，在使用原 API 网关或 MSE 网关的用户可能会问，现有产品的实例怎么办？对于这两个存量产品我们依然会保证商业化的支持，并在未来几个月提供迁移方案协助用户平滑地转移到新的网关实例。

那云原生 API 网关带来的最大价值是什么呢？首先，就是帮助用户进行网关架构的升级。下方左边的图是传统模式下，用户为了部署在容器上的微服务应用构建 Nginx Ingress 和 springcloud gateway 两层网关，前者做流量入口，后者做南北向业务网关，也负责东西向流量。对安全有要求的用户还要在前面加上 WAF。对于 C 端业务，一般通过路由将服务暴露出去，并在之上进行权限和流量管控即可，用户是通过 URL 访问就可以路由到后面的正确的服务上。而对于 B 端业务，需要经过 API 网关产品进行接口细粒度的认证和限流。然后根据服务部署情况，直连后端，或者经由  ingress 流量网关和微服务网关访问后端，这就导致网关的架构和部署非常复杂，徒增性能损耗，出现故障时排查难度也大增。 

新网关将 API 管理、流量网关、微服务网关、安全网关合一，无论后端服务部署在哪个平台，客户业务是 toC 还是 toB，用一套网关技术栈就搞定了，同时它集成了阿里云 WAF 3.0 的数据面，流量直接在网关引擎内清洗，请求链路更短。通过这种高集成的产品，用户不需要多层网关，只需根据业务特点创建对应的实例，并进行一站式地策略设置、观测分析和问题诊断。即使有问题也不需要去摇好几波人来解决。不仅将网关的整体资源成本下降 60% 以上，性能和运维效率还能提升一倍以上。另外，它基于开源项目 Higress 构建，用户无须担心厂商锁定，还能将其他云的网关进行统一纳管。

新网关带来的价值之二就是提升研发效率。当前开发测试同学可能会根据自身工作需要使用各种工具，比如 APIDoc、YAPI、Mockjs 等等，多个系统及工具会造成 API 规范不统一、版本错乱、文档不一致的问题。新网关使不同角色围绕在同一个平台操作，使用同一份 API 定义。它遵循 openapi 规划，支持控制台编辑和 Swagger 文件导入导出，一次 API 定义，测试/预发/生产/灾备 等多个环境可以重复使用。API 各个版本的信息、发布记录也一目了然。我们还提供大语言模型辅助的 API 设计、Mock 数据生成、插件代码开发、请求错误诊断，减轻开发测试同学的负担。

在开发流程上，一般有 API 优先和代码优先两种模式，前者是先设计好 API，然后前后端分离，根据 API 约定独立开发，这时后端服务还没准备好，前端就用 Mock 方式进行验证。然后后端开发完毕在测试环境部署，前后端开始联调及测试，最后在生产环境进行发布。这种模式对于中大型的团队或项目，能减少开发互相等待时间。

下面我们来看下云原生 API 网关适用的场景。首先是服务暴露及流量管控。对于部署于容器上的微服务，可以一键导入 K8s service 或 Nacos 上注册的服务。它兼容 K8s Ingress 标准，也支持 Nginx Ingress 核心注解扩展，提供精细化的路由或 API 管控。访问请求直连容器 Pod IP，并提供限流、预热、灰度等微服务治理能力。

对于 Serverless 应用，云原生 API 网关与函数计算结合，一个函数对应一个 API 快速对外提供服务，并提供强大易用的鉴权和流控能力，搭建完美的 Serverless 计算平台。

另外，它支持 ACK、MSE Nacos，FC，DNS 域名，IP 固定地址等多种服务来源，可用于多种后端，多个集群的统一接入层，流量可以按比例或者按请求内容精准路由到不同集群，不同服务，辅以服务健康检测，fallback 功能，可实现容灾多活等功能。

场景二是通过 API 的生命周期管理，来提升研发效率。云原生 API 网关将 API 设计和运行解耦。设计阶段，用户在控制台输入 API 定义或者导入已有的 Swagger 文件，生成 API 文档和 SDK，大家在同一个约定下进行开发、Mock、联调。利用多环境管理能力，支持不同环境归属于不同的网关实例，从而实现一套 API 定义可以发布到不同的环境，对接不同环境中的后端服务。针对 API 及其接口，支持设置不同的认证和流控策略，实现接口级别的访问控制。通过版本管理功能，可以支持 API 的升级迭代，并提供发布历史列表以便查看和回滚。最后，如果有 API 废弃不用，还可以进行下线的操作。

第三个场景是 AI 应用的流量入口和集成平台。云原生 API 网关支持 AI 应用常见的 SSE 和 WebSocket 协议，配置更新毫秒级生效。如果使用 Ngnix Ingress，每次新增或更新一个路由，就要做 Reload，造成客户端到后端服务的长链接流量受损，用户正和大模型聊着天，出现中断，非常影响体验。使用云原生 API 网关就不会出现这种情况。此外，它支持流式传输，尤其像图片、视频这种多模态，数据量是非常大的。网关通过流式处理能力能减少带宽消耗并降低响应延迟，其良好的内存回收机制可避免 OOM，通过 IP/Cookie 等多维度的 CC 防护能力也可防范黑客构造慢请求进行并发攻击。

另外，我们上线了丰富的 AI 插件。

• AI 代理插件：支持对接多数主流大型模型厂商的协议，并封装了重试、fallback 等功能，从而屏蔽底层差异。当出现被模型服务限流，或访问不稳定的情况，可按需切换模型服务。
• AI 内容审核插件：支持对接阿里云内容安全云服务，可以拦截有害语言、误导信息、歧视性言论、违法违规等内容。
• AI 统计插件：支持统计 Token 吞吐，支持实时生成 Promethus Metrics，在访问日志以及链路追踪的Span中打印相关信息。
• AI 限流插件：支持基于 Token 吞吐进行后端保护式限流，也支持面向调用租户配置精确的调用额度限制。
• AI 开发插件集：提供包含 LLM 结果缓存、提示词装饰等相关能力，可以助力AI应用的开发构建。

接下来，我们将介绍云原生 API 网关的核心优势。

• 常规场景下，相比 Nginx ingress，云原生 API 网关性能高出接近 90%。
• HTTPS 场景下，我们借助软硬一体技术将 TLS 处理卸载到硬件中执行，HTTPS QPS 性能提升了约 112%，RT 下降约 50%。
• 大数据、大流量场景下，GZip 压缩可大幅降低带宽消耗，但同时也很消耗 CPU 资源，通过硬件加速可将压缩/解压缩性能再提升 300%。
• 结合阿里集团内部和商业化大客户的大规模生产经验，我们从操作系统/网络/内核多个维度进行了深度调优，性能又提升了40%。

在稳定性方面，我们在不同的阶段，也对网关进行了高可用的保障。

• 开发态：支持内存异常检测、静态代码分析、混沌测试等。
• 运行态：支持过载保护、本地文件缓存、推空保护。例如，用户的流量突然变大，在没有做限流或者告警提示的情况下，云原生 API 网关会提供过载保护机制。另外，云原生 API 网关是控制面和数据分离的，一旦控制面发生一些小概率的故障问题，我们会通过缓存和推空保护机制，使数据面能够正常的运转，不让业务流量受到损失。同时，云原生 API 网关默认多可用区容灾，
• 变更态：云原生 API 网关在后台有很多巡检任务，能及时发现高风险事件，并提供了大盘监控和报警功能，以及滚动升级、灰度和回滚机制，来保证变更过程的稳定性。

除了稳定性，网关的安全防护能力也是用户选型网关关心较多的因素。在入口层，我们支持双向的 mTLS 认证，并集成了阿里云证书服务，对证书进行轮转更新，防止证书过期没及时更新的情况出现。默认集成并自动开启硬件加速，即将 TLS 证书的验证和卸载转移到硬件中执行，大幅提高 HTTPS 请求的性能。在登录认证上，云原生 API 网关支持 JWT/OIDC/ 自定义鉴权等多种认证登录机制，也提供黑白名单功能。

另外，云原生 API 网关集成了阿里云的 Web 应用防火墙（简称 WAF），将 WAF 的数据面下沉到网关引擎中，由 WAF 来下发防护规则。这样流量就不需要到 WAF 做一次清洗，而是直接在网关上处理，清洗粒度可以控制在路由级别，并且整个流量链路更短，减少性能损耗、降低故障排查难度。此外插件市场提供了多种鉴权和防护插件，用户也可自行编程来扩展安全能力，比如请求/响应的加解密等。最后，云原生 API  网关采用数据面和控制面分离的架构，可以防止控制面的风险外溢到数据面，进一步提升安全能力。

云原生 API 网关能力扩展方面，提供了以下能力：

• 提供了插件市场，网关的二次扩展功能均通过插件形式提供给用户，按需使用。
• 插件采用热更新机制，在沙盒中执行，插件出现问题对网关自身稳定性无影响。
• 借助 Webassembly 特性，用户可以使用多语言编写插件，同时支持 Lua 脚本。
• 网关 Wasm 插件与开源 Envoy 100% 兼容，不存在锁定。
• 提供 WebIDE，可一键拉起开发环境，基于模版快速开发，以及编辑、调试，发布插件。
• 提供基于 LLM 的 AI 助手，根据用户描述自动生成插件代码，降低用户门槛。

大家定义或测试复杂 API 时肯定会有很多繁杂的人工操作，比如在填写 API 响应 body 的 JSON Schema 时，一旦结构复杂非常耗时。在这里用户只需要提供一个示例，我们网关的AI助手就可以自动生成这个 Json schema。而在 mock 的时候，AI 助手又会根据 Schema 自动生成各种各样的数据帮助开发进行验证。我们还在不断探索新的 AI 助手能力，比如 API 接口自动生成，插件代码生成，智能诊断近期都会与大家见面，持续地为开发和运维同学提高工作效率。

一个业务应用正式上线前，需要在开发/测试/预发/生产环境依次部署并完成验证，如果用户在每个环境的网关实例都去配置 API 接口，做版本管理，对接后端服务那就太复杂了。在云原生 API 网关上，可以通过 “环境”允许相同的 API 指向不同的后端服务。用户创建网关后系统自动提供一个默认环境，用户也可以添加新的环境，这里网关实例与环境是 1:N 的关系，比如下图里，开发和测试共用一个实例，预发使用个实例，生产环境用一个实例。每个环境系统都会提供一个二级域名，用户再将自定义的业务域名分别 cname 到二级域名，比如生产使用 mypet.com 这个对外域名，预发和测试分别加上 pre 和 test 的前缀，测试就直接使用开发环境的二级域名。这样 API 设计是一份，发布的时候选择环境和域名，请求流量就会根据 URL 自动通过对应的网关实例访问到正确的后端服务。如果搭配函数计算 FC，它可通过别名屏蔽版本变更，各环境无需重复添加函数。比如开发环境总是指向 LATEST 版本，而测试、预发、生产环境的发布总是指向对应的别名，测试同学要验证的版本从 v1.1.0 切到 v1.1.1，这时只需要更新别名到版本的映射，不需要重新发布 API 更改后端服务，简化操作流程。

云原生 API 网关提供多种服务和流量治理能力，帮助用户在入口层构建业务稳定性防线。

网关可以支持蓝绿发布，并和 MSE 微服务治理结合实现全链路灰度，例如，后端服务发布新版本后，网关可以按照比例，或者请求的 Header 或 Cookie，将特定的流量引到灰度版本，以快速验证。遇到问题再切回基线版本，以避免发版引起的故障。

在服务运行的时候，云原生 API 网关支持无损上下线。当服务提供者的部分节点正在下线时，网关能主动将下线的服务节点剔除掉，将所有的请求流量路由到了正常运行的节点中，实现流量无损。针对发布或扩容场景，Java 应用节点在启动时会有类加载、连接池预热的过程比较耗时间，一开始就承载很大的业务流量可能会被打挂。网关服务管理中的负载均衡策略中可设置预热时间，将流量逐渐增大，给予新节点足够的预热时间保证其稳定性。

最后，我们再来简单介绍云原生 API 网关的两种创建过程。

创建网关实例之后，用户可以将自定义域名绑定到网关的访问地址，然后根据后端服务是否通过 ACK 或 Nacos 来提供服务发现，决定是否要先创建服务来源。有了服务后，开始创建路由，配置限流、重启、超时等策略，并根据业务需要配置认证方式，最后发布路由，并进行测试。

云原生 API 网关提供了两种配置方式，一种是白屏化控制台，一种是 K8s Yaml 来创建路由资源。如果使用后者，用户在网关控制台创建服务来源时选中监听 K8s Ingress 资源，在容器服务侧配置的 Ingress 规则会自动同步到 云原生 API 网关生效。云原生 API 网关兼容 K8s Ingress 规范，支持 Nginx Ingress 核心注解的无缝转换。用户可以像使用 Nginx Ingress 一样在容器服务侧进行路由管理。

如果用户需要进行 API 优先的开发流程，那么需要先设计 API，然后通过 API 接口对外提供服务。

获取《新一代云原生 API 网关开启公测》PPT

点击阅读原文查看本文相关视频分享。