📚 课程目录第2章 Kong网关核心原理与配置

API网关高级研发工程师高阶面试宝典 - 第2节

Kong 网关核心原理与配置

本章聚焦 Kong 网关在面试中的高频考察点：安装部署策略、插件机制、路由与服务的配置逻辑、性能调优实战。掌握结构化回答框架，能帮助你在面试中清晰展示对 Kong 架构的理解与工程落地能力。

考察点	对 Kong 部署架构的理解（DB 模式 vs DB-less 模式）、容器化与 K8s 部署经验、高可用设计。
回答框架	结论先行 → 方案对比 → 选型理由 → 实践要点 ① 一句话结论：推荐 K8s 下 DB-less 模式（声明式配置），传统场景用 DB 模式。 ② 对比两种模式优缺点。 ③ 根据团队运维能力、流量规模选择。 ④ 强调健康检查、Lua 共享字典、Worker 数配置。
示例回答	“生产环境我首选 K8s + DB-less 模式，配置声明式、无中心 DB 依赖。若团队已有 PostgreSQL 运维能力且需要动态管理，则使用 DB 模式。我曾在日亿级请求项目中使用 DB 模式搭配 PgBouncer 连接池，确保 Kong 数据库不成为瓶颈。”
可能追问	• DB-less 模式下如何热更新配置？ • 如何做 Kong 集群的蓝绿部署？ • 数据库表设计与索引优化？
避坑提醒	❌ 避免只背官方文档；要结合实际案例（如 DB-less 下 declarative config 变更需重启）。 ✅ 强调“高可用”和“运维成本”两个维度。

考察点	插件执行顺序（phases）、Lua 与 OpenResty 能力、插件注册与配置、性能影响。
回答框架	总述阶段 → 分阶段职责 → 自定义插件流程 → 性能注意点 ① Kong 插件基于 OpenResty 阶段：init、rewrite、access、header_filter、body_filter、log。 ② 自定义插件需实现 `schema.lua` 和 `handler.lua`，注册到 `custom_plugins`。 ③ 注意避免阻塞操作，使用 `ngx.timer` 或 `lua-resty` 异步化。
示例回答	“插件执行分六个阶段，最常用的是 access 阶段做鉴权，log 阶段做日志。开发自定义插件时，我通常继承 `BasePlugin`，实现 `access()` 方法；配置通过 `schema.lua` 声明校验。曾为灰度发布开发过一个 header 染色插件，性能损失小于 2%。”
可能追问	• Phases 执行顺序与 OpenResty 对应关系？ • 如何保证插件热更新？ • 如何监控插件性能？
避坑提醒	❌ 不要遗漏 `schema.lua` 的 validation 逻辑，否则配置注入危险。 ✅ 强调“非阻塞”和“共享内存”的使用，体现性能意识。

考察点	Route 匹配优先级、Service 与 Upstream 关系、健康检查配置、负载均衡算法。
回答框架	分层模型 → 匹配规则 → 负载均衡与健康检查 → 动态调整 ① Kong 三层模型：Route → Service → Upstream（Target）。 ② 路由优先级：精确路径 > 前缀匹配 > 正则；Header、Method 可叠加。 ③ Upstream 支持 round-robin、least-connections、一致性哈希。 ④ 主动+被动健康检查结合，避免只依赖一种。
示例回答	“路由匹配按权重评分，精确路径优先。我设计了一个多环境路由：通过 Host 头部区分 prod/staging。Upstream 使用 least-connections + 主动健康检查（每 10s 一次，超时 1s），被动熔断连续 5 次失败标记不可用。K8s 环境下自动同步 Endpoint。”
可能追问	• 正则路由性能如何？大规模路由表如何优化？ • 如何实现金丝雀发布？ • 健康检查超时与重试策略怎么设置？
避坑提醒	❌ 不要忽略路由数量大时的性能（使用 Redis 缓存路由）； ✅ 举例说明“动态路由变更”的场景，体现实操经验。

项目名称	基于 Kong 的统一 API 网关平台（灰度/监控/限流一体化）
业务背景	原基于 Nginx + Lua 的定制网关维护成本高，扩展困难。业务需要统一鉴权、限流、灰度、日志。选型 Kong 并进行二次开发。
规模指标	集群 12 节点（8C16G），日均请求 8 亿；峰值 QPS 12万；管理 200+ 服务，1500+ 路由；插件数 30+。
技术栈	Kong 2.8 (DB 模式) + PostgreSQL 12 + PgBouncer + Redis (限流/缓存) + Prometheus + Grafana + K8s 部署
核心难点	① 大规模路由匹配性能（优化为前缀树 + 共享字典缓存） ② 自定义插件多导致内存泄漏（定位为未释放 cosocket） ③ 数据库瓶颈（引入 PgBouncer + 连接池优化） ④ 灰度发布与蓝绿切换自动化
面试高频追问	• 如何定位 Kong Worker 内存暴涨问题？ • DB 模式下如何避免数据库成为瓶颈？ • 自定义插件如何做单元测试与性能压测？ • 灰度策略如何与 Route 权重结合？
可迁移回答话术	“在网关性能优化中我遵循‘先定位、后优化’原则：先用 Lua 火焰图分析 CPU 热点，再用 lua-resty-leaky-bucket 做平滑限流。数据库瓶颈通过读写分离 + 业务配置缓存解决。这套方法论同样适用于其他基于 OpenResty 的网关产品。”

💡 面试加分点：在回答 Kong 相关问题时，主动提及 OpenResty 阶段、Lua 性能优化、生产级运维监控，能显著拉开与普通候选人的差距。

⚠️ 高频雷区：
· 混淆 DB 模式与 DB-less 模式的能力边界。
· 只讲功能不讲性能（如插件内做同步 HTTP 请求）。
· 忽略 Kong Admin API 的安全性（生产务必禁用或添加认证）。