云原生网关当道，三大主流厂商如何“竞技”？

王德冲：首先，想请各位针对 UU 跑腿的一个场景来提出自己的解决方案。

李艳林（彦林）：我了解到 UU 跑腿业务是线上线下结合的。因此，相比于一般的纯线上业务，对于稳定性的要求会更高一些。我认为这是可以理解的。随着整个业务逐渐上云，整个行业对可靠性的要求会越来越高，特别是网关作为整个公司的入口，如果出现问题就会带来非常大的损失。我们在做 Higress 的过程中也是更加关注稳定性。我想分享一些想法。

首先，我们的架构和内核使用了 Envoy 和 Istio，它们的好处是将数据面和控制面解耦。这意味着，如果控制面出现问题，数据面不会受到影响。这种分离有效地避免了控制面的安全和稳定性问题对数据面的影响。在内核上，我们使用了一种称为 Wasm 的沙箱扩展机制。如果扩展逻辑代码出现问题，WASM 沙箱会做很好的隔离，不会影响整个网关的主业务。这种设计可以在一定程度上控制整个系统的爆炸半径。

其次，关于 UU 跑腿和阿里巴巴的 IOT 设备，因为在线上线下结合的过程中，这些设备对稳定性有更高的要求，特别是在多端情况下。如果在一般情况下去更新规则、路由或证书插件，连接可能会发生抖动。但由于 Higress 采用了 Envoy 内核，所有规则变更都是热更新的，因此对长连接都是非常友好的，不会抖动。这将显著提高在线业务的连续性和稳定性。

最后，简单介绍一下 Higress。虽然我们在 2022 年 7 月的云栖大会上开源了它，但在阿里云内部，我们已经孵化云原生网关大概三到四年了。最初，它是为了解决阿里电商和蚂蚁之间的互通问题，让 RPC 可以直接调用并使用 GRPC 协议。经过三四年的验证，包括在双十一等大促和成千上万家企业的验证，它现在非常稳定。在这些基础上，Higress 主要关注一些推空保护和其他细节方面的功能。

易久平：首先，我赞同从业务视角出发来讨论技术问题。UU 跑腿这种场景，线上线下结合，对稳定性要求较高，这是所有互联网应用的通用需求。我们通常会关注性能、稳定性和安全性。从 NGINX 的角度来看，我们一直致力于优化数据面、提升性能，这也是 NGINX 长期发展的核心思路。

在性能方面，整个 NGINX 的性能口碑在业界应该是毋庸置疑的。在稳定性方面，我们更关注一些可观测性的能力。当然，商业版本和开源版本在可观测性方面有差异。商业版本的可观测性比开源版本更强，因为我们可以自己定制监控指标，而开源版本只提供基本的仪表盘。

从稳定性角度看，NGINX 流量的出入口监控指标是非常完整和清晰的，无论是面向上游还是下游，可以很容易地定位问题。此外，通过输出日志做分布的链路跟踪，可以解决完整监控的需求。这些监控指标可以很容易地与监控平台集成，实现整个稳定性的保障。

另外，实现自动化的运维和扩缩容也是非常重要的。在云原生体系里面，我们可以通过与 API Server 做集成，使用 Kubernetes 的原生风格做运维配置，这套体系就解决了一些功能性问题。当然，自动化运维也带来了一些问题，比如在动态环境下经常需要扩缩容和发版本，这可能会造成一些问题。不过，商业版本有一些 API 的动态更新能力，可以很好地解决这些问题。在开源版本中，可能还倾向于使用配置文件做 Reload。但是，通过 Ingress Controller 的实现，这个问题已经被解决了，不用再手动配置和 Reload，这个动作已经被自动化实现了。

另外还有一个重要的方面是安全性，这在 NGINX 产品体系中非常受到关注。在云原生体系中，安全通常涉及零信任和 WAAP 应用防护等方面。零信任通常涉及认证、授权、加密和解密等功能，包括 SSL/TLS 证书的单向和双向认证。我们还提供了诊断功能。这些功能都可以通过网关来实现。

此外，我们还可以从 WAAP 的视角来看待安全性问题。NGINX 提供了商业版的 NGINX App Protect 模块，支持 WAF、七层 DDoS 防护，机器人防御和 API 安全。因此，从整个安全体系建设的角度来看，我们可以提供完整的安全能力。综合来看，通过这几个核心能力，我们可以解决 UU 跑腿的性能、稳定性和安全性问题。

温铭：从高可用方面看，我们可以从两个方面进行考虑：架构和功能。在架构方面，我们通常采用 DP（数据平面）和 CP（控制平面）分离的架构，每个 DP 都是无状态的，可以随意地进行扩缩容。如果 CP 宕机了，不会影响 DP 的正常运行，同样，如果 DP 宕机了，也不会影响其他 DP 的正常运行。这种架构能够保证我们的业务具备弹性扩缩容的能力，同时也能够减少客户端的感知。

在功能方面，我们要确保业务具备高可用性，就需要实现一些功能，例如灰度发布、蓝绿发布、探测后端节点健康状况、内置 API 熔断和服务熔断等。从架构和功能两个方面保证业务的高可用性。

此外，我们还需要关注基础组件的质量，这些基础组件是用户看不到的。这些组件包括代码质量、自动化的 CI/CD、端对端测试、混沌测试等。在 APISIX 中，我们内置了大量的测试案例代码，包括单元测试、E2E 测试、混沌测试，以及一些基准测试等，从而保证 APISIX 具备高可用性。

温铭：API 的全生命周期是从 API 的设计开始，然后经过 Mock 和测试环境，最终到达生产环境。在 API 的生命周期中可能会涉及到一些后期的操作，比如 DevPortal，等等。很多网关产品主要在 API 生命周期的中间环节发挥作用。

在这个环节中，网关产品管控着生产环境中的流量。与此同时，它们可能不会像 Postman 那样在开发阶段进行一些前期工作。但是这些网关产品能够通过 API、Swagger 等方式进行集成。至于后期的 DevPortal 部分，它们主要负责 API 的发布和“货币化”。有些 API 网关的厂商会提供这样的服务。

对于 APISIX 来说，我们主要处在生命周期的中间环节，更准确地说是处在中间的底层。因为用户使用 API 网关主要是为了进行互联网业务、金融类业务或者 IOT 业务。我们更关注的是提供底层的基础设施，让大家可以接入 OpenAPI、Swagger 和 Consumer 等，从而让大家可以消费 API。我们还提供一些底层的功能，比如 CV 限流、限速以及计费等等。这就是我们对自己定位，我们为上层的整个生态提供能力，并开放各种标准的接口供大家使用。

李艳林（彦林）：这个话题很有意思，它实际上关乎人们对整个网关未来的定位和趋势判断。从阿里云的角度来看，我们认为客户最关注的是网关的安全问题。事实上，阿里巴巴最初开发网关也是为了解决安全问题，因为我们希望能够通过一个统一的入口来解决安全问题。

以前我在外部也遇到很多客户的应用因为一些问题而被攻击，导致整个风险极大。因此，网关的第一个重要作用就是建立统一的安全防线。Higress 在这方面提供了一些 WAF 插件、认证插件，以及黑白名单机制，可以为企业数字化升级过程中保驾护航。

我认为，无论是国内还是海外，安全都是网关的首要问题。虽然国内许多人关注高可用性，但海外很多人更加注重安全性，特别是像纳斯达克这样的金融机构和中央情报局等机构，它们都在某些公有云上运行，并且非常注重应用安全和基础设施安全。

其次，我想谈谈高可用和稳定性。其实，大家最关心的问题可能是我们的网关稳定性如何、能否帮助我们解决高可用问题。在这方面，Higress 做了一个深度集成，使用阿里云的 Sentinel，在入口提供整体的降级防护能力，以防止业务雪崩。今年我们搞了很多次大促、海外业务等爆发性增长，当流量达到峰值时，建立防护线以防止异常流量打垮整个系统非常重要。特别是对于像 UU 跑腿这样有高峰值场景的业务，保障业务的整体意义更加重大。

过去两年，我在做海外网关竞品分析时发现，最早的架构可能是 SLB+ECS（单体应用架构），包括云服务都是这样的架构。随着微服务的兴起，人们开始使用 API 网关等工具来管理微服务，并将其集成到服务网格体系中。在 Serverless 时代，每个领域都有独立的入口，并且运营数据是独立统计的。这种架构演进也带来了问题。例如，我们今年做了一个标杆客户，需要挂三层网关，相当于在单体到微服务、再到 Kubernetes 的过程中添加了网关层，导致整个访问链路多层网关，最终影响 RT 和运维效率。

我看到 UU 跑腿之前也在处理协议的转换，将 HTTP 转换为 DUBBO，需要加一个网关，这样代价太大了。因此，Higress 定位是支持多种后端服务负载模式的统一，包括单体微服务、Kubernetes 和整个服务器的负载均衡。我们将后端的能力暴露到北向，进行服务发现，并将整个微服务网关、流量网关和安全网关三合一，以便高效地解决业务问题。这样，用户的业务和运维成本，以及资源成本都会大幅降低。我们发现客户非常认可这种做法。

在网关的标准方面，我最近在研究时发现，有三个标准，分别是协议标准（HTTP 加 RESTFUL），文档标准（Swagger），以及路由标准（Kubernetes Ingress / Gateway API）。Kubernetes 推出了路由标准，并通过 Higress 逐渐将路由标准统一起来，这是非常好的事情。此外，开源社区正在推动 Gateway API 的完善，这将进一步统一路由标准。我们希望通过开源标准的建立来推进整个产业的发展。类似于 Linux 标准、MySQL 标准等，网关标准的建立对于未来云计算的发展是至关重要的。未来，我们相信这些需求，包括 API 管理的更多能力，能够更好地跨越云、混合云和多云。这是我思考的一些问题，希望对大家有帮助。

易久平：关于这个事情，NGINX 的思路是不设统一的标准。从我们公司的产品战略来看，我们将场景分成了三个大类。第一类是连接应用程序，这种场景可以定位为传统的面向软负载均衡或反向代理。在此基础上，我们会添加一些安全功能，流量路由等。这种使用场景在整个技术架构下都很有价值，无论是放在数据中心入口还是放在跨 Kubernetes 集群入口，或者是跨技术架构的入口上，都有其存在的价值。

另一个场景是连接 API，我们将这个场景定位在更细的 API 级别。类似于其他 API 网关，我们将其分为数据面和控制面。同时，我们通过一些开发者门户暴露 API，并提供 API 文档，使开发者能够更方便地查看 API 文档。我们还提供了一个门户来管理这些 API 策略，例如限流限速策略，以便将这些策略下发到 API 网关上。

第三个场景是连接 Kubernetes。在云原生体系中，有 Ingress、Gateway API 和 Service Mesh 等场景。我们将这些场景定位为放在 Kubernetes 入口或某个服务入口上。

在这三个场景下，我们会添加安全功能。连接应用程序、连接 API 和连接 Kubernetes，然后在其上叠加安全，是我们产品建设的核心思想。通过这种方式，我们可以实现南北向和东西向流量的调度和安全。

易久平：我的观点是，云原生的核心技术包括容器化、微服务、服务网格、不可变基础设施和管理 API 生命周期。当我们谈论这些技术特点时，云原生网关更多地强调在 Kubernetes 集群的入口。然而在整个云原生体系中，这个过程不是一蹴而就的，存在着新老兼容或者多集群同时存在的情况，需要考虑多集群之间是主备高可用还是多活高可用等。因此，不同的场景对网关的要求是不一样的，因此可能更适合放在 Kubernetes 集群的入口，也可能更适合放在 Kubernetes 集群外部。

我认为，云原生网关无论以什么形式存在于云原生体系中，都需要解决两个问题。首先，它必须与云原生体系融合。其次，它需要能服务好云原生体系。帮助应用实现灵活的扩缩容、可观测性以及快速变更而不影响业务，这是最关键的点。

温铭：我更多的是从生态的角度来看，因为在云原生生态系统中有很多开源项目，比如 CNCF 中就包含了很多开源项目。这些项目能够在云原生中以开源为主体，与各种开源项目进行协作和集成，例如在容器中运行并由 Kubernetes 进行调度。随着企业迁移到公有云、混合云和多云架构，应用程序能够在任何环境中进行部署，实现了边界的模糊化，用户不必再关心底层基础设施。因此，我认为云原生的优势更多地体现在生态系统上，而在功能方面，大家都差不多，无论是可观测性、可扩展性还是其他方面的功能，在大多数情况下都没有太大差异。

温铭：APISIX 经历了几个阶段。最初，我们突出的是性能。接着，我们关注稳定性。而现在，我们更加注重让 APISIX 更加易用。在过去的几年中，APISIX 由全球五六百个开发者共同贡献，迅速发展成为一个顶级开源项目。

APISIX 拥有很多功能和插件，大概有 100 多个插件和各种功能。虽然它功能齐全，但是它距离好用还有很大的差距。因此，我们未来一年的主要目标是让 APISIX 更加易用，让用户可以更轻松进行各种配置和插件的安装和使用，使其成为一个更加顺手的开源项目。

李艳林（彦林）：我们一直参与阿里容器化的架构演进。这个过程中，我们发现云原生网关应该具备四个特点：标准化、高集成、热更新和易扩展。为什么呢？

首先，我们期望代码可以跨云、混合云、私有云和公有云运行，而不受厂商的限制。比如，采用某个厂商的实现时，如果需要切换到另一个厂商，不会因为厂商差异而出现问题。因此，标准化非常重要，它解除了厂商的绑定。Ingress 标准、Gateway API 标准和容器标准等构成了云原生的基础。

在此基础之上，我们强调云原生网关应该具备高集成特点。作为一家以公有云为主的厂商，我们的思路与专有云为主的厂商有所不同。我们提到高集成，是因为我们发现在传统架构中，通常有三层：前端安全网关 WAF、中间流量网关 Nginx 、后端微服务网关 SpringCloud Gateway。例如，我曾遇到一位客户在面对超时问题时需要拉三拨人去查，判断到底是 WAF 超时，还是 Nginx 或 SpringCloud Gateway 超时，这样的部署资源成本很高，而且排查链路效率非常低。

我们认为“合久必分，久必合”。为什么有这个想法？因为我们是从第一性原理出发，阿里内部并没有那么多网关，为什么今天会有三个？其实是为了简化架构，更好地拆分模块和职能，但实际上这不符合用户的利益。用户的实际利益在于成本，包括运维成本和部署成本。因此，我们认为大部分客户可能都需要高集成，包括像阿里、快手、抖音和腾讯等头部厂商。这些大厂也需要拆分，拆分逻辑包括四层和七层，上层使用 SRB，下层可能使用原生网关，上层承担流量，下层负责路由转发。但对于大部分中小客户，一层就足够了。例如，我们的客户已经有数百万连接和几百万 TPS 的数据，但只需要一层就足以应对。这显然降低了整个运维和部署成本。

第三个是热更新。实际上，我们认为 Kubernetes 带来的一个核心变化是业务频繁调度。如果调度频繁，后端发布和规则变更需要快速联动，尤其是在存在长连接和 IOT 设备的情况下，连接的抖动是不可接受的。因此，热更新在确保连接稳定性方面非常必要。随着基础设施和使用场景的不断变化，包括线上线下结合、IOT 设备等，热更新的重要性会越来越突出。

第四个，易扩展性也是重要的一点。我们发现许多客户在网关上都进行了定制，主要包括安全和路由方面的定制，甚至包括存储方面的定制，这是因为不同公司在安全定制方面的策略不同。因此，易扩展性非常重要。我们采用了多语言热更新等机制，使得我们的网关可以更好地支持定制需求。因此，我们认为在未来，这四个能力：易用性、高集成、热更新和易扩展性，将是原生网关必备的。

在今天的原生网关定位和发展过程中，我们围绕着四个关键点展开，以差异化能力为目标。大家都知道，像 APISIX 和 NGINX 这样的巨头拥有非常强的护城河，所以我们需要构建差异化能力，围绕着这四个关键点进行。目前，我们已经完成了整个原生网关的布局，接下来会在易用性和 Gateway API 的标准化上继续探索。

我们的思路与温铭的思路可能有些不同。他们认为 API 网关或云原生网关是基础能力，但我发现云原生网关与 API 网关的区别在于云原生网关多了一个 API 的层次。这是非常重要的，因为有了 API，我们可以利用其自动化测试、调用和安全审计的能力，这对于未来结合人工智能非常重要。我们意识到，如果只做底层的原生网关和基本的路由能力，就无法获取服务和 API 的元数据，这将限制我们在增加更多功能时的扩展能力。因此，我们最近在内部探索一种可能的演进方向。

我们已经完成了阿里巴巴的 Nacos 和 DUBBO 生态的整合，包括在灰度发布方面集成了 Kubernetes OpenKruise，这为我们打造更多的生态扩展奠定了基础。尽管我们目前的插件相对于 NGINX 或 APISIX 来说较少，但我们采用的是整个服务网格的架构，可以复用一套扩展机制来快速构建统一控制东西南北流量的能力。我们正在不断积累这些能力。我们相信通过插件市场，可以一起扩展整个上下游，包括 API 管理和安全等能力，这样就能为客户提供一站式的网关解决方案，而不需要过多地研究其他技术。

李艳林（彦林）：这个话题很有趣。我之前看到一篇文章，讲的是《开源与商业的关系》。我认为，今天的开源与商业关系正处在一个非常重要的阶段，就像中国的软件市场一样。例如，你的手机里有多少款软件是付费的呢？这反映了中国人民对软件付费的态度。如果没有人为软件付费，软件的持续发展就会受到威胁。因此，开源与商业之间的关系非常重要，就像如今社区与企业之间的关系一样。

有点像之前的 360 互联网模式，其中大部分人免费使用，只有 1% 的人付费。这种模式可以使开源与商业相互促进，从而实现持续的发展。如果没有这个正循环，一些项目就很难维持下去，例如早期的 Dubbo 以及现在的 Spring Cloud Netflix ，每公司都有自己的 KPI，如果项目没有持续发展，就会面临失败的风险。今天我们能够在这里交流，说明我们背后有一个力量在支持着我们。但是如果没有这个力量，这些事情就会变得更加困难。

我们需要不断地加强社区投入，促进生态建设。我们都知道，在数字化时代、云时代，开源就是标准。我们通过开源软件构建了整个开源标准，然后借助众人的力量推动它的使用场景和通用性，然后达到最佳状态，这样我们才能把整个领域做大、扩大这个蓄水池。这其实是一种互联网经营模式，当这个蓄水池足够大之后，我们才能继续生存下去。只有这样，我们才能更好地回馈社区。

不过，如今开源的诉求与商业的要求还是有所区别：开源更关注易用性、生态；商业版本则更关心产品的稳定性、安全性、高可用性和兜底服务能力。

阿里巴巴是开源、商业和内部三位一体。我们通过开源软件打磨产品的易用性和生态、和扩展性，而商业上更关注企业级特性，如稳定性和安全性，我们在阿里内部的场景打磨高可用性和高性能。这几个方面是相辅相成的，大家都明白开源到商业、社区到企业的闭环非常重要，这也是我们能够生存下去的关键。

易久平：彦林老师刚才的分享非常到位，NGINX 的整体思路也是如此。目前，我们已经加强了去年提出的开源战略思想，即要扩大开源，包括开源功能和更多控制面、数据面商业能力的开放。我们正在将我们的开源社区扩大，并将源代码管理放到更大众化的代码仓库上，以便让更多人参与其中。公司的定位是希望能够扩大开源社区，为开源社区做出更多的贡献、提高装机量，让更多的人使用和参与，来改善生态。

其他方面，我们希望通过提供企业化能力来减少开源使用的成本，同时提供点对点的商业支持、销售商业产品和提供 SaaS 服务。目前我们的 SaaS 服务可以放在公有云上，也可以用我们自己的分布式云平台。

温铭：APISIX 是一个由 Apache 软件基金会赞助的顶级开源项目。绝大部分功能都是由开源社区贡献的。最初的技术架构和底层算法是由一些开发者创建的。社区驱动了很多插件和生态，以及修复了很多由使用者报告的问题。因此，社区对于 APISIX 的发展和完善做出了很大的贡献。如果你对某个功能感兴趣，比如在使用 Clickhouse 进行日志分析时想要做一些集成，就可以在社区寻求帮助。虽然我们可能不理解这些贡献者为什么会这么做，但是他们为 APISIX 的发展做出了重要的贡献。

对于项目维护者来说，有些功能我们可能不太理解用户的具体使用场景，比如支持 MQTT 或 GraphSQL，因为这些场景在我们的使用中并没有遇到过。但随着用户声音越来越多，维护者们也会意识到这些新需求的存在，从而推动新功能的开发。这也是 APISIX 功能不断增强的原因，即主要是由社区驱动。

商业公司则更多是由商业客户驱动，他们往往面临更大规模、高并发等复杂的情况，发现了开源用户不容易发现的 Bug 或风险，从而对 APISIX 进行优化和改进，我们企业版的 APISEVEN 会提供一些更丰富的企业级的功能。

温铭：数字化转型听起来似乎是一个高大上、高层次的话题，但如果你和企业客户交流得多就会发现，中国企业距离数字化还很远，很多系统之间还没有完全实现良好的对接。

其实数字化就是所有数据能否通过 API 进行查询，而这些 API 是否能够相互连接。我们现在使用的互联网和各种视频软件，甚至我们使用的办公软件，本质上都是通过 API 将数据从一个地方转移到另一个地方，然后再相互传递。对于企业来说也是一样，数字化就是将企业的各个孤立的服务通过 API 等方式连接在一起，从而提高效率。因此，数字化中很重要的一部分就是将不联网的服务变成联网服务，再将联网服务变成相互交换信息、数据的方式，这样才能提高效率。

易久平：我之前查询了一下数字化转型的含义，因为我觉得这个名词对于很多人来说，虽然听过很多次，但并不一定真正理解。一个比较形象的解释是，我们正在从信息化时代转向数字化时代。在信息化时代，我们的生活大部分轨迹还是线下的，只是偶尔通过线上渠道进行协助，完成一些常见的活动，比如购物或就医等。而在数字化时代，我们在线下完成的事情较少，大部分活动发生在线上。在这个背景下，我们对应用的复杂度、API 数量、系统稳定性和安全性的要求更高。我之前举过一个例子，特别是在上海去年封控期间，核酸检测系统崩溃后，人们冒着感染风险在外排队。你会发现，随着数字化转型程度的提高，对系统稳定性和安全性的要求也越来越高。

从网关的角度来看，我们作为连接客户端和服务端的中间载体，作为统一的入口，安全性和稳定性尤为重要。从网关的重要性程度来看，这一点毫无疑问地得到体现。

李艳林（彦林）：大家对数字化的理解大概是这样的：首先有一个网站，其次有一个大盘。不知道大家是否看过在朋友圈中转发的“灵隐寺的大盘”，一般来说，传统公司对数字化的需求可能就是有一个网站和一个大盘；对于已经进行了数字化升级的公司来说，它们需要从传统架构过渡到云原生架构。

第一类用户需要快速构建企业级、高可用、安全的入口，我们可以帮助他们实现这个目标。第二类客户，也是我们目前关注的重点客户，因为他们通常是传统架构，希望升级到微服务和云原生架构。最简单的方法是在前面加一个网关。有了网关，传统的应用可以继续使用传统的负载方式，而微服务可以使用微服务负载方式，这样就能快速进入云原生时代。

那么，如何实现新老系统之间的互联互通呢？云原生网关充当了统一的控制中心，可以控制流量和管理新旧系统之间的互动。举个例子，可以实现上云和下云之间的互通，不同业务域之间的跨域互通，通过网关来快速解决新老系统之间的连接和升级。这样一来，新的 IDC 和老的 IDC 之间可以快速连接和升级，从而加快整个数字化升级和创新的速度。

因为大家都知道，当一个 IT 系统变得越来越复杂时，采用微服务架构可以释放出更大的研发效率红利，尤其在海外更为明显。这也是为什么海外要推崇 Serverless 架构，从微服务走向 Serverless，因为人力成本是最高的，所以要尽可能降低运维和开发成本。所以，对我们来说，这意味着我们可以加快企业的创新速度。

另外一个我最近研究的课题是关于上云和数字化过程的。实际上，它可以分为两个部分：业务数字化和业务智能化。在第一个阶段，我们的云原生网关可以帮助用户快速将单体应用、微服务应用以及整个 Kubernetes 等多种负载快速地将后端服务能力输送到客户端，这是我们的第一个价值所在。

第二个价值在于如何快速将后端的数据能力和 AI 能力输送到客户端。这个问题也非常重要，包括之前提到的 GraphQL 等。在研究中，我发现通过低代码和快速的方式将后端的数据能力快速输出到客户端非常有意义。从业务智能化的升级过程来看，我们的网关可以快速将后端的 AI 能力输送到手机端，这样就可以帮助企业快速将后端能力输出到客户端和生态系统。

提到 API 领域，通过服务的货币化将调用、生态全部整合起来，也具有很大的意义。在海外，这种做法已经得到了很好的发展，而我相信国内未来也会成为趋势。为什么这样判断？因为国外的人力成本较高，所以他们更倾向于使用别人的服务而不是自己开发，而国内则相对较少。但随着中国数字化水平的提升，程序员的工资持续上涨，API 化仍然是未来的趋势，这是第二个可能性，即我们能够帮助企业快速将后端能力输出到客户端。

第三个价值在于网关本身。云原生网关在入口处建立安全和高可用的防线非常重要，因为近年来行业内出现了数据泄漏和稳定性问题，网关作为一个关键位置具有致命的意义。

李艳林 (彦林)：我的判断是这样的，现在正是传统网关向云原生网关迅速发展的爆发期。首先，我们可以看到容器已经成为基础设施的主要架构，而 Kubernetes 通过网关构建了一个标准，这实际上是行业发展的基础。第二点是，从 CNCF 报告和整个行业动态来看，云原生网关和 API 网关在过去三年里增长了一倍以上，每年都在持续增加，增长速度非常快。我最近做分享时仔细数了一下，在 CNCF 里大约有二三十个项目涉及这个领域。在这个领域有这么多的参与者，说明这是一个机会，吸引了许多人涉足。

在这个领域中，我进行了一些分析。大约有 40% 的项目是基于 NGINX 内核构建的，而 35% 的项目是基于 Envoy 内核构建的。可以说，Envoy 与 NGINX 占据了 75% 的网关实现市场份额，这确实是两个主要的主流力量。

温铭：我认为，如果仅从公司业务场景分析的话，构建一个 API 网关并不是很难的事情，不管是基于开源项目还是从头开始开发，门槛都不算高。例如，APISIX 最早版本我们只用了两三个月时间就完成了，它包含了基础组件并能够正常运行。

然而，从只能供自己使用的工具，到真正能够应对数百万 QPS、每天处理数百亿请求、处理数百亿到千亿次 API 调用的工业级可用工具，是一条漫长的路。这其中并不仅仅是技术挑战，更关键的是，是否能够遇到足够多的场景和客户来验证这一过程。因此，APISIX 大概花费了几年时间才逐步稳定下来。如果你看一两年前的 APISIX，经常会遇到 CPU 利用率达到百分之百或者内存溢出等问题，这些问题在 GitHub 的 issue 中也有很多用户提到。但是，通过不断踩坑，APISIX 逐渐变得更加稳定。因此，我认为构建一个轮子并不困难，真正的挑战是将其打造成一个可靠的工业级产品。

我认为真正的挑战可能不是来自技术，可能并非另一个 API 网关，而是其他完全不同的产品将我们这些厂商挤出市场。因此，我们经常需要考虑这些变量来自哪里。比如，现在非常火的 ChatGPT 大模型，我一直在思考它对我们当前从事技术中间件和网关开发的影响，是否会在某一天让用户不再需要我们，而用全新的产品取而代之？

易久平：我也看过一些报道，例如艾瑞咨询在 2021 年关于《人工智能 API 经济》的一篇报道中提到，通过 API 发布基于人工智能的核心能力，包括像 ChatGPT 这样的服务。实际上，很多人都将其作为客户端与服务端进行交互，这种情况下只要有客户端和服务端的存在，API 网关就会有价值。因此，从这个角度来看，我们不太可能被替代。

正如之前彦林分享的，许多网关更多地关注业务场景或部署环境的适配。这导致了一个现象，就是在过去的二十多年中，NGINX 在开源生态方面似乎没有太多进展。尽管有很多人编写了一些扩展模块和功能，但包括官方仓库在内，仍然停留在那个以 HG 开头的域名下。为什么会出现这样的结果呢？实际上，这是有原因的，因为在开发数据面的核心能力时，对稳定性和性能有相当高的要求。如果你没有保护好作为入口的门，就会给应用带来很大的风险，可能会意外引入漏洞（CVE）。

当然，这并不意味着开放社区可以将其扩大为商业社区的借口。但总的来说，这也说明了仍然存在一定的门槛，如果真的要从事相关工作并非那么简单。

另外，从控制面或业务场景的支撑角度来看，这个领域是不断创新的。针对不同的行业、协议和应用可能有不同的要求，例如流媒体协议和各种物联网协议可能不同，因此在这个层面上进行创新，并将其与业务场景相结合是很常见的。在某个垂直领域做一些 API 网关的创新可能会有一定的机会，但这也要看具体情况。

李艳林（彦林）：从整个行业的角度来看，现在的标准正在逐渐建立，但还没有完全稳定下来。目前实践方面相对来说已经比较集中，大约占了 75% 的份额，但还有 35% 是比较分散的长尾部分。我们希望行业标准能够统一，让大家都能达成共识。比如，MySQL、PostgreSQL、Oracle 等数据库在市场上占有较大份额，加上其他一些常见的网关产品，可能占据了 90% 左右的市场份额，这种收敛的趋势对整个产业会有积极的影响。我们需要共同推动这些标准的发展，加快标准的形成。

未来，我认为网关在安全和 Serverless 领域都有巨大的挑战和机遇。首先，对于开发者而言，他们在软件开发过程中首先关注的是研发效率，其次是扩展性，然后是稳定性，最后才是安全性。但实际上，随着数字资产的增大，包括像俄罗斯和乌克兰战争这样的事件，我们会发现各种攻击和防御正在不断增加。这些安全威胁的加大将带来巨大的变数和机遇。例如，能否利用人工智能自动进行攻击和防御，这都是攻防之间的问题。谁能够利用人工智能和算力快速构建防护壁垒？包括阿里云自身在内也在进行相关探索。

其次，将网关发展到极致，实现服务化也是一个有趣的方向。当前的四层网关和云厂商的第二层网关基本上都是基于特定内核构建的。而对于我们的七层网关来说，原生网关应该具备流量付费和弹性调整能力，以适应资源需求的变化。将网关无服务化将会是一个有意义的发展方向。我们一直在对网络进行抽象，从四层到七层再到网关实质上是网络一层层向上抽象，对开发者越来越易用。未来，能否实现网关的无服务化和极致弹性是一个重要的挑战。

目前看来，网关行业处于一个非常有前景的阶段，市场需求强劲，各家企业都在争相进入，并通过共同努力来推动行业的发展。

温铭：我同意彦林之前提到的观点，当前的情况可以描述为百家争鸣，这其实是一个最好的状态。大家都非常重视网关领域，无论是使用方还是开发者，都希望能够做出更好的网关产品。因此，许多开发者、大公司和创业公司都希望在这个领域分一杯羹，我认为这是一个非常好的现象。

关于标准的问题，我对此并不像彦林那样乐观。我认为建立标准是一件比较困难的事情。一旦建立了标准，例如从 NGINX 到 Envoy，很可能不愿意打破现有的标准，更多的是希望能够达成共识，例如大家普遍认可 Gateway API。但要实现从一个 API 网关无痛迁移到另一个 API 网关仍然是比较困难的。

易久平：我认为参与标准的制定是非常重要的，因为在应用场景方面，不论是 Higress 还是 Gateway API，都存在一些不足之处。作为 Kubernetes 集群的入口，它需要满足各种 API 网关的需求。特别是在国内，有一些典型的需求，比如全链路灰度发布。那么我们是否可以将这些需求直接纳入到 Gateway API 的规范中呢？类似这样的场景都可以推动标准的发展。

就像我们看到的情况，包括 NGINX 已经实现了 Ingress Controller，但我们也发现为了支持许多高级功能，用户需要扩展自定义资源（CRD）等，相当于自定义了一些扩展。在这种背景下，对于用户来说，迁移的成本就会增加，因为很多厂商并没有完全按照标准实现他们的网关。这样一来，如果要进行替换，就必须要支持那些 CRD 的功能后才能进行切换。类似这样的情况可能会持续存在。如果有一个相对完整、通用性强、能够支持大多数业务场景的规范被定义出来，那对于开发者和使用者来说是非常有利的，可以促进网关产品的切换，并推动整个网关市场的发展。

总结一下，我认为参与标准制定对于发展网关领域非常重要，因为它可以解决一些现有解决方案的不足，并推动创新和市场发展。

温铭：我认为云原生网关的发展趋势更多是生态系统的健全性和开发者的便利性。大家已经不再仅仅关注 QPS 和功能，因为大家基本都已经采用了基于 Envoy 的解决方案，所以在功能性上差异并不大。

相反，人们越来越关注以下几个方面：首先，它是否真的易于使用、是否确实在混合云或私有云环境下提供了相同的体验；其次，是否能够方便地集成更多的生态系统。作为一个中间件，网关需要连接各种下游终端和协议，并与各种云服务、SaaS 服务、公司内部服务及其他项目连接。所以，能否构建一个强大的生态系统是非常重要的。

易久平：我认为整个网关的发展必须与业务应用形态的变化相符合。我一直在分析网关的发展过程，发现它的演进一直与应用形态的变化相伴随。在当前的云原生体系中，开发者变得更为重要，因为开发者更注重管理自己的 API 和应用。从这个角度来看，开发者习惯于通过扩展和参与来完成很多事情。这与温铭老师的观点类似，我们希望扩大开发生态系统，让人们可以基于这个生态系统进行集成扩展。

从云生态系统角度看，云生态系统一直在发展，不同的技术点正在逐渐形成规范。对于网关来说，它必须首先融入整个云原生生态系统，因此必须实现各种规范，包括监控规范、API 网关规范和部署扩展规范等。其次，要为云原生服务，并支持云原生应用形态的变化，包括从微服务到服务网格，再到未来的无服务器。因此，在各方面不断提升支持是必要的，最终目标是提升用户体验。对于终端用户来说，用户体验好就是要安全、稳定和可靠，这就是所谓的良好体验。

李艳林（彦林）：这块我可以给大家一些建议。首先，未来云原生网关的发展趋势应该朝着标准化、高集成、易扩展和热更新的方向不断加强。我们推测，Ingress 和 Gateway API 可能会成为 API 路由的标准，这个标准可能不会受个人主观意愿的影响。

第二个趋势是，对于一些小中型客户来说，Higress 对于一些简单的 4 层路由和 7 层简单路由可能足够了，但对于一些中大型客户来说，他们可能对于复杂的 API 管理和路由有更多需求，未来可能会朝这个方向发展。我注意到在群里也有人提问，当 API 变得复杂并且规模扩大时，如何进行 API 管理和治理，我们可以在以后讨论这个问题。

第三个趋势是统一东西南北流量。我们采用 Envoy 内核，可以看到东西南北流量的统一加速趋势。无论是从北向进来的流量，还是跨安全域、跨业务域、跨区域的东西向流量，包括 sidecar 之间的流量，因为采用 Envoy 内核，我们在统一东西南北流量方面具有一些优势。当然，我也看到一些尝试将 NGINX 用作 sidecar 内核的设计，包括 APISIX 也在进行这方面的尝试。我认为大家的思路都很好，核心本质是大家都认为统一东西南北流量控制是一个重要的方向。

第四个趋势可能是关于 AI 领域的探索，AI 的入口到底是谁？包括在阿里内部以及与其他合作伙伴进行的一些尝试。未来的 AI 能力和大模型能力都是基于容器作为基础设施进行输出的，对于连接的稳定性、高可用性以及流量防护也有较高的要求。所以，我相信在未来的 AI 探索领域中，探索 AI 的入口将是值得的。

最后，根据 CNCF 的数据，我认为以 NGINX、Envoy 为内核可能是未来原生网关的关键实现。我也相信 Higress 在未来一年会有爆发性增长，加速推动原生网关的认知建立，这只是我大致的判断。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！