kong

想象一下：你公司有 20 个微服务、10 个 AI 模型，每个都要独立管理认证、限流、监控、路由——光是配置维护就能让整个团队崩溃。Kong 就是来解决这个问题的。

🦍 Kong 是什么：一个会管流量的「大猩猩」

Kong（中文社区常称「孔」）是一个诞生于 2011 年的开源 API 网关，GitHub 仓库 Kong/kong 目前拥有 43,000+ 颗星，是全球最受欢迎的 API 管理开源项目之一。项目核心语言为 Lua，运行在 NGINX 之上——这意味着它天然继承了 NGINX 的高性能和非阻塞 I/O 能力，同时通过 Lua 脚本实现了高度可插拔的业务逻辑扩展。

近年来，随着 AI 浪潮涌来，Kong 迅速从「传统 API 网关」进化为「AI & LLM 网关」。2024-2025 年，Kong 密集发布了 AI 代理插件（AI Proxy Plugin）、多模型路由（Multi-LLM Routing）、MCP（Model Context Protocol）安全治理等重量级功能，将自己在 API 管理领域积累了十余年的流量管控能力无缝迁移到 AI 工作负载管理场景。

图1：Kong 核心架构示意图——从 API 代理到 AI 网关的演进

🔬 核心技术解剖：为什么它能打？

高性能核心：Lua + NGINX 的化学反应

Kong 的底层基于 OpenResty（一个将 Lua JIT 嵌入 NGINX 的扩展），这让它获得了两个关键优势：第一，NGINX 的事件驱动架构保证了每个请求的极低延迟（实测 P99 < 1ms）；第二，Lua 脚本在请求生命周期内可以任意插入钩子（hook），实现插件化的功能扩展，而无需改动核心代码。

代码结构上，Kong 采用清晰的模块化分层：

• kong/init.lua：入口文件，负责初始化共享字典、加载全局补丁
• kong/runloop/：请求路由与负载均衡的核心循环逻辑
• kong/db/：数据库抽象层（支持 PostgreSQL、Cassandra），管理 Service/Route/Plugin 的元数据
• kong/llm/：Kong 3.x 新增的 LLM 专用模块，内置多模型适配器和驱动框架

AI 流量管控：多模型统一入口

Kong 在 kong/llm/drivers/ 目录下实现了对主流 LLM 平台的适配：

• openai.lua：OpenAI GPT 系列（含 DALL-E、Whisper 等多模态能力路由）
• anthropic.lua：Claude 系列，支持工具调用（Tool Use）
• azure.lua：Azure OpenAI Service，企业级身份与合规
• gemini.lua：Google Gemini 多模态模型
• bedrock.lua：AWS Bedrock（Claude/Llama/Titan 等）
• cohere.lua、huggingface.lua、mistral.lua：覆盖更多模型生态

这种「适配器模式」的架构设计，使得 Kong 可以在同一个入口后面，同时代理来自不同提供商的 AI 请求，实现统一鉴权、限流、监控、缓存——对 AI 开发者来说，这就意味着你不需要在每个 AI Agent 里单独实现 Token 计数或成本控制，Kong 直接帮你管了。

插件生态：Kong 的灵魂所在

Kong 真正的护城河是插件系统。通过 kong/plugins/ 目录下的插件，Kong 可以动态注入认证（JWT、OAuth2、API Key）、限流、熔断、缓存、日志、转换（请求/响应改写）等能力。插件以 Lua 编写，遵循统一的 PDK（Plugin Development Kit）接口规范，任何开发者都能快速编写自己的插件。

云原生能力：Kubernetes Ingress Controller

Kong 官方维护了独立的 kubernetes-ingress-controller 项目，将 Kong 的路由规则直接映射为 Kubernetes Ingress 资源。这意味着你可以用纯 K8s 原生语法管理 Kong 配置，配合 Helm 一键部署，在 K8s 环境中实现「声明式」的 API 流量管理。

📊 量化看实力：数据不会说谎

🚀 怎么上手：两条路

对于普通开发者，Kong 官方提供了开箱即用的 Docker 镜像（来自独立仓库 Kong/docker-kong），配合 docker-compose --profile database 可以在本地一键启动带数据库的 Kong 实例，管理界面 Admin GUI 默认在 8001 端口，5 分钟内即可完成 API 注册和插件配置。

对于 AI 开发者，Kong 新增了 Admin API 和声明式配置（deck）两种方式管理 AI 流量。你可以把 Kong 当作 AI 应用的「流量大门」：所有 LLM 请求经过 Kong 时，自动附加鉴权、记录 Token 消耗、应用限流策略——相当于给你的 AI 应用加了一层企业级的流量护盾。

Kong 原生不依赖 GPU，是纯粹的流量处理层，不占用训练或推理资源。当然，如果你计划在 Kubernetes 环境中运行，配合 GPU 节点池部署 AI 推理服务（比如 vLLM），Kong 可以在 Ingress 层统一管理进出流量，形成完整的 AI 服务网格。

⚠️ 现实的一面：它也有局限

Kong 不是一个 AI 模型服务框架，它不运行任何模型——它只是帮你管理访问模型的流量。如果你需要部署自己的开源模型（Llama、Mistral 等），Kong 本身无法满足，你需要的是 vLLM、Ollama 或 TGI。但如果你已经有 AI API 服务（或使用云端 LLM），Kong 能极大降低你的运维复杂度。

另外，Kong 的学习曲线相对陡峭：Lua 语言本身偏小众，OpenResty 的非阻塞编程范式对习惯同步代码的开发者有门槛，加上 Kong 配置语法（kong.conf、deck 声明式 YAML）较丰富，完整掌握需要一定时间。建议从官方文档的「Getting Started」入手，先跑通一个简单的 API 代理场景，再逐步扩展到 AI 场景。

🌐 行业意义：AI Gateway 赛道的有力选手

2025 年是「AI Gateway」概念爆发的一年。随着企业大量引入多供应商 LLM、AI Agent 数量激增，如何统一管控 AI 流量、安全、成本的挑战越来越突出。传统 API Gateway 厂商（Kong、Apache APISIX）和新兴 AI 原生网关（Bifrost、Portkey）在这一赛道正面交锋。

Kong 的优势在于存量用户基础——全球已有数万家企业将 Kong 用于传统 API 管理，向 AI Gateway 演进时，这些团队不需要学习新平台，直接在现有 Kong 集群上启用 AI 插件即可。这种「存量迁移」的成本优势，是 Kong 在 AI Gateway 赛道最核心的竞争力。

Kong 3.12 版本带来的 MCP（Model Context Protocol）治理功能，更是直击 AI Agent 时代的痛点——当企业需要让多个 AI Agent 互相通信、共享工具时，Kong 作为统一入口可以统一管理 MCP 服务器的安全认证、流量审计和访问策略，这在多 Agent 协作场景中极有价值。