1. Kong 网关概述：架构、核心组件与传统对比
Kong 网关是基于 Nginx + OpenResty + Lua 构建的高性能 API 网关，广泛应用于微服务架构中的流量管理、安全认证、协议转换与可观测性场景。本节从架构分层、核心组件与对比传统网关三个维度建立对 Kong 的全局认知。
1.1 Kong 网关架构分层
Kong 采用 控制面（Control Plane）与数据面（Data Plane）分离 的架构设计，兼顾集中管理与高性能转发。
架构要点： 控制面负责配置管理与 API 下发，数据面负责实际流量转发与插件执行，两者通过数据库或声明式配置文件同步。
1.2 核心组件详解
Kong 的核心能力建立在三个技术支柱之上，下表对比各组件在网关中的角色与职责：
| 组件 | 角色 | 关键特性 | 在 Kong 中的职责 |
|---|---|---|---|
| Nginx | 高性能 Web 服务器 / 反向代理 | 事件驱动、异步非阻塞、低内存 | 基础 HTTP 请求处理、连接管理、负载均衡 |
| OpenResty | Nginx + LuaJIT 扩展平台 | 动态脚本、协程调度、共享内存 | 提供 Lua 运行时，支持动态路由与插件热加载 |
| Lua / LuaJIT | 轻量级嵌入式脚本语言 | JIT 编译、极低开销、与 C 互操作 | 实现插件逻辑（认证、限流、日志、转换等） |
性能提示： Kong 的每个请求处理都在 Nginx worker 内以 Lua 协程方式执行，避免了多线程上下文切换开销，这是 Kong 能支撑万级 TPS 的关键原因。
1.3 Kong 与传统 API 网关的对比
传统 API 网关（如基于 Java 的 Zuul 1.x、基于 Node.js 的 Express Gateway）与 Kong 在架构、性能与扩展性上存在显著差异。下表从 8 个关键维度进行对比：
| 对比维度 | Kong（Nginx + OpenResty） | 传统网关（Zuul / Express Gateway） |
|---|---|---|
| 底层引擎 | Nginx 事件驱动 + LuaJIT | Servlet 阻塞 I/O / Node.js 事件循环 |
| 请求处理模型 | 异步非阻塞，单 worker 可处理数万并发 | 线程/进程模型，并发受限于线程数 |
| 插件机制 | Lua 插件，热加载，运行时动态安装 | Java Filter / Node.js 中间件，需重启 |
| 性能（P99 延迟） | 通常 < 5ms（无插件） | 通常 10~50ms（同等条件下） |
| 扩展性 | 数据面无状态，水平扩展简单 | 需会话同步或额外状态层 |
| 配置管理 | 声明式（decK）+ Admin API + KIC | 配置文件 / 管理界面 |
| 多集群支持 | 原生 Hybrid 模式，CP/DP 分离 | 通常需自建同步方案 |
| 生态与插件市场 | 200+ 官方与社区插件 | 相对较少，需自行开发 |
1.4 为什么选择 Kong 做延迟诊断与性能调优
本课程聚焦 API 延迟诊断 与 多集群性能调优，Kong 具备以下天然优势：
- 可观测性插件丰富： 内置 Prometheus、Zipkin、OpenTelemetry 等插件，可直接采集延迟、错误率、吞吐量等指标。
- 缓存策略灵活： 支持共享字典（lua_shared_dict）、Redis、Proxy Cache 等多级缓存，是延迟优化的核心手段。
- 多集群原生支持： Hybrid 模式（CP/DP 分离）使得跨区域、跨机房部署成为标准能力，便于进行全局延迟分析。
- 性能可调参数多： Nginx worker 数、连接池、缓冲区、Lua 协程池等均可按业务场景精细调优。