1. Kong网关概述：Kong Gateway的发展历程、核心功能与版本对比
1.1 发展历程：从开源API网关到云原生服务控制平台
Kong Gateway 最初由 Mashape 公司于 2015 年开源，基于 OpenResty（Nginx + LuaJIT）构建，凭借其高性能、插件化架构和声明式管理迅速成为 API 网关领域的标杆。其发展可划分为四个关键阶段：
| 阶段 | 时间 | 核心特征 | 代表版本 |
|---|---|---|---|
| 开源起步 | 2015–2017 | 基于 OpenResty，插件化架构，RESTful Admin API | 0.x → 1.x |
| 企业化扩展 | 2018–2020 | 推出企业版（EE），增加 Dev Portal、Vitals、RBAC | 2.x |
| 云原生重构 | 2021–2023 | Kong Gateway Operator、Kong Mesh、声明式 DB-less 模式 | 3.x |
| AI 与多协议 | 2024–至今 | AI Gateway 插件、gRPC/WebSocket 深度支持、Kong Konnect 混合云 | 3.6+ |
关键里程碑：Kong 3.x 版本引入了 DB-less 模式和声明式配置（decK），使得 Kong 可以完全脱离数据库运行，成为真正意义上的云原生 Sidecar 或 Ingress Controller，为 Helm 部署和资源配额管理奠定了架构基础。
1.2 核心功能：路由、限流与认证
Kong 的核心能力围绕 流量管理、安全防护 和 可观测性 三大维度展开。以下为最核心的三项功能：
- 路由（Routing）：基于 Host、Path、Method、Header 等条件将请求转发至上游服务。支持加权轮询、一致性哈希、健康检查等负载均衡策略。
- 限流（Rate Limiting）：通过本地计数器或 Redis 集群实现秒/分/时/日级别的请求速率限制。支持按 Consumer、IP、Credential 等维度做精细化限流。
- 认证（Authentication）：内置 Key-Auth、JWT、OAuth2、Basic-Auth、HMAC、LDAP、OpenID Connect 等多种认证插件，可组合使用形成多层安全防线。
功能联动示例：一个典型的 API 请求流经 Kong 时，依次经过 认证 → 限流 → 路由 → 日志/监控 插件链，每个环节均可通过插件热插拔动态调整，无需重启网关。
1.3 企业版与开源版对比
Kong Gateway 提供 开源版（OSS） 和 企业版（EE） 两种发行形态。企业版在开源版基础上增加了管理界面、高级安全、混合云管理等能力。以下为关键差异对比：
| 对比维度 | 开源版 (OSS) | 企业版 (EE) |
|---|---|---|
| 许可证 | Apache 2.0 | 商业许可（需订阅） |
| 管理界面 | 仅 Admin API（REST） | Kong Manager（Web UI） |
| 开发者门户 | 无 | Dev Portal（API 文档/订阅管理） |
| 安全功能 | 基础认证插件 | RBAC、审计日志、密钥轮换、安全扫描 |
| 可观测性 | Prometheus 插件（社区） | Vitals（内置监控面板 + 告警） |
| 部署模式 | 传统 DB 模式、DB-less | 混合云模式（Konnect）、DB-less、传统模式 |
| 插件数量 | ~60+ 社区/官方插件 | ~80+（含企业专属插件：OIDC、Proxy Cache 增强等） |
| 支持服务 | 社区支持 | 24/7 企业支持 + SLA |
架构选型提示：在 Helm 部署场景下，开源版和企业版的 Helm Chart 结构基本一致，但企业版需要额外配置
enterprise.enabled=true 以及 license 密钥。资源配额模型（CPU/内存/副本数）在两者之间通用，但企业版由于包含 Kong Manager 和 Dev Portal 等额外组件，整体资源需求会高出 30%–50%。
1.4 版本架构演进对比
从 2.x 到 3.x，Kong 的架构发生了显著变化，直接影响 Helm 部署时的资源规划：
架构演进对资源配额的影响：3.x 的 DB-less 模式消除了数据库依赖，使得 Kong 可以以无状态 Pod 形式运行于 Kubernetes，资源配额模型从“Proxy + DB”二元组简化为“Proxy 副本数 + 配置卷”的单一维度，大幅降低了 Helm 部署的复杂度。