Kong攻略：和Nginx、Traefik怎么选
Kong攻略里最常见的问题不是“它强不强”，而是它和 Nginx、Traefik 到底谁更适合自己的项目。三者都能接请求，却解决不同层面的麻烦。用真实选型问题拆开聊：流量入口、插件治理、Kubernetes、性能与运维成本，避免一上来就选错赛道。
问：Kong、Nginx、Traefik都是反向代理吗？
是，但重点不同。Nginx 是久经考验的 Web 服务器和反向代理，静态文件、负载均衡、基础转发都很能打；Traefik 对动态服务发现和容器标签很友好；Kong 则更聚焦 API 治理，把路由、消费者、认证、限流、插件策略做成核心能力。
换句话说，Nginx 像一把极顺手的多功能工具刀，Traefik 像会自动识别新设备的智能插排，Kong 更像 API 入口的门禁和调度台。它们并非绝对互斥，实际架构里也常见负载均衡器在外层、Kong 处理 API 策略的组合。
问：只想转发几个接口，Kong会不会太重？
很可能会。若你的需求只是把 example.com/api 转发到一个后端，Nginx 的配置更短、运行组件更少。为了一个 rewrite 装 Kong，属于拿大锤敲图钉。
但当接口开始出现不同调用方、不同限额、统一 API Key、审计日志、版本路由时，Nginx 配置会越来越像一团业务规则。Kong攻略的实用判断线是：同一类网关规则是否已经被三个以上服务重复实现。是的话，集中治理通常就值回复杂度。
问：Kubernetes项目里，Traefik和Kong谁更顺手？
如果团队要的是快速发现 Service、根据 Ingress 或标签自动更新路由，Traefik 的上手感通常很轻。它特别适合容器频繁创建销毁、规则相对简单的环境。
如果团队更在意 API 生命周期、调用方管理、细粒度鉴权、配额和插件生态，Kong 会更贴近需求。前提是团队愿意维护相应的控制面、配置规范和可观测性。别只看“都支持 Kubernetes”这一行，真正的差别在你把什么规则放到入口层。
问：性能对比该怎么看，能不能只看QPS？
不能。空转发压测的 QPS 很好看，但线上请求会经过 TLS、认证、日志、限流、上游连接池，延迟分布才是重点。特别要盯 p95、p99，以及上游变慢时网关是否把连接拖满。
做选型压测时，用同一台机器、同一组上游、相同并发和同等 TLS 条件；分别测试裸转发、开启目标插件、上游注入 200ms 延迟三组数据。再看 CPU、内存、错误率和恢复时间。拿不同版本、不同硬件的网上跑分横比，参考价值接近看热闹。
问：最终怎么选，给一个不绕弯的答案
静态站点、简单反向代理、已有深厚 Nginx 运维积累：优先 Nginx。Docker 和 Kubernetes 服务变化快、主要诉求是自动发现和轻量入口：认真评估 Traefik。多个 API、多个调用方、统一认证限流审计已经变成刚需：Kong 更合适。
无论选谁，都别把网关当万能中间件。业务权限、核心风控和领域规则仍该留在业务或身份系统。网关擅长统一执行入口策略，不擅长承载所有业务判断；这个边界守住了，后面的架构才不会发胖。
推荐阅读
常见问题
Kong可以替代Nginx吗？
部分 API 代理场景可以，但两者定位不完全相同。若有大量静态资源、复杂 Web 服务配置或既有 Nginx 体系，应按实际职责组合或保留 Nginx，而不是机械替换。
Kong和Traefik哪个更适合微服务？
看微服务最痛的点。偏动态发现和容器编排，Traefik很有优势；偏 API 身份、配额、插件治理和开发者调用管理，Kong通常更匹配。
网关会成为单点故障吗？
单实例会。生产环境应通过多副本、负载均衡、健康检查、配置发布回滚和上游超时控制降低风险，同时验证故障切换是否真的生效。