技术

架构师指南：OpenResty、Kong 与 Apache APISIX 高性能 API 管理深度对比分析

三金

06 Aug 2025 — 55 min read

摘要

在现代数字经济中，高性能、可扩展且可延伸的 API 管理已非奢侈品，而是构建弹性分布式系统的基础要求。本报告对该领域三大领先平台进行详尽的对比分析：OpenResty、Kong 和 Apache APISIX。尽管三者都源于 NGINX 的高性能和 Lua 的灵活性这一共同技术基因，但它们的架构理念、运维模型和战略定位已大相径庭，为决策者呈现了一道需要细致权衡的选择题。

OpenResty 并非一个 API 网关，而是一个功能强大、无固定范式的 Web 平台。它是一个基础工具包，捆绑了增强版的 NGINX 核心、LuaJIT 以及一系列精选模块，旨在打造一个高性能、可编写脚本的应用服务器。它为拥有深厚工程专业知识的团队提供了最大的灵活性，使其能够从零开始构建定制化解决方案，如自定义 WAF、广告技术平台或专用网关。

Kong 是一个成熟的、面向企业的 API 网关，直接构建于 OpenResty 之上。它通过增加一个全面的管理层，包括一个强大的管理 API 和丰富的插件生态系统，将 OpenResty 工具包产品化。其架构传统上以 PostgreSQL 或 Cassandra 数据库作为配置存储，这对于企业 IT 组织而言非常熟悉。凭借其商业产品 Kong Konnect，它提供了一个精良的、全生命周期的 API 管理平台，具备广泛的功能、专业的支持和强大的市场影响力。对于优先考虑企业级功能、成熟商业生态系统和既定运维模式的组织而言，Kong 是战略性选择。

Apache APISIX 是一个 Apache 软件基金会的顶级项目，从设计之初就追求极致性能和云原生敏捷性。虽然同样构建于 NGINX 和 Lua 之上，但它对关键组件进行了重新架构，最引人注目的是使用 etcd 进行配置存储和使用基数树（radix tree）进行路由。这带来了卓越的性能，尤其是在大规模场景下，并实现了毫秒级的配置传播。其“完全开放”的模式、充满活力的社区以及与 Kubernetes 的架构契合度——特别是其创新的无 etcd 的 Ingress 控制器——使其成为性能关键型工作负载和深度投入现代云原生运维范式团队的理想选择。

本报告将从架构、核心功能、扩展性、性能和运维现实等多个维度剖-析这些平台。分析最终将汇总成一个战略决策框架，以指导架构师和技术领导者选择最符合其特定技术要求、运维能力和业务目标的平台。

决策矩阵速览

优先事项	推荐平台	理由
极致性能与敏捷性	Apache APISIX	基于基数树路由和 etcd 的架构，具有卓越的 QPS 和低延迟。专为实时、动态的云原生环境设计。
企业级功能与商业支持	Kong	成熟、功能丰富的平台，拥有全面的商业产品（Konnect）、详尽的文档和庞大的企业客户群。
终极灵活性与定制化构建	OpenResty	一个强大、无固定范式的工具包，供专家团队从基本原则出发构建高度定制化的 Web 平台和网关。

第一部分：NGINX 与 Lua 基础：理解 OpenResty

要理解 Kong 和 Apache APISIX 的架构决策和性能特点，首先必须了解它们的共同祖先和基础技术：OpenResty。OpenResty 并非 Kong 或 APISIX 的直接竞争对手；相反，它是 Kong 赖以构建的强大 Web 平台，也是 APISIX 汲取核心原则的源头。¹ 其架构结合了全球性能最高的 Web 服务器 NGINX 和最快的即时（JIT）编译器之一 LuaJIT，创造出的协同效应定义了这一整类高性能网关。

1.1 NGINX 事件驱动模型：性能引擎

所有这三个平台的性能都从根本上源于 NGINX 的非阻塞、事件驱动架构。³ 与传统的 Web 服务器（如默认 prefork 模式下的 Apache）通常为每个连接分配一个独立进程或线程不同，NGINX 采用一种高效模型，能够在一个小而可预测的内存占用内处理数以万计的并发连接。⁶

该模型建立在两个关键概念之上：

主-工作进程架构 (Master-Worker Architecture)： 一个 NGINX 实例运行一个主进程和一个或多个工作进程。⁵ 主进程负责特权操作，如读取配置、绑定端口和管理工作进程。而工作进程则以非特权用户身份运行，是实际处理客户端连接和请求的进程。这种分离提供了稳定性和安全性。
事件循环 (The Event Loop)： 每个工作进程都运行一个单线程的事件循环。通过使用高效的事件通知机制（如 Linux 上的 epoll 或 BSD 系统上的 kqueue），单个工作进程可以同时管理数千个连接。当新请求到达或现有连接准备好进行读写时，事件通知系统会通知工作进程，然后由其处理该事件。只要工作进程内的任何操作都不阻塞事件循环，它就可以循环处理其所有活动连接，随事件发生而提供服务。该模型在 I/O 密集型工作负载（占绝大多数 Web 流量）方面表现出色，因为它最大限度地减少了与线程管理相关的 CPU 上下文切换和内存开销。

扩展 NGINX 的主要机制是其请求处理流水线，该流水线被划分为一系列不同的阶段。这些阶段，如 rewrite、access、content 和 log，代表了 HTTP 请求生命周期中的不同环节。⁵ 模块可以在这些特定阶段注册处理器，允许开发者以精细的控制来检查、修改、路由或终止请求。OpenResty、Kong 和 APISIX 正是利用这种分阶段执行模型，将其自定义逻辑和 API 管理策略直接注入到 NGINX 请求流中。

1.2 引入 LuaJIT：核心中的高速脚本

虽然 NGINX 的性能极高，但其原生配置语言是声明式的，缺乏执行复杂任务所需的程序逻辑。为了克服这一点，OpenResty 集成了 LuaJIT，这是一个用于 Lua 编程语言的高性能即时编译器。³ 这种集成主要通过

ngx_http_lua_module 实现，这是 OpenResty 的一个核心组件，它将 LuaJIT 虚拟机直接嵌入到每个 NGINX 工作进程中。¹¹

这种结合具有变革性意义。它将 NGINX 从一个相对静态的 Web 服务器和反向代理转变为一个完全可编程的动态应用服务器。³ 开发者可以用 Lua（一种轻量级且易于学习的脚本语言）编写复杂的逻辑，而得益于 LuaJIT 的积极优化，其执行性能接近原生 C 代码。¹³ Lua 解释器和加载的模块在工作进程级别持久存在，确保了即使在高负载下也只有极小的内存占用，因为请求上下文是使用轻量级的 Lua 协程进行隔离的。¹¹ 这种直接在 NGINX 事件循环内运行的高速脚本能力，是 Kong 和 APISIX 中动态功能的技术实现基础。

1.3 OpenResty 作为“Web 平台”：一个精心策划的软件包

将 OpenResty 仅仅视为“NGINX 加 Lua”是一个常见的误解。更准确地说，它是一个“功能完备的 Web 平台”，因为它是一个经过精心策划和集成的软件包。³ 除了增强的 NGINX 核心和 LuaJIT，OpenResty 还包括大量强大的第三方 NGINX C 模块和 Lua 库，其中大部分由 OpenResty 团队自己开发和维护。³ 这个软件包为从与数据库交互到处理 WebSocket 等广泛任务提供了开箱即用的能力。

为了管理其生态系统，OpenResty 提供了自己的包管理器 opm，其“fat” Docker 镜像通常还包括 LuaRocks，这是 Lua 社区的标准包管理器。⁵ 这使得开发者可以轻松地从庞大的 Lua 生态系统中引入额外的库来扩展平台。

认识到对企业级解决方案的需求，OpenResty 团队也提供了基于其开源平台的商业产品。OpenResty Edge 是一个专为大规模 Web 应用和微服务设计的分布式流量管理平台，提供用户友好的图形界面、“无代码”配置解决方案、WAF 功能和动态负载均衡等特性。¹⁷

OpenResty XRay 是一个先进的、非侵入式的可观测性平台，它使用动态追踪技术，以最小的开销分析运行中应用的性能问题，不仅支持 OpenResty，还支持 Python、PHP 和 Java 等其他技术。³

1.4 核心概念：协同套接字 (Cosocket) 与共享字典

基于 OpenResty 的平台能够在不牺牲性能的情况下执行复杂任务，这取决于两个被 Kong 和 APISIX 广泛利用的关键概念。

协同套接字 (Cosockets)： NGINX 事件模型的性能依赖于永不阻塞事件循环。如果一个 Lua 脚本对数据库进行传统的、阻塞式的网络调用，整个工作进程将会冻结，直到调用完成才能处理任何其他请求。Cosocket API 通过向 Lua 暴露 NGINX 的非阻塞 I/O 能力解决了这个问题。³ 当脚本发起一个 cosocket 操作（例如，对 MySQL 或 Redis 服务器的查询）时，它会将控制权交还给 NGINX 调度器。工作进程此时可以自由处理其他事件。一旦网络操作完成，NGINX 会唤醒相应的 Lua 协程，使其从中断处继续执行。这使得开发者可以用同步风格的编程逻辑，实现底层 100% 非阻塞的操作，这对于维持高吞吐量至关重要。¹¹
共享字典 (lua_shared_dict)： 由于 NGINX 的工作进程是独立的进程，它们默认不共享内存。这给实现需要在单个服务器节点上所有请求间共享状态的功能（如速率限制计数器或缓存）带来了挑战。lua_shared_dict 指令通过创建一个可供同一节点上所有工作进程访问的共享内存区域来解决这个问题。⁸ Lua 脚本随后可以使用原子 API 对该字典进行读写，为跨进程通信和状态管理提供了一种高性能机制。²¹ 这个特性是 Kong 和 APISIX 中实现许多有状态插件的基石。

构建于 NGINX 和 Lua 基础之上的决定是一个战略性选择，它从一开始就赋予了像 Kong 和 APISIX 这样的平台世界级的 I/O 性能。它们继承了一个经受住海量互联网流量考验的引擎。然而，这种继承并非没有代价。它们也受限于 NGINX 请求处理生命周期的约束以及每个工作进程内 Lua 上下文的单线程特性。事件循环的效率取决于永不阻塞。因此，在工作进程内直接执行 CPU 密集型或长时间运行的同步操作会“饿死”事件循环，从而降低所有并发请求的性能。这一基本特性解释了为什么 Kong 和 APISIX 都战略性地推出多语言插件生态系统，以便在更合适、通常是隔离的环境中运行复杂逻辑——本报告稍后将探讨这一主题。本质上，OpenResty 提供了一个强大但底层的工具包。Kong 和 APISIX 则将这个工具包产品化，在其之上构建了用户友好、API 驱动的管理层。它们之间的关键区别在于如何架构和实现那个管理层。

第二部分：架构深度剖析：Kong 与 APISIX

尽管 Kong 和 Apache APISIX 共享一个基于 NGINX 和 Lua 的共同高性能基础，但它们的架构理念却大相径庭。这些设计上的差异，特别是在配置存储和部署模型方面，对它们的性能、运维复杂性以及对不同环境的适用性产生了深远的影响。

2.1 Kong：面向企业的网关

Kong 作为首批将 OpenResty 技术栈产品化的主要开源 API 网关之一，旨在为管理微服务流量提供一个健壮、可扩展且对开发者友好的平台。

2.1.1 架构理念：构建于 OpenResty 之上

Kong 的架构是 OpenResty 的直接扩展。它利用 OpenResty 软件包作为其核心引擎，使用其强大的 Lua 脚本能力来实现大量的 API 管理功能。¹ Kong 的主要价值主张在于它在该引擎之上构建的抽象层。Kong 不要求开发者编写底层的 NGINX 配置文件和 Lua 脚本，而是暴露了一个全面的 RESTful Admin API，允许动态配置所有网关实体，如服务、路由和插件。¹ Kong Inc. 也是底层生态系统的积极贡献者，开发并向 OpenResty 提交补丁以增强核心平台，这突显了两个项目之间深厚的共生关系。¹³

2.1.2 控制平面与数据平面：部署拓扑

为了满足从简单部署到大规模、全球分布式系统的不同运维需求，Kong 提供了三种主要的部署拓扑 ¹：

传统模式 (Traditional Mode)： 这是最简单也是最初的部署模型。在传统模式下，每个 Kong 节点同时充当控制平面（CP）和数据平面（DP）。每个节点直接连接到中央数据库以获取其配置，并且也可以通过其 Admin API 接受管理变更。虽然设置简单，但该模型存在缺点。在同时服务公共流量的每个节点上暴露 Admin API 可能存在安全风险。此外，如果一个节点还在运行图形化的 Kong Manager（企业版功能），用于分析的资源密集型计算可能会影响同一节点上代理流量的数据平面的性能。²³
混合模式 (Hybrid Mode)： 这是生产和大规模部署的推荐架构。混合模式将控制平面和数据平面的角色解耦。一小组 CP 节点管理配置并与数据库通信。这些 CP 随后将配置更新推送到 DP 节点集群。DP 仅负责代理流量，并从 CP 接收配置，将其存储在内存中。该模型在安全性和可扩展性方面提供了显著优势。DP 可以部署在不同的地理区域或网络中，无需直接访问中央数据库，从而减少了延迟和攻击面。一个被攻破的 DP 不会暴露中央配置，并且 DP 的可用性与数据库的即时可用性无关。¹ 这个架构是 Kong 的 SaaS 产品 Kong Konnect 的基础，其中 Kong 在云端管理控制平面，客户可以在自己的环境中部署数据平面。²³
无数据库模式 (DB-less Mode)： 在此模式下，Kong 运行时没有任何数据库依赖。所有配置都在一个声明式的 YAML 或 JSON 文件中定义，Kong 在启动时将其加载到内存中。¹ 该模式非常适合现代自动化和 GitOps 工作流。配置文件成为唯一的真实来源，可以在 Git 仓库中进行版本控制，并通过 CI/CD 流水线自动应用。这消除了管理数据库集群的运维开销，并确保网关的配置始终处于已知、可复现的状态。²³

2.1.3 中央数据存储：PostgreSQL/Cassandra 的角色与影响

在其传统和混合部署模式中，Kong 的架构围绕一个外部数据存储展开，支持 PostgreSQL（关系型数据库）或 Apache Cassandra（NoSQL 数据库）。¹ 该数据库作为所有网关配置（包括服务、路由、插件和消费者）的唯一真实来源。

这一设计选择有几个重要影响。对于许多企业 IT 部门来说，管理像 PostgreSQL 这样的集群关系型数据库是一项众所周知且熟悉的运维任务，这使得采用 Kong 相对直接。²⁵ 然而，这种依赖引入了一个关键的依赖项。数据库本身必须实现高可用，通常通过集群和复制来实现，这给整个系统增加了显著的运维复杂性和成本。²⁰ 在传统部署中，数据库的故障会影响整个网关的功能和重新配置能力。²⁰ 配置变更被写入数据库，然后由 Kong 节点轮询，这些节点将配置缓存在内存中。这种轮询机制在配置变更发生和它在所有数据平面上生效之间引入了延迟，这个延迟可能在几秒钟的量级。²⁰

2.1.4 配置管理：Admin API 和声明式配置 (decK)

Kong 的配置主要通过其功能强大且全面的 RESTful Admin API 进行管理，该 API 通常监听 8001 端口。¹ 该 API 提供了对网关各个方面的命令式、程序化控制，允许对配置进行动态、实时的更改，而无需重启服务器。

对于实践基础设施即代码（IaC）的团队，Kong 提供了一个名为 decK 的专用命令行工具。¹³

decK 促进了声明式的配置管理方法。它允许操作员在 YAML 或 JSON 文件中定义网关的整个状态。然后，该工具可用于“比较”文件中期望的状态与运行中 Kong 集群的实际状态，并通过 Admin API 应用必要的更改，使集群与定义保持一致。这使得 GitOps 工作流成为可能，其中保存声明式配置文件的 Git 仓库成为网关状态的唯一真实来源。

2.2 Apache APISIX：云原生竞争者

Apache APISIX 是 Apache 软件基金会的顶级项目，从诞生之日起就明确专注于成为一个完全动态、高性能和云原生的 API 网关。虽然它共享相同的 NGINX/Lua 基础，但它做出了根本不同的架构选择。

2.2.1 架构理念：对 NGINX 核心的全新诠释

APISIX 构建于与 OpenResty 相同的核心组件——NGINX 和 LuaJIT——之上，但它采取了更为精细的方法。APISIX 并未使用整个 OpenResty 软件包，而是利用 NGINX 高度优化的网络库，但完全用自己高性能、完全动态的实现替换了 NGINX 原生的静态配置加载和请求路由机制。² 其核心设计理念是“云原生”和“完全动态”，意味着网关的几乎每个方面，从路由到插件，都可以在不重载或重启的情况下即时更改，且变更近乎实时地传播。³¹

2.2.2 控制平面与数据平面：部署拓扑

APISIX 通过一组类似的拓扑结构反映了 Kong 的部署灵活性，尽管底层技术和术语有所不同 ³⁵：

传统模式 (Traditional Mode)： 在此模式下，单个 APISIX 实例同时充当控制平面和数据平面。它与外部的 etcd 集群通信以存储和检索其配置。³⁵ 该实例既处理代理数据流量，也提供用于配置更改的 Admin API。
解耦模式 (Decoupled Mode)： 类似于 Kong 的混合模式，此拓扑分离了控制平面和数据平面的角色。数据平面实例仅负责代理流量。它们与 etcd 集群保持持久的监视（watch）连接以获取配置更改。控制平面实例暴露 Admin API，通过它进行的任何更改都会写入 etcd，然后 etcd 通知数据平面。这种分离增强了安全性，并允许数据和控制平面独立扩展。³⁵
独立模式 (Standalone Mode)： 类似于 Kong 的无数据库模式，独立模式完全消除了对外部 etcd 集群的依赖。APISIX 在启动时从本地的 apisix.yaml 文件加载其全部配置。³⁵ 然后它会监视此文件的更改，并在文件更新时热重载内存中的配置。此模式是 Kubernetes 环境的首选部署方法，特别是在使用 APISIX Ingress 控制器时，因为它与基于声明式、GitOps 的管理工作流完美契合。³⁶

2.2.3 etcd 配置中心：动态实时同步的典范

将 APISIX 与 Kong 区分开来的最重要架构选择是其使用 etcd 作为配置中心。²⁵

etcd 是一个分布式的、一致性的键值存储，是许多云原生系统的核心组件，最著名的是 Kubernetes，它在其中作为整个集群状态的主数据库。

这一选择具有深远的性能影响。APISIX 不是周期性地轮询数据库以获取更改，而是利用 etcd 的 watch 机制。每个 APISIX 数据平面节点与 etcd 集群建立一个长连接，并订阅相关配置键的更改。当管理员通过 Admin API 更新路由或插件时，更改被写入 etcd，etcd 随后立即向所有订阅的 APISIX 节点推送通知。这使得配置更改能够以毫秒级的延迟在全球集群中传播，与基于轮询的系统中固有的数秒延迟形成鲜明对比。²⁰

虽然 etcd 提供了卓越的性能和可靠性，但管理一个高可用的 etcd 集群也带来了其自身的运维开销。⁴⁰ 这曾是采纳的一个公认障碍，特别是在 Kubernetes 环境中，为网关设置一个独立的

etcd 集群感觉是多余的。这个挑战直接催生了无 etcd 的 APISIX Ingress 控制器的创新，该控制器在内部模拟 etcd API，提供了相同的实时优势，而无需外部依赖。⁴²

2.2.4 配置管理：Admin API 和声明式 YAML

与 Kong 类似，APISIX 提供了一个功能齐全的 RESTful Admin API 用于命令式配置管理。³³ 在独立模式下，

apisix.yaml 文件作为声明式的真实来源。该文件支持使用环境变量进行配置模板化，从而允许在容器化环境中进行动态设置。³⁶ 高性能数据平面和声明式、基于文件的配置模型的结合，使 APISIX 非常适合自动化、高速度的部署流水线。

配置存储的选择——Kong 的传统数据库与 APISIX 的 etcd 键值存储——是区分这两个平台的最重要架构决策。它是它们不同性能剖面、运维模型以及在各种技术生态系统中“原生感”的根本原因。Kong 以数据库为中心的模型天然适合拥有深厚 PostgreSQL 等集群数据库管理经验的传统企业 IT 组织。这些概念是熟悉的，运维模式是成熟的。相比之下，APISIX 以 etcd 为中心的模型与 Kubernetes 原生环境完美匹配，在这些环境中，etcd 已经是一个核心、被充分理解的组件，SRE 团队也擅长管理它。最初在 Kubernetes 环境中为 APISIX 要求一个独立的 etcd 集群所带来的“阻抗失配”是一个重大的运维障碍。无 etcd 的 Ingress 控制器的开发是针对此问题的直接而有效的解决方案，极大地简化了其在目标生态系统中的部署。⁴² 这种架构上的分歧也决定了每个平台的高可用性策略。对于 Kong，高可用性需要一个集群化的数据库，前面是多个无状态的 Kong 节点。¹ 对于 APISIX，高可用性需要一个集群化的

etcd，前面是多个无状态的 APISIX 节点。⁴⁰ 运维负担从数据库管理员转移到了

etcd 或 Kubernetes 管理员身上。两个平台都朝着提供声明式、基于文件的“无数据库”或“独立”模式的演进，代表了在运维理念上的明显趋同，这是由 GitOps 原则的广泛采用所驱动的，即使它们的底层技术仍然不同。

第三部分：核心能力对决：功能分析

尽管 Kong 和 APISIX 都提供了一套全面的 API 网关功能，但仔细审视会发现它们在底层实现、性能特征以及开源产品理念上存在显著差异。本节将直接比较它们在路由、安全、流量控制以及新兴的 AI 网关功能等核心能力。

3.1 动态路由与负载均衡

API 网关的主要功能是智能地将传入请求路由到正确的上游服务。路由机制的效率对网关的整体性能至关重要，尤其是当服务和路由的数量增长到数千个时。

Kong 的方法： Kong 的路由引擎被描述为使用遍历搜索方法。²⁰ 这意味着对于一个给定的请求，Kong 可能需要遍历其配置的路由列表来找到与请求属性（主机、路径、方法等）匹配的路由。虽然对于中等数量的路由非常有效，但这种方法在非常大的规模下可能会导致性能下降。随着路由列表的增长，找到匹配所需的时间可能会增加，从而可能影响延迟。²⁰

APISIX 的方法： 相比之下，APISIX 在设计时就将大规模路由作为首要考虑因素。它采用基数树（也称为压缩前缀树或 trie）作为其核心路由数据结构。³⁹ 基数树对于基于前缀的匹配（这是网关中 URI 路径和主机名最常见的匹配类型）进行了高度优化。这种数据结构使得 APISIX 匹配路由的查找时间在很大程度上与系统中的路由总数无关。时间复杂度与被匹配的 URI 长度成正比，而不是与配置的路由数量成正比。这一架构选择是 APISIX 在涉及大量路由的基准测试中性能优越的关键原因。⁴⁴

高级场景： 两个平台都为复杂的流量管理策略提供了丰富的功能。它们支持金丝雀发布、蓝绿部署以及基于各种请求属性（如头部或参数）的细粒度流量切分的动态配置。³⁰ 主要区别不在于这些功能的可用性，而在于它们应用的性能和实时性，这取决于前一节讨论的配置传播机制。与 Kong 的基于轮询的模型相比，APISIX 的毫秒级更新使得流量切换更加敏捷和响应迅速。

3.2 安全与认证

保护 API 是任何网关的基石，两个平台都提供了广泛的插件来处理认证和授权。

Kong 和 APISIX 都为最常见的认证标准提供了健壮的、生产就绪的插件，包括：

密钥认证 (Key Authentication)： key-auth ³⁰
基本认证 (Basic Authentication)： basic-auth ³⁰
JWT (JSON Web Token)： jwt-auth ²⁵
OAuth 2.0： 两个平台都有插件来验证 OAuth 2.0 令牌，充当资源服务器的强制执行点。²⁵
OpenID Connect (OIDC)： 两者都可以与外部身份提供商（IdP）如 Keycloak、Okta 或 Auth0 集成，作为 OIDC 依赖方来验证身份令牌。²⁵

除了这些标准之外，两个平台还通过插件提供了各种其他安全功能，例如 IP 地址白名单和黑名单、CSRF（跨站请求伪造）保护，以及与外部授权系统如 Open Policy Agent (OPA) 的集成。¹⁸ Kong 将其许多高级安全功能和集成定位为其企业版产品的一部分 ²⁵，而 APISIX 则在其开源发行版中包含了非常广泛的安全插件。³³

3.3 流量控制与可观测性

除了路由和安全，网关还负责保护上游服务并提供对流量模式的可见性。

流量控制： 两个平台都提供了一套强大的工具用于流量整形和弹性：

速率限制 (Rate Limiting)： 两者都提供复杂的速率限制插件，可以基于各种键（消费者、IP 地址、服务等）控制流量，并使用不同的算法（例如，固定窗口、漏桶）。APISIX 提供了 limit-req、limit-count 和 limit-concurrency 插件。³³ Kong 提供了类似的功能，包括使用需要数据库的cluster 策略进行速率限制的能力。²³
请求/响应转换 (Request/Response Transformation)： 两者都可以动态修改头部、主体和查询参数，这对于与遗留服务集成或用额外数据丰富请求非常有用。¹
熔断 (Circuit Breaking)： 两个平台都实现了熔断模式，以自动检测和隔离发生故障的上游服务，防止级联失败并提高整体系统弹性。³³

可观测性 (Observability)： 现代网关必须与现代可观测性技术栈无缝集成。Kong 和 APISIX 在这方面都表现出色。它们可以以 Prometheus 格式暴露大量指标用于监控和警报。¹ 它们还支持将日志和分布式追踪推送到各种后端，包括与 OpenTelemetry、Datadog、Apache SkyWalking 和 Zipkin 的集成，从而提供对 API 性能和行为的深度可见性。¹

3.4 AI 网关：LLM 和 AI 流量的新兴用例

一个新的重要竞争前沿是“AI 网关”的出现。随着组织越来越多地将大型语言模型（LLM）和其他 AI 服务集成到其应用中，它们面临着传统 API 网关未曾设计来处理的一系列新挑战。Kong 和 APISIX 都在迅速发展以满足这些需求。³⁰

正在引入的特定 AI 网关功能包括：

基于令牌的速率限制： LLM 的使用通常按令牌计费，而不是按请求计费。AI 网关正在引入能够解析请求体以计算令牌并根据令牌消耗强制执行限制的插件。
提示词工程与转换： 正在开发用于在发送到 LLM 之前修改、模板化或保护提示词的插件，以确保合规性、安全性和一致性。
多 LLM 负载均衡与故障回退： 随着组织使用多个 LLM 提供商（如 OpenAI、Anthropic、Google）以优化成本和提高弹性，网关可以跨它们进行请求的负载均衡，并在一个提供商失败时提供自动回退。
凭证管理： 安全地存储和注入用于各种后端 AI 服务的不同 API 密钥。
AI 的可观测性： 提供关于令牌数量、延迟（包括首个令牌时间）以及与 LLM 调用相关的成本的详细日志和指标。
MCP (模型即服务) 网关： APISIX 引入了一个插件，用于将基于标准输入输出（stdio）的 MCP 服务器桥接到可扩展的 HTTP SSE 服务，从而方便了自托管模型的部署。³³

这种演变表明，这些平台并非静止不变，而是在积极适应新的技术范式，将自己定位为所有类型服务间通信的中央控制点，包括日益重要的 AI 相关流量。

虽然安全和流量控制的高级功能列表可能看起来相似，但它们的实现细节和开源策略揭示了理念上的分歧。APISIX 的架构选择，如用于路由的基数树，使其具有可证明的性能优势，尤其是在复杂性和规模增加时。²⁰ 此外，它们的开源模式存在明显差异。APISIX 作为一个 Apache 项目，遵循将其核心、仪表盘和大量插件完全开源、毫无保留的理念。⁵¹ 而 Kong 虽然建立在强大的开源核心之上，但遵循的是更传统的“开放核心”商业模式。许多高级功能、企业级集成和精美的用户界面（如 Kong Manager）都保留给其商业订阅用户。³⁰ 这种差异直接影响了总拥有成本和潜在采用者的评估过程。使用 APISIX，组织可以免费访问更广泛的功能，但可能会选择从第三方供应商（如 API7.ai）购买企业支持以获得服务级别协议（SLA）和专家指导。³² 使用 Kong，组织可能会发现开源版本足以满足基本需求，但很可能需要为 Kong Konnect 订阅编制预算，以解锁全套企业级功能。²⁴

第四部分：扩展性与插件生态系统

现代 API 网关的真正威力不仅在于其内置功能，更在于其扩展性。将自定义逻辑注入请求/响应生命周期的能力，使得这些平台能够适应独特的业务需求并与任何后端系统集成。Kong 和 APISIX 都在创建灵活而强大的插件架构方面投入了大量精力。

4.1 插件架构：钩子、阶段和执行优先级

两个平台的插件执行模型都与 NGINX 的请求处理阶段紧密相连。这为在请求过程中的不同时间点执行自定义代码提供了一种结构化和可预测的方式。插件可以实现“钩入”这些阶段的函数，从而在正确的时间执行特定操作。⁵⁵ 插件可用的常见阶段包括：

init_worker：在 NGINX 工作进程启动时执行一次。用于初始化资源或设置后台计时器。
certificate：在 SSL 握手期间执行，允许动态选择 SSL 证书。
rewrite：一个早期阶段，可以修改请求的 URI 或参数。
access：在请求传递到上游服务之前，实现安全策略（如认证、授权和速率限制）的主要阶段。
header_filter：在从上游服务接收到响应头之后，但在发送给客户端之前执行。
body_filter：在从上游服务流式传输响应体时执行，允许动态修改响应内容。
log：在请求完成且连接关闭后执行，是日志记录和指标收集的理想阶段。

两个平台中的一个关键概念是插件优先级。当在单个路由上启用多个插件时，它们在给定阶段内的执行顺序由一个数字优先级值决定。⁵⁸ 这对于构建复杂的策略链至关重要，例如，确保认证插件总是在

access 阶段的速率限制插件之前运行。

4.2 多语言插件开发：对比观察

认识到 Lua 虽然功能强大，但仍是一种小众语言，Kong 和 APISIX 都扩展了其平台以支持使用更主流的语言进行插件开发。这大大降低了开发团队的入门门槛，并允许他们利用现有的技能和库。然而，它们在多语言支持方面的架构方法截然不同。

Kong 的插件开发工具包 (PDKs)： Kong 为 Lua、Go、Python 和 JavaScript 提供了插件开发工具包 (PDKs)。³⁰ PDK 是一个特定于语言的库，提供了一组用于与 Kong 网关的请求和响应对象交互的函数。无论使用何种语言，基本的开发工作流程都包括创建一个实现所需请求阶段函数的处理程序模块，以及一个定义插件配置选项的模式模块。⁵⁸ 对于 Go 插件，Kong 以前使用一个独立的

go-pluginserver，但自 3.0 版本以来，它已转向更嵌入式的模型，其中 Go 插件代码被构建成一个共享库并由网关加载。⁶²

APISIX 的原生 Lua 和外部插件运行器： APISIX 支持两种主要的插件开发模式。

原生 Lua 插件： 这是性能最高、集成最紧密的方法。开发过程与 Kong 非常相似，需要一个 Lua 文件来定义插件的模式、优先级和阶段处理程序。⁵⁹
外部插件： 对于其他语言，如 Java、Go、Python 和 WebAssembly (Wasm)，APISIX 使用外部插件运行器架构。³³ 插件运行器是一个与 APISIX 数据平面并排运行的独立 sidecar 进程。当请求需要外部插件时，APISIX 会向相应的运行器发起本地 RPC 调用（通常通过 Unix 套接字）。⁶⁷ 然后，运行器在其原生语言环境（例如，Java 插件的 JVM）中执行插件逻辑，并将结果返回给 APISIX。

支持多种语言的举措是旨在降低采用门槛的关键趋势。然而，架构实现——Kong 基于 PDK 的方法与 APISIX 基于运行器的 sidecar 模型——揭示了不同的设计权衡。APISIX 的 sidecar 模型提供了卓越的故障隔离。一个编写不佳的 Java 或 Python 插件的崩溃只会终止相应的运行器进程，而核心的 APISIX 数据平面不受影响，能够继续为其他流量提供服务。这对于在拥有许多自定义插件的环境中保持稳定性是一个显著优势。其代价是由于进程间 RPC 通信可能带来的稍高延迟，以及管理运行器进程生命周期的额外运维复杂性。相反，Kong 更集成的 PDK 方法可能为外部语言插件提供稍低的延迟，因为它避免了 RPC 开销，但风险更大。一个行为不当的插件更有可能破坏其运行所在的 NGINX 工作进程。APISIX 的这一架构选择呼应了像 Istio（使用 Envoy）这样的服务网格所推广的更广泛的 sidecar 模式，使其插件模型在概念上对于已经在云原生生态系统中工作的开发者来说更为熟悉。此外，APISIX 对 Wasm 插件的早期和实验性支持，预示着对未来可能成为安全、沙盒化、高性能和语言无关的网关扩展通用标准的超前投资。²

4.3 生态系统：插件中心、社区和企业产品

一个平台的价值通常由其生态系统的实力来衡量。

Kong： 作为更成熟的参与者，Kong 拥有一个非常成熟的生态系统。其网站上有一个中央插件中心 (Plugin Hub)，展示了由 Kong 自己、其技术合作伙伴和广大社区开发的各种插件。³⁰ Kong 在 AWS 和 Azure 等主要云市场上也占有重要地位，直接向云客户提供其企业产品。⁵²

APISIX： 作为一个 Apache 软件基金会项目，APISIX 的优势在于其充满活力且迅速发展的开源社区。支持者声称，它是世界上最活跃的 API 网关项目之一，贡献速度快，贡献者数量已超过 Kong。²⁰ 虽然它没有像 Kong 那样具有商业光环的“中心”，但其文档提供了可用插件的全面列表。³² 商业支持、企业级插件和 SLA 可通过

API7.ai 获得，这是一家由 APISIX 的原始创建者创立的公司，在 APISIX 生态系统中扮演着与 Kong Inc. 在 Kong 生态系统中类似的角色。⁵⁴

OpenResty： OpenResty 没有像 Kong 或 APISIX 那样面向用户的集中式插件中心。它的生态系统更像一个标准的编程语言生态系统。它由大量的 lua-resty-* 库组成，这些库可通过社区包管理器如 LuaRocks 和 OpenResty 自己的 opm 获得。⁵ 这提供了巨大的能力和灵活性，但需要开发者付出更多努力来发现、审查和集成库。

第五部分：压力下的性能：数据驱动的分析

虽然功能和可扩展性至关重要，但 API 网关的原始性能——以吞吐量（每秒请求数，QPS）和延迟来衡量——通常是首要考虑因素，尤其对于高流量应用。Kong 和 APISIX 所做的架构选择对其性能剖面产生了直接且可衡量的影响。

5.1 剖析基准测试：QPS 与延迟对比

已有多项独立和厂商提供的基准测试来比较这些平台的性能。虽然具体数字可能因硬件、测试条件和网关版本而异，但从现有数据中可以发现一个一致的模式。

基线性能（无插件代理）： 在纯代理场景中，APISIX 始终表现出显著的性能优势。一项比较 APISIX 3.0 和 Kong 3.0 的基准测试发现，APISIX 的平均 QPS 是 Kong 的 140%。⁴⁴ 其他来源报告称，APISIX 在单核 CPU 上可达到约 18,000 QPS，延迟仅为 0.2 毫秒 ³¹，在像 AWS Graviton3 这样的新硬件上甚至更高。⁷⁶ 作为参考，早期在旧硬件上的基准测试显示 OpenResty 每秒可处理约 28,000 个请求。⁷⁷ 这些数据建立了一个清晰的性能层级，APISIX 在原始吞吐量上领先于 Kong。
启用插件后的性能： 当引入插件时，两个平台之间的性能差距急剧扩大。这是一个关键场景，因为大多数现实世界的部署都使用插件进行认证、速率限制和日志记录。比较 3.0 版本的同一基准测试发现，在启用速率限制插件的情况下，APISIX 的性能是 Kong 的 190%。当同时启用速率限制和认证插件时，APISIX 的性能飙升至 Kong 的 220%。⁴⁴ 这表明 APISIX 的插件执行框架比 Kong 的更高效，引入的开销更小。
大规模性能（多路由路由）： 路由算法的架构差异通过大规模性能测试得到了鲜明验证。一项使用 5,000 个独立路由的基准测试显示，APISIX 保持了其对 Kong 140% 的性能优势。⁴⁴ 这直接支持了 APISIX 的基数树路由算法优于 Kong 的基于遍历的搜索的说法，因为其性能不会随着路由数量的增加而下降。²⁰

5.2 架构瓶颈与影响因素

在基准测试中观察到的性能差异并非偶然；它们是前面讨论的核心架构决策的直接结果。

路由算法： 这可以说是最重要的因素。APISIX 使用基数树进行路由匹配，提供了近乎恒定的查找时间，使其在拥有数千条路由的部署中异常高效。³⁹ 相比之下，Kong 的遍历搜索随着路由数量的增长可能成为瓶颈，导致延迟增加。²⁰
配置传播： 更新数据平面配置的机制影响网关的敏捷性。APISIX 依赖 etcd 的 watch 机制，允许配置更改在毫秒级内推送到数据平面。²⁰ Kong 的传统轮询数据库模型引入了数秒的内置延迟，这在需要快速配置更改的高度动态环境中可能成为限制因素。²⁰
插件实现开销： 基准测试数据强烈表明，APISIX 加载和执行其插件的方式比 Kong 的实现性能更高，导致启用策略时的性能损失更小。⁴⁴

值得注意的是，性能是两个项目持续关注的焦点。例如，Kong 团队发现 OpenResty 的默认计时器实现在大规模健康检查和缓存等功能上成为瓶颈。作为回应，他们设计了一个新的、更具可扩展性的基于时间轮算法的计时器系统，并已集成到 Kong 3.0 中。⁷⁸ 这表明两个社区都致力于不断识别和解决性能限制。

5.3 生产环境性能调优策略

在生产环境中实现最佳性能需要针对部署拓扑和工作负载进行仔细的调优和配置。

对于 Kong：
- 部署模式： 对于性能关键型应用，强烈建议在无数据库或混合模式下运行，以将数据平面与数据库解耦，数据库可能成为延迟来源和性能变量。⁷⁹
- 资源规划： 通常最好使用更少、更大的 Kong 节点（例如，配备 4 或 8 个 CPU 核心及相应的 NGINX 工作进程数），而不是许多小节点。⁷⁹
- NGINX 调优： 标准的 NGINX 调优参数至关重要，例如将 worker_processes 设置为与可用 CPU 核心数匹配，并根据预期负载调整 worker_connections。⁸⁰
- 配置大小： 在混合模式下，从控制平面发送到数据平面的配置负载大小是影响内存使用和启动时间的关键调优参数。⁸¹
对于 APISIX：
- 工作进程： 与 Kong 类似，NGINX 配置中的 worker_processes 应设置为与可用 vCPU 数量匹配，以最大化 CPU 利用率。⁸²
- etcd 优化： etcd 集群的性能和健康状况至关重要。确保 APISIX 节点与 etcd 集群之间的低延迟对于快速配置更新和避免超时至关重要。³⁴
- 延迟分析： 理解延迟的组成部分是调优的关键。这包括客户端到 APISIX 的网络延迟、APISIX 内部处理时间（包括 Lua 插件执行）以及与上游服务交互的延迟。⁸³
- 内置优化： APISIX 除了基数树之外还使用了高效的数据结构，例如使用哈希表在允许/拒绝列表中进行快速 IP 地址匹配，这提供了 O(1) 的查找时间。³⁹
对于 OpenResty：
- 适用通用的 NGINX 和 LuaJIT 性能调优原则。对于深层次、复杂的性能问题，商业工具 OpenResty XRay 被定位为一个强大的、低开销的动态追踪解决方案，可在生产环境中使用，以查明性能瓶颈的根本原因，而无需更改代码或重启应用。³

第六部分：运维现实与战略选择

除了功能和性能基准，选择 API 网关还具有重大的长期运维影响。部署、管理、扩展和支持平台的日常现实是总拥有成本和其成功采用的关键因素。本节对比了 OpenResty、Kong 和 APISIX 的运维模型，重点关注管理开销、高可用性、社区支持以及与 Kubernetes 生态系统的集成。

6.1 运维模型：数据库 vs. etcd vs. GitOps

配置存储的架构选择决定了网关的主要运维模型。

Kong 的以数据库为中心的模型： 在其传统和混合模式下，操作 Kong 需要管理一个高可用的 PostgreSQL 或 Cassandra 集群。¹ 这项任务完全属于数据库管理员（DBA）的范畴。对于拥有成熟 DBA 团队和数据库基础设施的大型企业来说，这是一个熟悉且通常舒适的运维模型。数据库是一个已知量，有成熟的备份、恢复和扩展程序。
APISIX 的以 etcd 为中心的模型： APISIX 对 etcd 的依赖转移了运维负担。管理一个高可用的 etcd 集群是站点可靠性工程师（SRE）和在 Kubernetes 及云原生生态系统中操作的团队的核心能力。⁴⁰ 对于这些团队来说，etcd 不是一种陌生的技术，而是其基础设施的基本构建块。
趋同的 GitOps 模型： 两个平台都采纳了第三种运维模型，该模型正迅速成为现代基础设施的标准：GitOps。Kong 的无数据库模式和 APISIX 的独立模式都允许网关的全部配置在 YAML 文件中进行声明式管理。²³ 这将运维焦点从管理有状态数据库转移到在 Git 仓库中管理配置即代码。该模型非常适合自动化，提供版本控制、通过拉取请求进行同行评审以及可审计的变更，所有这些都集成到 CI/CD 流水线中。

6.2 高可用性与容错架构

确保网关不是单点故障至关重要。Kong 和 APISIX 都被设计为无状态应用，可以水平扩展以实现高可用性（HA）。

Kong HA： Kong 的典型 HA 部署包括一个负载均衡器，将流量分布到一个由两个或多个相同的、无状态的 Kong 节点组成的集群。状态本身在外部的、集群化的数据库（PostgreSQL 或 Cassandra）中管理。实现 HA 的关键任务是确保该数据库集群的弹性。¹
APISIX HA： APISIX 的 HA 架构在概念上是相同的。一个负载均衡器将流量分布到一个无状态的 APISIX 节点集群。状态在外部的、集群化的 etcd 中管理。etcd 集群的弹性是整个系统可用性的关键。⁴⁰ 在独立模式下，只需部署多个具有相同声明式配置文件的 APISIX 节点，并在前面放置一个负载均衡器，即可实现 HA。

6.3 社区 vs. 商业：支持与长期可行性

社区的健康状况和商业支持的可用性对于长期成功和风险缓解至关重要。

Kong： Kong 拥有一个庞大而成熟的社区，拥有超过 160,000 名成员，并在 GitHub 上有重要影响力。⁸⁴ 其社区论坛 Kong Nation 是用户的一个活跃资源。⁷⁰ 在商业上，Kong Inc. 是一家成熟的供应商，拥有一个精良的企业产品Kong Konnect，提供托管控制平面、高级功能、专业服务和企业级支持 SLA。²⁴
APISIX： 作为一个 Apache 软件基金会（ASF）的顶级项目，APISIX 拥有一个非常透明和活跃的开源社区，受 ASF 原则的管辖。⁸⁵ 该社区以其快速增长和高水平的贡献者活动而自豪，声称是该领域最活跃的项目之一。²⁰ 商业支持和企业级功能由API7.ai 提供，这是一家由 APISIX 的创建者创立的公司，提供与 Kong Konnect 类似的解决方案，为关键任务部署提供 SLA 和专家支持。³²
OpenResty： OpenResty 拥有一个历史悠久且专注的专家用户和开发者社区。商业支持以及企业产品 OpenResty Edge 和 OpenResty XRay 由 OpenResty Inc. 提供。³

6.4 Kubernetes 生态系统：Ingress 控制器与 Operator 成熟度

对于许多组织来说，主要的部署目标是 Kubernetes。因此，网关与 Kubernetes 生态系统集成的质量是一个关键的选择标准。两个平台都提供官方的 Kubernetes Ingress 控制器（KIC）和 Operator，以使用原生的 Kubernetes 自定义资源定义（CRD）来管理网关。³⁰

Kong KIC 和 Operator： Kong 拥有一个成熟且广泛使用的 Ingress 控制器，可将 Kubernetes Ingress 和 Gateway API 资源转换为 Kong 配置。⁸⁹ 对于使用官方 Kubernetes Gateway API 标准的部署，现在推荐使用 Kong Operator 作为安装方法，因为它提供了更紧密的集成和更好的生命周期管理。⁹⁰
APISIX Ingress 控制器： APISIX Ingress 控制器也是一个成熟且功能丰富的项目。其最重要的创新是最近的架构转变，即在 Kubernetes 中运行时消除了对独立 etcd 集群的需求。⁴² 该控制器现在运行一个在内存中模拟etcd API 的组件，使用 Kubernetes API 服务器作为其真实来源。这极大地简化了部署架构，减少了运维开销，并降低了资源消耗，使其成为比其前身和需要独立状态存储的竞争对手更轻量级、更“Kubernetes 原生”的解决方案。⁴²

这些网关之间的选择越来越成为一个组织希望拥抱哪种运维生态系统和理念的选择。拥有强大 DBA 技能的传统企业可能会发现 Kong 以数据库为中心的模型非常契合。而拥有深厚 Kubernetes 和 SRE 专业知识的云原生组织会发现 APISIX 以 etcd 为中心的模型是其现有环境的自然延伸。竞争的战场正明显转向 Kubernetes，在这里，运维的简单性是至高无上的美德。在这个舞台上，APISIX 决定为其 Ingress 控制器工程化地去除外部 etcd 依赖是一个重大的战略举措。它直接解决了一个主要的运维痛点——为网关管理一个独立于 Kubernetes 自身 etcd 的状态存储的复杂性——并将其架构简化得更像精简的 ingress-nginx 控制器。虽然 Kong 以 Operator 为主导的方法也表明了其对更深层次 Kubernetes 集成的承诺，但 APISIX 实现的架构简化目前在 Kubernetes 环境下的运维优雅性方面使其具有优势。最终，云原生领域的长期赢家很可能是那个提供最无缝、资源效率最高、真正“Kubernetes 原生”运维体验的平台。

第七部分：综合与战略建议

本综合分析已从基本原则、核心架构、功能集、性能特征和运维模型等多个维度，对 OpenResty、Kong 和 Apache APISIX 进行了剖析。最后一步是将这些发现综合成一个清晰的比较摘要，并提供基于场景的可行建议，以指导战略决策。

7.1 比较摘要表

下表提供了三个平台关键属性的整合、一目了然的比较。

属性	OpenResty	Kong Gateway	Apache APISIX
主要身份	高性能 Web 平台与工具包 ³	面向企业的 API 网关与管理平台 ¹	高性能、云原生的 API 网关 ³¹
核心技术	增强版 NGINX + LuaJIT ³	直接构建于 OpenResty 之上 ¹	NGINX 网络库 + LuaJIT；自定义动态核心 ²
配置存储	NGINX `.conf` 文件, Lua 脚本 ⁸	PostgreSQL, Cassandra, 或声明式文件 (无数据库模式) ¹	etcd 或声明式文件 (独立模式) ³¹
配置传播	NGINX 重载/重启	数据库轮询 (秒级) 或基于文件 ²⁰	etcd 监视 (毫秒级) 或基于文件 ²⁰
路由算法	N/A (由用户逻辑定义)	遍历搜索 ²⁰	基数树 (高度可扩展) ³⁹
部署模式	N/A (自定义服务器设置)	传统模式, 混合模式 (CP/DP), 无数据库模式 ²³	传统模式, 解耦模式 (CP/DP), 独立模式 ³⁵
插件语言	Lua, C (NGINX 模块) ³	Lua, Go, Python, JavaScript (通过 PDK) ⁵⁶	Lua (原生), Java, Go, Python, Wasm (通过运行器) ³³
性能 (QPS)	高 (基线) ⁷⁷	良好；低于 APISIX，尤其在有插件时 ⁴⁴	优秀；行业领先，尤其在有插件时 ⁴⁴
性能 (延迟)	低 ⁷⁷	低；高于 APISIX ⁴⁴	非常低 (亚毫秒级) ³¹
开源模型	BSD 许可证 ⁴	开放核心 (OSS 网关 + 企业版 Konnect) ³⁰	Apache 2.0 许可证 (功能完全开放) ⁵¹
K8s 集成	手动 / 自定义	成熟的 Ingress 控制器与 Operator ⁸⁹	成熟的 Ingress 控制器 (无 etcd 选项) ³⁸
商业产品	OpenResty Inc. (Edge, XRay) ¹⁷	Kong Inc. (Kong Konnect) ²⁴	API7.ai (API7 Enterprise) ⁵⁴

7.2 基于场景的建议

“最佳”API 网关并非一个普适的称号；它是一个组织特定背景、优先事项和约束条件的函数。基于详细分析，为不同的战略场景提供以下建议。

场景 1：“自己动手”路径，追求最大灵活性和定制化构建

建议：OpenResty

对于需要一个无固定范式、高性能的工具包来构建完全定制化解决方案的高技能工程团队来说，OpenResty 是理想选择。它不是一个交钥匙的 API 网关，而是一套强大的构建模块。

选择 OpenResty 的时机：
- 您的需求非常独特，以至于现成的网关限制过多或引入了不必要的开销。
- 您正在构建一个专业系统，例如高频广告服务平台、内容分发网络（CDN）边缘节点，或需要控制每一行逻辑的定制化 Web 应用防火墙（WAF）。
- 您的团队在 NGINX、Lua 和系统编程方面拥有深厚的专业知识，并且乐于从基本原则出发构建和维护一个自定义平台。³
- 目标是创建一个专有平台或产品，而不仅仅是管理内部 API。

场景 2：企业路径，追求成熟、有商业支持的 API 管理

建议：Kong

对于寻求一个经过验证、功能丰富且有商业支持的 API 管理平台的企业来说，Kong 是首选。其架构和生态系统专为大型、复杂组织的需求而设计。

选择 Kong 的时机：
- 您的组织优先考虑一个全面的、全生命周期的 API 管理解决方案，包括开发者门户、分析功能和精美的用户界面，这些都由 Kong Konnect 企业版提供。²⁴
- 您需要来自成熟供应商的强大商业支持，包括有保障的 SLA 和专业服务。⁴⁹
- 您的运维团队在管理像 PostgreSQL 这样的集群关系型数据库方面拥有丰富的经验，使得 Kong 的传统架构成为一个舒适的选择。¹
- 生态系统的成熟度和广泛的企业级插件与集成，比实现绝对最低的延迟或最高的原始吞吐量更重要。

场景 3：云原生路径，追求极致性能和敏捷性

建议：Apache APISIX

对于优先考虑最高性能、实时敏捷性以及与云和 Kubernetes 生态系统原生的运维模型的组织来说，Apache APISIX 是领先选择。

选择 APISIX 的时机：
- 性能至关重要。 您的用例涉及高吞吐量、低延迟的工作负载，每一毫秒都至关重要。APISIX 的卓越性能，尤其是在有多个插件和数千条路由的情况下，是一个关键优势。³¹
- 敏捷性和实时更新是必需的。 您的环境高度动态，需要近乎瞬时的配置变更传播，用于流量切换、金丝雀发布或安全策略更新。²⁰
- 您深度投入于 Kubernetes 生态系统。 APISIX 与 etcd 的架构对齐及其创新的无 etcd Ingress 控制器，在 Kubernetes 内部提供了更无缝、运维效率更高的体验。⁴²
- 您偏爱一个在 Apache 软件基金会治理下的“完全开放”项目，其中大量功能在开源版本中可用，无需商业许可。⁵¹

7.3 未来轨迹与总结思考

API 管理的格局正在迅速演变。Kong 和 APISIX 之间的激烈竞争是创新的强大催化剂，推动两个平台提升性能、简化运维并向新的技术前沿扩展。两者都在通过 Gateway API 标准大力投资于与 Kubernetes 的更深度集成，并且都将自己定位为下一波 AI 和 LLM 驱动应用的中央控制点。

最终，选择一个网关是一项长期的战略决策。这不仅是对一个软件的投资，也是对一个架构、一个运维模型和一个生态系统的投资。本报告提供了详细的分析和细致的理解，旨在帮助架构师和技术领导者超越表面的功能比较，做出一个技术上合理、运维上可行且与组织未来方向战略上一致的选择。

摘要