老牌网关 NGINX 的云原生新故事

云几乎给每项基础设施都带来了变革，网关也不例外。由于各企业技术栈、性能需求、成本预算等不同，企业找到适合自己的网关产品也非易事。另一方面，虽然 NGINX 及其生态已经相对成熟，但随着 Kubernetes Gateway API 的推出，新一轮网关标准定义的争论再次掀起。

我们在 4 月份邀请了网关领域的资深专家，每周一晚 8 点做客《极客有约》直播间，与大家一起聊聊云原生网关的现状与发展趋势。4 月 17 日，我们邀请到了 NGINX 资深架构师易久平，与大家一起聊聊老牌网关 NGINX 如何讲好自己云原生时代的故事。以下内容根据直播内容整理，点击「阅读原文」可直接观看回放内容。

关键收益：

• API 网关发展历史及云原生时代的网关特点

• 当前网关技术路线有哪些

• 企业如何做网关选型

• NGINX 产品演化策略及如何云原生网关需求

易久平：既然我们要讲云原生网关，一定要理解云原生到底是什么。此外，我们可以看下整个 API 网关的发展历程，以及它变化的驱动力到底是什么。

CNCF 对云原生的定义中提到了几个关键的点。首先，强调应用环境的动态性，像公有云、私有云、混合云等新型的动态环境已成为大多数应用的首选；另外，强调在跨多云部署应用时具备非云平台绑定的属性；此外，还强调了弹性扩展、基于自动化手段快速部署和拉起等方面的重要性。

在整个互联网应用大量崛起和企业都在做数字化转型的两大背景下，应用的数量不断增多，复杂性也在变大，因此需要更敏捷地支撑和响应这些变化。云原生技术的发展主要就是在解决这类问题。

谈到 API 网关，我们也知道，API 网关概念并没有一致的定义。我也去查阅了关于 API 网关整个发展历程的资料。

最早是 1995 年的时候，大家谈的是硬负载。那个时候互联网刚刚兴起，应用大都是一些单体的 Web 应用，可能只要有个硬件做负载均衡就好了。

2000 年左右，有一部分小型互联网公司发展起来，这时大家意识到硬负载的成本还是比较高的，因为一些公司希望快速验证业务场景但不投入那么大。这个时候，有些公司，比如 NGINX 等，实现了软负载，主要目的是为了降低成本。这两种负载主要还是基础设施工程师、网络运维或者系统运维在维护。

到了 2005 年左右，互联网应用快速发展，应用越来越多。这个时候，应用交付过程会涉及很多团队，比如交付部署应用要跟安全团队、网络团队或运维团队交流，沟通成本比较高。后来有了一个新的概念，叫应用交付控制器，就是在负载均衡的基础上叠加一些安全能力、SSL 卸载、性能优化、做连接多路复用等，其中包括流量监控，主要是为了解决应用快速交付问题。当时也有一个技术背景：应用已经开始做前后端分离了。结果就是，相比前两个阶段，应用的流量请求数越来越少，但是请求频率会更高。对后端来讲，这个时候它的流量形态已经发生变化，可能有更多的请求到后端，有更多 SSL 卸载的需求。

2010 年以后，我们开始讲 API 网关的概念了。这个时候有大量的企业已经开始做架构转型，比如开始做 SOA 架构。做 SOA 架构的时候，系统之间需要去沟通，需要通过 ESB 这样的组件串联系统。另外，各类单体应用需要对外提供服务能力。这个时候，API 经济已经开始发展。对于企业来讲，API 变成一种资产，也是一种商业模式，需要有统一对外的 API 入口来管理分散在各个部门的能力，并把这些能力用一个通用的方式暴露出来，这就是 API 网关的第一个阶段，可以称之为 1.0 阶段。这以后，网关角色更加偏向于开发或者开发运维。

2015 年左右，API 网关进入 2.0 阶段，此时微服务大规模兴起。当时移动互联网崛起，应用数量越来越多，迭代也越来越频繁，这导致大家希望网关由平台运维或者运维团队搭建，然后交给开发人员快速部署、上线自己的 API。在这个阶段，API 网关多了一些能力，比如跟微服务相关的服务治理、服务发现、认证鉴权、限流限速、灰度发布等。像 Spring Cloud Gateway 就属于这一类网关，Kubernetes Ingress  Controller 严格来讲也属于这一类，他们只是部署场景不一样。

从网关的发展过程可以看出，其演进过程都是跟随着应用技术架构变化发展的，到现在的云原生技术阶段，网关本身需要融入云原生体系，同时作为生态的一部分，需要服务基于云原生技术实现的应用服务。

最后，我们可以推断和总结出，云原生时代的 API 网关除了常规网关需要具备的安全能力、流量调度或控制能力外，还需要具备以下特性：

1） 容器化：支持容器化部署，可部署在容器集群外、集群入口、集群内，作为容器集群入口网关需要实现 Ingress、Gateway API 模型规范；

2） 微服务：支持容器集群的服务发现，服务好容器集群内的微服务；

3） 服务网格：支持容器集群边缘部署，成为服务网格的出入代理网关；

4） 弹性扩展：基于容器的弹性伸缩；

5） 动态应用环境：支持多云部署，实现云平台无关性；

6） 声明式 API：使用声明式接口完成配置运维，并可集成到 CI/CD 流水线实现自动化；

7） 可观测性：可被云原生监控体系集成，实现日志、指标、链路监控；

8） 多角色：DevOps、NetOps、SecOps、AppDev 等不同用户角色可基于 K8s 实现协作，提供自服务能力。

易久平：从网关选型角度，我的观点是没有一种网关可以覆盖所有的场景，因为不同规模的企业组织架构，不同的应用业务架构，不同的应用技术架构，都会对 API 网关的侧重点有所不同。但是，我们可以总结出几个关键的通用点：

• 企业架构：企业内的组织架构决定了应用系统的架构，API 网关的范围是全企业，还是部门；

• 技术架构：API 网关部署的位置与应用场景会直接影响技术选型，位置是在容器集群外、集群边缘或集群内？网关仅服务单 K8s 集群、还是跨多 K8s 集群、或者跨 K8s 集群与老的微服务集群？是否需要 API 管理，对外输出统一的 API 文档和开发者门户？

• 业务场景：业务应用场景对不同的应用协议、性能、安全性等有所区别；

• 性能：API 网关代理的后端服务级别及业务特性是什么？性能是否能满足您的需求？

• 可伸缩性：API 网关是否具备横向伸缩或纵向伸缩的能力？

• 安全性：API 网关需要具备哪些安全能力：零信任（访问控制、认证鉴权、TLS/mTLS、审计日志）、WAAP（WAF、Bot 防护、DDoS 缓解、API 安全）；

• 用户角色：谁负责建设和运维，谁负责使用？

• 成本：总的投入成本是多少，是完全基于开源自建，还是购买企业级 API 网关？

易久平：我认为，技术路线取决于场景。

有的企业可能云原生技术栈发展比较快，已经全面 Kubernetes 化了，有的企业只是部分 Kubernetes 化，甚至有部分企业只是把 Kubernetes 集群当成当虚拟机场景。不同情况对网关的需求完全不一样。

全面 Kubernetes 化的企业，可能只需要关注 Kubernetes 集群的流量入口就好了，这时把网关放在 Kubernetes 集群入口的位置，用 Ingress Controller 或者 Gateway API 就可以实现。有的企业可能没有容器化，或者只是容器化但没有到 Kubernetes 集群部署阶段，这种可能还在依赖 Spring Cloud Gateway 直接部署。

另外，很多时候还需要分层级，因为不同层级的网关处理的场景也不一样的，比如边缘网关需要实现跨集群的负载均衡等。

易久平：它的能力是差不多的，无非就是分流、调度、流量控制、安全防护、流量监控这些，基础能力大部分还是通用的。

易久平：使用场景不同。比如放在边缘位置的话，一定不会做像协议转换那种比较重的动作，否则可能对性能有很大影响。具体场景还是要根据实际情况分析，然后才能构建出符合自己企业特点，或者符合自身长期技术计划规划的网关架构。

易久平：QUIC 协议最早是在 2012 年时由谷歌发起的，当时只是支持 Chrome 浏览器，它的优点是基于 UDP 协议，UDP 协议无需建立连接，也就没有连接的开销问题，通讯效率会更高。它天然支持 TLS，安全性也比较高，这是 QUIC 协议的优点。

但是，QUIC 协议的整个规范制订过程比较漫长。2012 年谷歌发起后，2015 年才开始提交到 IETF 做规范化，第一个正式草案在 2018 年才提出来，正式版本是 2021 年才发布。QUIC 协议的整个标准化过程花了八九年的时间。在上述阶段中，如果适配各种草案的版本，相当于只是实现了一个半成品。

从 NGINX 角度讲，NGINX 在全球有十亿的部署，作为一个通用性的 Web Server，在实现 QUIC 协议过程中会考虑各种稳定性因素。NGINX 当时有个针对 QUIC 协议的独立开发分支，是在 2020 年 3 月份创建的，但实际上到了 2023 年 2 月份才提出正式的预览版。可以看到，从开发到正式的预览版就已经跨了三年的时间。

从 NGINX 支持 QUIC 的开发分支提交历史上可以看到，开发工程师们做了很多代码的变更，可见开发工作量还是很大的，这其中主要的原因有技术层面也有其他层面的因素，主要有：

1） QUIC 协议的规范一直没有定稿，开发工程师需要不断的适配新的规范草案版本，对于一个通用的 Web 服务器 / 负载均衡 /API 网关产品，需要做大量的客户端兼容性测试才能正式发布；

2） 从技术架构上，NGINX 的多进程架构与 QUIC 基于 UDP 协议的无连接有一定的冲突。在处理 TCP 连接时，每个连接会被分配到一个工作进程，但是基于 UDP 的 QUIC 在 Linux 内核层面不会建立端口到进程的映射关系，NGINX 的解决方案是通过实现了一个 eBPF 扩展来集成 SO_RESUSEPORT（允许将多个进程关联到一个端口），将 Connection ID 映射到首先处理的工作进程上（QUIC 在五元组的基础上支持 Connection ID 用于逻辑上保持连接的不中断）；

3） 为了支持各种协议相同的处理能力，例如：长连接处理等，还做了一些 NGINX 内核优化；

4） QUIC 天然就支持 TLS 1.3，NGINX 默认使用 OpenSSL 库，但是 OpenSSL 的老版本并不支持 QUIC，所以 NGINX 只能选择 BoringSSL 库，及 OpenSSL 的 quictls 分支版本；

这几个事情做下来花费的工作量还是很大的，也解释了为什么花那么长时间还没有正式版本支持 QUIC。不过，大概在 5 月左右，公司计划正式发布 QUIC 支持的版本。

易久平：并没有那么简单。这也正面体现出，稳定性、可靠性、安全性对于一个网关组件的重要程度，大家在发布新版本时候是比较谨慎的。

易久平：插件机制不只是在网关层面，在其他的应用里面都有很多的插件。这种模式的核心思想就是实现了一个稳定可扩展的基础平台，一些可有可无或者创新性的功能通过插件的方式扩展，既保证了基础平台的稳定性和健壮性，又保证了一定的扩展性。

这对网关来讲也是一样的。比如我们可以通过 NGINX 技术框架实现一些底层的内核级优化，比如连接、事件机制、安全机制等。但这些都是底层能力，不能解决所有问题。有了这种扩展机制后，它的扩展就不一定受制于官方支持，只要具备这种开发能力的人都可以去做，只是扩展难度不同的问题。

NGINX 目前最主流的扩展机制有两种，一种就是基于 C 语言直接写扩展模块，这种方式可以做更多内核级的优化，当然它的开发难度也更大，需要同时做静态编译、考虑平台兼容性等。

另外一种比较流行的是基于 Lua 的扩展机制。Lua 机制是由 OpenResty 扩展出来的，他当时把 Lua 扩展模块开源出来了。大部分情况都不需要做底层优化，只是需要做流量控制和监控。Lua 的开发难度要低，而且支持动态加载，因此解决了不少扩展问题。

除了 Lua 以外，NGINX 官方也支持 JavaScript 的扩展机制。JavaScript 机制本质上跟 Lua 机制相似，能力上也基本上跟 Lua 扩展机制持平，或者能做得更多。它是由官方实现的，考虑得会更全面。另外，JavaScript 语言的掌握群体要大于 Lua，前端的开发者大都会写 JavaScript，这也是 NGINX 选择用 JavaScript 作为扩展语言的主要原因之一。

易久平：灵活性跟复杂性永远是一个矛盾体。所有使用动态脚本方式扩展功能都会面临着灵活性与管理复杂性的平衡问题，例如：基于脚本的规则引擎、工作流引擎、低代码平台等。NGINX 无论是基于 Lua，还是基于 NJS 扩展也都会面临同样的问题，如何做配置管理、版本控制、回归测试等。在 K8s 这种强调动态性的云原生环境中，更是无法采用传统的文件复制方式维护。但是，好在云原生环境中也强调 Everything as Code 的思想，包括 NGINX 的 conf、Lua、NJS 等都可以当成源码放入 Git 代码仓库中，通过运用 GitOps 思想，以及 Kubernetes 原生的运维配置风格（如：声明式 API、YAML、ConfigMap），把脚本变更纳入 CI/CD 流水线中，再完善回归测试用例和脚本，也能有效管理起来。

易久平：一般来说，每种开发语言都有各自的天然优势领域和劣势领域，在语言选择上我们总是需要从所需要开发的技术组件功能与非功能特点，以及对云原生环境的融入与适应能力出发。

我个人不是某一个语言的忠实粉丝，因为存在即有价值，但是网关类组件作为数据通路，一定是要求高性能、高安全性、高可靠性为首要考虑因素，其次是可扩展性、动态性和敏捷性，最后还要考虑团队的技术栈偏好。

从目前流行的网关组件技术栈来看，NGINX 核心采用 C 语言、Envoy 核心采用 C++、Cloudflare 采用了 Rust、Tyk 和 Traefik 采用 Go、Spring Cloud Gateway 则采用了 Java、Ocelot 采用了.net，可见在语言选择上并没有一家独大。但是细看这几个网关可以简单总结其语言选择逻辑：

1） 微服务框架主导类网关，一般由微服务框架所采用语言决定，例如：Spring Cloud Gateway、Ocelot，更关注于微服务框架的融合能力；

2） PaaS 平台或容器平台主导类网关，一般采用 Go 语言，因为 Kubernetes 大量使用 Go，更关注于平台技术栈一致；

3） 通用型网关，能部署在各种位置的软负载、反向代理、数据中心边缘网关等组件，则通常采用 C、C++、Rust，更关注于性能、安全性、可靠性等。

易久平：“为什么我觉得 NGINX 配置好麻烦？”NGINX 发展确实好多年了，要考虑不同的场景，官方模块大概有 89 个，配置指令将近八百多条，这些配置指令都有不同的上下文，这也是为什么这位观众觉得麻烦了一点。但也可以看出，NGINX 的功能非常多，除了这些官方模块，还有开源模块，扩展的模块功能更多。从这个层面上来讲，灵活性与复杂性永远是并存的。

所谓难度，大家如果掌握的好了，也并没有那么难，这是我个人的观点。我们也有一些通用的配置最佳实践，大家可以参考我们的官方 Blog。

易久平：所有事情都是有利有弊的。从 NGINX 的整个发展历程看，我认为，它的益大于弊，因为正是多进程架构的设计，才造就了现在很好的性能。它可以充分利用 CPU 多核能力达到更高的吞吐量、做到更低的延时，这是它的一个亮点。早期，如果没有多线程模型，就会造成一定的开销问题。

但我们其实也很早就支持了单工作进程下面做多线程，实现了“熊掌鱼翅二者兼得”，既利用了多进程架构去充分利用 CPU 多核处理能力，同时在单工作进程下面也实现了多线程，避免请求无限等待、死锁等问题。

本质上，我认为这不是核心问题，主要还是取决于整个实现过程中的功能架构设计，以及实现的代码的质量问题。

易久平：我个人觉得“云原生网关”是新造出来的一个概念，我更认同 API 网关 2.0 的概念。云原生网关更多指的是 Kubernetes 入口的网关，其现在主流实现有三种形态：一是以 NGINX 或者 NGINX 衍生品为底座的一类网关，它们都实现了 Ingress API 规范，作为容器 Kubernetes 集群入口或者出口的角色存在；二是基于 Envoy 去实现 Envoy Proxy；三是自研的产品。但本质上，他们都实现的是 Kubernetes 的规范，比如 Ingress 或 Gateway API。

易久平：最早的时候， Kubernetes 社区还没有 Ingress 概念，使用 NodePort 直接对外发布，但它只能做四层，也没办法拿到源地址。随着 NodePort 越来越多，大家发现在 Kubernetes 环境也需要一个 API 网关的角色，所以才有了 Ingress。Ingress 本质上是一种规范，但是完整度并不高，解决的业务场景也不全面。作为一个 API 网关，它的能力是缺失的。

这也是为什么当时大家在实现的时候都在定义自己的 CRD，自己扩展 Ingress 模型实现更多生产级的能力。NGINX 也一样，做了很多能力补充。这段时间可以认为是 Gateway 1.0 阶段。

Ingress 一方面是能力不足，另一方面是没有区分多角色，导致边界不清晰。发现这个问题后，Istio 建立了一套 Istio Ingress Gateway 规范，它引入了 Gateway 这个名词，与之前的 Gateway 概念有了衔接。Istio Ingress Gateway 实现了多角色和更多的模型。这个背景下，社区干脆制定了一套新的规范，所谓的 2.0 规范，即 Gateway  API 规范，这个规范解决了刚才提到的 Ingress 的两个问题：多角色协同和能力拓展。2.0 规范支持不同的角色定义不同的资源对象，解决了边界的问题。同时，在吸取了很多生产级的 API Gateway 能力后，它把一些标准 API 网关的能力扩展出来。

当然，规范还是规范，只是定了一个框架，具体怎么实现、实现得好不好，还是由各个厂商去做。NGINX 去年发起了 NGINX  Kubernetes Gateway 产品，实现了 Gateway  API 规范，严格来讲，它实现的是控制面的规范，数据面还是 NGINX 来做。

易久平：这是大家希望努力得到的结果，就是希望这个规范会不断成熟、不断迭代。通过这个规范，厂商的能力会越来越强，网关用户的切换成本会更低，因为所有的配置都是基于标准规范配置的，今天可以用基于 NGINX 的云原生网关，明天也可以改成其他的，因为他的配置不用改。

当一个技术开始百花齐放的时候，一定会出现一个规范，来降低使用者的迁移成本。

易久平：我是这样想的，因为所有的开源厂商最终都要盈利的，因为他也要养活自己的团队。NGINX 一个独立的厂商，也希望通过云平台提供的应用市场来扩大我们的销售渠道。从数据中心、混合云、多云、分布式云的发展，各类公有云平台已经成为非常流行应用运行环境，这也是云原生技术快速发展的主要原因，作为技术组件类产品能跟云厂商集成，依托云平台的应用市场和渠道，可加速我们的商业产品推广。云租户可快速按需拉起 NGINX 实例，就像其他中间件一样，例如：Redis、Kafka 等。这种模式主要有两个问题：

1） 有部分厂商锁定的嫌疑，尽管比完全由云厂商自己提供的网关组件要小，但是对于跨云平台的技术迁移还是有些许成本；

2） 如何与现有的 CI/CD 流水线集成，让基于云应用市场的组件能融入现有技术体系。

易久平：NGINX 在去年的时候已经把整个企业的云原生策略重新梳理过了，总结就是：拥抱开源，拥抱云原生。

首先是拥抱开源。拥抱开源会有几个动作，第一是开源更多的功能，包括数据面的功能和控制面的功能。在控制面上，我们开源了 NGINX Kubernetes  Gateway、NGINX Agent；数据面上，我们开源了 DNS 解析能力及 QUIC 支持能力等。当然还有一些更多的开源的策略还在内部讨论中，大家可以持续关注。

另一个策略就是多场景覆盖。基于云原生的多场景覆盖，我们提出了几点，第一是连接应用，这一点体现了原来 NGINX 强势的地方，就是作为 ADC 或软负载去实现连接应用的能力。第二是连接 API，作为 API 网关来使用。第三是连接 Kubernetes。我们在 Kubernetes 的体系里也实现了不少能力，有 Ingress Controller 实现，有 Kubernetes Gateway API 的 Gateway 实现，也有 Service Mesh 的实现。

基于此，我们还可以叠加安全防护的能力，比如我们有自己的安全防护模块，可以做七层 DDoS 的防御、做机器人防御、做 API 安全等，让整个云原生的安全防护左移，把整个安全防护策略放到 CI/CD，DevSecOps 环节里，这部分能力 NGINX 在持续迭代演进。

易久平：网关系统里最重要的是数据面能力。底层能力决定了上层能力，底层能力不好，上层的那些业务抽象也不一定好。从这点来看，我觉得 NGINX 团队还是有很强的工匠精神，就像我们在实现 QUIC 协议上，做了很多很细致的调优。有了这种精神，它才会持续地去打造更好的数据面能力，通过底层能力再衍生到对云原生体系的支持，例如：可观测的集成、安全的集成、规范的实现等，都是从底层能力衍生出来的上层应用。“底层能力 + 部署环境 + 应用场景”就得出了不同的方案，这是 NGINX 在持续做的。

易久平：我个人觉得，网关的角色从核心能力上来讲，国内国外并没有差异。它的核心能力包括性能、安全性、稳定性、协议支持、限流、限速等各种标准能力，我认为这些是通用的。但是对于国内客户来讲，可能更多会看是否有中文文档、是否有国内的技术支持团队、是否有本地化的技术服务、是否支持国内的云平台、是否支持国产的操作系统和服务器等，这些是国内企业比较关注的点，其实是基于核心能力衍生出来的一些本地化能力。

易久平：从个人的实践经验来说，一般会从“理清概念，识别需求，分步实现”的三部曲开启网关产品的选型和实践，理清概念对于理解产品的核心设计理念和想解决的关键问题有一个清晰的认识，识别需求则是排定自身需要解决的关键问题。对于网关类产品来说，建议按照以下几步进行：

1) 理清概念

网关的核心价值是建立客户端与服务端的桥梁，那么从 5W2H 的方式来分析理解一下网关的概念：

• What：什么是 API 网关 / 流量网关 / 业务网关 / 微服务网关 / 云原生网关 /BFF，跟 ADC 或负载均衡有啥区别？我需要用网关解决什么问题？

• When：什么时候需要增加网关层，什么时候需要修改网关配置？

• Where：网关部署在什么位置？一般来说网关部署在某一个“体系”的边缘，如：数据中心入口、可用区入口、VPC 入口、企业 / 部门入口、微服务集群入口、K8s 集群入口；

• Why：我为什么需要增加这层网关，带来什么价值和缺陷？

• Who：网关由谁来建设，谁来运维，谁来操作使用？

• How：怎么使用网关？自动化配置，还是手动配置？网关自身的高可用、安全性如何保障？如何构建网关，是自建还是用云产品？

• How Many：我们需要部署几层网关？每个网关集群的性能指标是什么？打算投入多少成本？

2) 架构梳理

一定要了解自身的企业组织架构和应用技术架构：

• 企业组织架构：康威定律中说企业的组织架构决定应用架构，网关往往位于各组织的边界，用于衔接不同的组织。

• 应用技术架构：我们需要理清自身应用的主要业务场景与流量场景，及使用了哪些应用协议等。例如：视频直播类应用与电商平台类应用的流量特征肯定有所区别。此外，应用部署的环境是什么、是否为传统微服务架构（Spring Cloud），有无使用 K8s 集群，有无使用多 K8s 集群，多 K8s 集群是主备 / 双活 / 多活高可用，有无历史系统需要兼容集成，是否有统一的 PaaS 平台等都是重点考虑的内容。

3) 场景梳理

网关衔接了应用与客户端，通常来说网关的核心价值点有：

• 隐藏后端应用的内部技术架构，对外提供量身定制的 API，降低复杂度并加速应用发布；

• 为应用提供统一的基础设施层，把应用通用的横切面非功能都卸载到这一层；

• 通过统一的流量监控简化应用故障的排查；

• 具体有哪些场景大类呢？常见的有：

• 应用协议：四层协议（TCP、UDP），七层协议（HTTP/1、HTTP/2、HTTP/3、HTTPS、WebSocket、gRPC、Dubbo、SOAP、MQTT、HLS、RTMP 等）

• 流量路由：基于请求上下文的条件路由、蓝绿部署、灰度发布、A/B 测试、负载均衡、会话保持；

• 流量控制：限流限速、限并发、限带宽、请求 / 响应改写、请求重定向、协议转换、集群级限流限速

• 流量安全：访问控制、认证鉴权、TLS/mTLS、审计日志、WAF、Bot 防御、DDoS 缓解、API 安全、CORS；

• 服务治理：自动服务发现、熔断降级、主动健康检查；

• 服务优化：响应缓存、响应压缩

• 流量可视：指标监控、日志监控、链路监控、安全监控

• API 管理：API 生命周期、版本控制、安全策略、流量策略、API 文档、开发者门户

• 高可用：主备、多活高可用，网关有状态集群（配置同步、会话同步、内存计数器同步）；

• 高性能：网络吞吐、请求吞吐、响应延时、基于加密卡的 SSL 卸载加速、基于 DPDK 的内核优化；

• 可扩展：足够的扩展点、基于脚本的插件扩展能力；

• 自动化运维：声明式 API、动态配置加载、自动化监控采集、容器化部署；

• 国产化支持：国产服务器 / 操作系统的支持、国密算法等；

4) 选型对比

结合自身需求优先级，选定可选网关产品项，并做对比打分选择。

5) 分步上线

网关的上线通常需要非常谨慎，一不小心就是巨大的生产事故，除了需要在测试、预发环境做深入测试外，还需要考虑网关自身的灰度上线，流量灰度引流到新的网关，网关功能逐步开启等。

易久平：这也体现出了网关的重要性，你必须得谨慎。虽然大家在讲云原生，但我理解并不是所有企业都已经完全切换到了所谓的云原生体系里面去，还有一部分历史的系统要兼容，还有多集群要考虑，甚至得考虑多部门的协同，这些问题也是避免不了的。

易久平：NGINX 近期开源了一个 Agent 项目，其可作为 NGINX 的控制面工具使用，通过 Agent 管理 NGINX 实例，可降低开发者门槛。另外，在 Kubernetes 集群里，通过实现 Ingress 与 Gateway API 规范，让网关的配置方式符合云原生标准，开发或运维人员可通过 Kubernetes 原生方式管理和配置网关。底层的实现逻辑是，Ingress Controller 充当了网关控制面的角色，其与 Kubernetes API Server 对接，自动监听配置变化，并将配置转换成 NGINX 原生配置，可能通过配置文件生成方式，也可能调用 NGINX 实例 API 动态修改。Gateway API 或 Service Mesh 本质都是实现了不同的控制面，并与 NGINX 数据面配合简化 NGINX 的使用难度。由于这些项目都是开源的，开发者可基于此实现更多自定义功能。

易久平：网关的竞争我想从来就没有停止过，这块市场很大，玩家也很多。最近几年企业都在做数字化转型，大量的应用与 API 出现，同时应用的技术架构也变的越来越复杂，对于各类网关的需求非常大。我们可以参考 IDC 在 2022 年 10 月发布的《IDC Market Glance: Integration and API Management, 2022》，其中提到 API 管理与集成总潜在市场将以 15.8% 的复合年增长率增长，到 2026 年将达到 159 亿美元的规模。正是因为有很大的市场前景，才有这么多玩家在里面努力去打下自己的一片天地。

除了市场规模，Garner 在 2022 年发表了一份市场报告《Market Guide for API Gateways》，站在企业组织架构及市场分类的角度来定义网关的层级，最外面一层叫边缘网关，再下面一层叫企业网关，企业网关下面有部门级的网关，部门级的网关下面有微服务的网关，还有内嵌网关等。如下图所示：

在不同层级的网关市场，有不同的企业在主导。像边缘网关，可能像 F5 或是传统的 ADC 厂商是比较强的，这类网关对性能、稳定性、安全性要求都比较高。但是像企业级的网关，或者部门级的网关，强调的是整个 API 生命周期管理、API 编排与聚合等这类能力，可能其他的一些厂商在发力。还有基于 API 网关 2.0 阶段的微服务架构入口这类网关，又有不同的厂商在里面角逐。

总体来看，我觉得 Gartner 市场角度的网关分类还算比较合理，基本上通过层级把各个厂商区分出来，只是可能有的厂商并不只在某个纬度发力，而是跨边界的。但大家总体来说，只是各自擅长的领域会有所不同。

易久平：我们官网上有一张图，从 CDN 的内容缓存和接入网关开始，再到前面说的 API 网关，再到 Service Mesh 的 Sidecar，你会发现，NGINX 的产品线很完整，使用场景很多，覆盖面已经很广。

以下是产品分类：

以下是使用场景：

在云原生提体系下我们主要做三件事：

第一，帮助 K8s 建立起高性能、高安全、高可观测性的网络连接能力，包含南北向与东西向。东西向通过 Service Mesh 去解决，南北向通过 Ingress Controller 或者 Gateway  API 解决。那么，安全体现在哪？所有有 NGINX 的地方都可以部署 NGINX 相关的安全模块，其基于零信任与 WAAP 体系实现较为全面的安全能力。

第二，帮助 K8s 安全且高性能的管理集群内与集群外的 API。不管是在 Kubernetes 集群里面还是外面，都能做好高性能的管理，就是在安全高性能的网络问题解决后，再提供 API 管理的能力。

第三，帮助 K8s 提升系统可靠性与韧性，实现跨集群或跨云的伸缩。

总体来讲，我们的整体战略很明确：拥抱开源，拥抱云原生。