Kong：插件化 API 网关架构解析

项目地址：https://github.com/Kong/kong 定位：基于 OpenResty（Nginx+LuaJIT）的高性能 API 网关与微服务管理平台，插件生态是其灵魂。

元信息	说明
语言	Lua / OpenResty（新版支持 Go/WASM 插件、Kong Gateway OSS + Enterprise）
星标	38k+ ⭐
协议	Apache 2.0（OSS）
依赖	PostgreSQL 作为配置存储（Cassandra 支持已于 3.x 移除；另有声明式 DB-less 模式）
系列关联	本文是网关三部曲之二（第 8 篇 Traefik → 本文 → 第 18 篇 Istio）

1、背景：API 网关的问题域

微服务拆分后，外部请求需要统一入口处理横切关注点：

认证鉴权 / 限流熔断 / 日志审计 / 协议转换
缓存 / 灰度路由 / 监控埋点 / 证书管理 / 请求/响应改写

Kong 的答案：数据面（OpenResty 高性能转发）+ 控制面（声明式配置/DB）+ 插件模型（一切皆插件）。对比 Traefik 的"动态路由优先"，Kong 更强调"API 生命周期管理"——路由只是入场券，插件市场才是主菜。

2、核心架构

2.1、请求处理全链路

client ──> Nginx/OpenResty（worker 进程）
             │ 路由匹配（service.route：host/path/method/source）
             ▼
          ┌──────────── 插件管道（按优先级排序执行） ────────────┐
          │ access 阶段：ip-restriction → rate-limiting →      │
          │              jwt/bot-detection → correlation-id    │
          ├────────────────────────────────────────────────────┤
          │ upstream 转发（负载均衡：round-robin/一致性哈希）      │
          ├────────────────────────────────────────────────────┤
          │ response 阶段：response-transformer → correlation-id│
          │ log 阶段：http-log → statsd/prometheus              │
          └────────────────────────────────────────────────────┘
             ▼
          upstream（后端服务 / Kong 之间 mesh）

插件是 Lua 模块，挂载在 OpenResty 的处理阶段上，每个路由/服务/消费者可任意组合启停——这是"微内核 + 插件"模式在网关领域的标准实现。

2.2、对象模型：Service → Route → Consumer → Plugin

# 一切配置皆对象，支持 Admin API 与声明式两种管理方式
curl -X POST http://localhost:8001/services \
  -d name=example -d url=http://upstream:8080

curl -X POST http://localhost:8001/services/example/routes \
  -d 'paths[]=/api' -d name=api-route

curl -X POST http://localhost:8001/routes/api-route/plugins \
  -d name=rate-limiting -d config.minute=100

# Consumer 维度差异化（VIP 用户更高限额）
curl -X POST http://localhost:8001/consumers -d username=vip
curl -X POST http://localhost:8001/plugins \
  -d name=rate-limiting -d consumer.username=vip \
  -d config.minute=10000

层次化配置（global → service → route → consumer，越具体越优先）让"通用策略 + 例外管理"可以声明式表达，不用写一行代码。

2.3、DB-less 模式与 GitOps

KONG_DATABASE=off KONG_DECLARATIVE_CONFIG=kong.yml kong start

配置以 YAML 声明（deck 工具双向同步），无数据库依赖——K8s 环境下天然契合 GitOps（配置进 Git，CI 校验后滚动生效），也消除了"DB 故障导致网关瘫痪"的耦合。

3、快速上手

docker network create kong-net

# 1) 配置存储（经典模式）
docker run -d --name kong-db --network kong-net \
  -e POSTGRES_USER=kong -e POSTGRES_DB=kong \
  -e POSTGRES_PASSWORD=kong postgres:16

# 2) 迁移 + 启动
docker run --rm --network kong-net -e KONG_DATABASE=postgres \
  -e KONG_PG_HOST=kong-db kong:3.7 kong migrations bootstrap
docker run -d --name kong --network kong-net \
  -e KONG_DATABASE=postgres -e KONG_PG_HOST=kong-db \
  -e KONG_PROXY_LISTEN=0.0.0.0:8000 -e KONG_ADMIN_LISTEN=0.0.0.0:8001 \
  -p 8000:8000 -p 8001:8001 kong:3.7

# 3) 验证 & 接一个后端
curl http://localhost:8001/          # Admin API 就绪
# 配 service/route/plugin 见 2.2 示例，随后：
curl http://localhost:8000/api/hello

高可用：Kong 无状态（DB-less）或多实例 + 前置 LB（经典模式）；K8s 里用 Kong Ingress Controller 以 CRD 管理路由与插件。

4、插件开发：网关的扩展经济学

方式	语言	生态	性能
Lua（PDK）	Lua	原生、官方文档齐全	最高（worker 内）
Go plugin	Go	独立进程 + RPC	高
WASM（Proxy-Wasm）	Rust/Go/AssemblyScript 等	新标准，跨网关	高
外部函数	任意	HTTP 调用外部服务	取决于外部

开发一个最小插件（Lua）只需要一个 handler.lua + schema.lua，PDK（Plugin Development Kit）提供 kong.request.get_header()、kong.service.request.set_header() 等原语。插件在 access/header_filter/body_filter/log 等阶段被回调——理解 OpenResty 执行阶段是写插件的前置课。

5、生产实践清单

版本选择：OSS 与 Enterprise 差异逐年扩大（RBAC、工作区、Vitals、动态 TLS 属商业版）；选型前对照功能矩阵，避免上线后才发现关键能力在付费墙内；
性能与容量：Lua 插件在 worker 内执行，单机 QPS 万级轻松；瓶颈通常在 DB 模式的配置一致性轮询——大集群选 DB-less 或 Enterprise 的混合模式（控制面/数据面分离）；
限流策略：rate-limiting 有 local/cluster/redis 三种策略——local 只对单节点计数，多副本后必须上 cluster（DB 共享）或 redis，否则限额会被副本数放大；
认证体系：jwt/key-auth/basic-auth/oauth2 可组合；大厂常见姿势：网关层 JWT 验签 + 服务层细粒度鉴权（网关不背所有业务逻辑）；
可观测性：开 prometheus 插件（QPS/延迟/连接数/上游健康），http-log 打点到 ELK/Loki，opentelemetry 插件做链路追踪——三件套配齐才能定位"网关还是上游慢"；
安全基线：Admin API（8001）绝不对公网暴露；pre-function 插件慎用（任意 Lua 执行面）；TLS 版本与密码套件按等保/合规收紧。

6、横向对比：网关三部曲

维度	Traefik（第 8 篇）	Kong（本文）	APISIX	Envoy/Istio（第 18 篇）
内核	Go	OpenResty	OpenResty	C++
配置	Provider 动态	DB/DB-less 声明式	etcd + Dashboard	xDS 动态
插件	中间件/wasm	Lua/Go/WASM，最成熟	Lua，更轻更年轻	Filter/wasm
定位	边缘路由	API 全生命周期	API 网关（国产，Apache 顶级）	服务网格 sidecar/网关

选型直觉：容器环境自动路由 → Traefik；重插件治理与 API 资产管理 → Kong/APISIX（国产生态与中文支持选 APISIX）；微服务间流量治理 → Istio。

7、面试高频问答

Q：Kong 为什么选 OpenResty 而不是纯 Go？ A：Nginx 事件驱动模型的连接处理性能久经考验，LuaJIT 在 worker 内执行插件接近原生速度；代价是开发语言小众与调试成本——这也是 APISIX 同样选 OpenResty 的原因。
Q：DB-less 和 DB 模式怎么选？ A：DB-less=配置不可变快照（GitOps 友好、无 DB 依赖，但运行时不能通过 Admin API 随意变更）；DB 模式=动态性强（消费自助、自动注册），适合中心化 API 平台。K8s 原生部署倾向 DB-less。
Q：限流在多副本下怎么保证准确？ A：计数器共享（cluster 模式走 DB 事务或 redis 原子操作）必然增加延迟；接受"近似限流"（local + 配额切分：每副本 limit/副本数）换取零额外依赖——网关限流本来就该是防击穿而不是精确计费。
Q：网关层鉴权与服务层鉴权的边界？ A：网关做"身份认证"（谁在调用，JWT/key 验签）与粗粒度授权（路由级）；业务级权限（这个用户能不能改这个订单）必须在服务内——网关不该长出业务逻辑，否则插件库会腐化成单体。

8、总结

Kong 把"API 网关"做成了一个平台工程问题：对象模型管理 API 资产、插件管道承载横切关注点、声明式配置融入 GitOps。它的插件架构与 OpenResty 执行模型值得每个后端工程师精读——即使你最终选了别的网关，"横切关注点插件化"的思想会跟随你整个职业生涯。

9、参考资料

官方文档：https://docs.konghq.com/
GitHub：https://github.com/Kong/kong
OpenResty 执行阶段：https://openresty-reference.readthedocs.io/
本系列第 8 篇（Traefik）、第 18 篇（Istio）