网关这个词，做微服务的同学基本都绕不开。在技术群里丢一句“微服务网关选型，5 种主流 API 网关哪个最香”，底下大概率吵翻天：有人站 Kong，有人喊 APISIX，还有人说 Spring Cloud Gateway 挺好用，也有人直接告诉你 Envoy 才是天花板。我看了很多年这类讨论，慢慢发现一个规律——最后吵赢的人往往不是技术最好的，而是团队场景最贴合的那一方。这篇文章不打算给你一个“最香”的定论，而是把 5 种常见网关（Kong、APISIX、Spring Cloud Gateway、Envoy、Traefik）的设计内核、适用边界、常见翻车点一次讲清楚，最后给出一套能落地的选型框架。适合正在做网关调研的架构师、后端开发，以及负责网关运维的同学借鉴。
1. 先搞清楚网关在扛什么活：选型纠结的本质
1.1 网关六项基础职责与三个隐藏成本
网关不是单纯的路由器。在微服务架构里，它至少要承担六件事：路由转发，把外部请求按路径、Header、参数分发到正确的服务实例；负载均衡，服务实例有多副本时做动态权重分配和健康检查；认证鉴权，统一校验 Token、API Key、IP 白名单；限流熔断，防止突发流量打垮下游服务；协议转换，在 HTTP/JSON 与 gRPC、Dubbo 等内部协议之间互转；可观测性，为每个请求产生 trace、日志、metrics，让后续排查有数据可查。
这六件事多数网关都能做，但做的深度差别很大。比如限流，有的网关只支持简单的令牌桶限流，有的能按消费者维度做精细化配额；比如观测，有的网关能无缝对接 SkyWalking、Prometheus 这类工具，有的得自己写插件对接。真正决定选型的往往不是功能列表，而是三个隐藏成本：配置管理成本，网关配置怎么写、怎么上线、怎么回滚，决定你后期每天是否舒服；扩展开发成本，官方插件不够用时，你是否能用熟悉的语言开发自定义插件；升级风险，版本升级、插件兼容、依赖变化，这些坑会在运行半年后集中爆发。
很多团队选型时只盯着功能对比表，忽略了上述成本，结果就是把网关从 A 迁到 B 的时候，整个运维组忙了一个多月。我在帮人做技术评审时，第一个问题永远是“你们现在最痛的三个问题是什么”，而不是“你们喜欢哪个技术栈”。先把痛点点出来，再匹配网关特性，才能避免那种“换了一款网关，旧的问题没解决，新的问题倒冒出来好几个”的尴尬局面。
1.2 用小区门禁来理解“最匹配”而不是“最香”
我常用一个类比来解释网关选型——小区门禁。自建房自己管，随便装个密码锁就行；普通商品房需要一个过得去的门禁机和物业管理系统；写字楼大楼则要考虑人脸识别、访客系统、消防联动、高峰期吞吐，多个系统要对接。你能说写字楼那套门禁最“香”吗？在自建房里它根本装不下，成本也完全没有意义。
选网关也一样。流量性质、团队技术栈、运维投入，这三个前置变量不先讲清楚，谈“哪个最香”就是鸡同鸭讲。流量性质决定你需要多高的性能和什么层级的接入；团队技术栈决定你能不能改动它、接得起它；运维投入决定你是否有能力驾驭它的复杂度。下文分析 5 种网关时，我都会围绕这三条线展开，最后汇总成决策框架。
2. OpenResty 双雄：Kong 与 APISIX 的正面较量
2.1 共同底子：在 Nginx 之上用 Lua 写扩展
Kong 和 APISIX 一个绕不开的共同点是都基于 OpenResty。OpenResty 是 Nginx 加 LuaJIT 的增强版，让你能在 Nginx 处理 HTTP 请求的各个阶段运行 Lua 脚本。这个设计的意义在于：Nginx 本身的并发模型和网络处理能力经过十几年线上验证，单实例扛几万到几十万并发请求都是家常便饭；Lua 脚本则让路由、鉴权、限流等逻辑能以轻量方式嵌入请求生命周期，性能损耗远小于 Java 或 Go 实现的一次代理转发。
Lua 在这两个网关里扮演的是“胶水语言”角色，不参与核心网络 IO，只做业务逻辑。有人担心 Lua 小众，实际上你 80% 的需求都能用现成插件解决，真正需要自己写 Lua 的场景并不多；真到了需要写插件的地步，面对的也就是几百行代码的规模，比从零写一个完整 Java 服务简单多了。OpenResty 系的另一个优势是天然适应高并发长连接，这对于公网流量入口来说是硬指标。
2.2 Kong：插件生态最丰富，但要注意开源和企业版的边界
Kong 是这 5 种里资格最老的，经过多年迭代，积累了非常庞大的插件市场，从认证、限流、日志到转换、安全、流量控制都有现成方案。它支持声明式配置，用 decK 工具把所有配置导出为 YAML，可以放进 Git 做版本管理和 CI 校验。在 Kubernetes 环境下，Kong 提供了 Ingress Controller（KIC），让 Ingress 资源自动同步成网关路由，这一点对已经上了 K8s 的团队非常友好。
Kong 有两种运行模式：传统模式用 Postgres 存配置，提供管理 API，适合动态管理；DB-less 模式则不依赖数据库，配置全在本地 YAML 文件，适合以声明式方式管理基础设施的团队。如果你有较强的配置沉淀需求，我更推荐 DB-less 配合 decK，让网关配置像代码一样评审和发布，每次变更之前先 diff 一下，能看清影响面再动手。
需要注意的边界是：Kong 开源版和商业版之间存在功能分层。部分高级治理能力（比如某些精细的 ACL 策略、企业级安全插件）在开源版里是需要扩展开发的，选购之前一定把插件清单和许可证条款核对清楚。此外，近两年 Kong 社区功能迭代节奏明显放缓，一些新的云原生理念（比如网关和网格融合、多集群统一管理）跟进不算快，这影响了它在新技术团队的欢迎度。
2.3 APISIX：动态化做到极致的云原生进攻者
APISIX 是另一款 OpenResty 系网关，设计取向和 Kong 有明显差别。它把“动态”两个字做到极致：路由、上游、插件、SSL 证书都可以热更新，不需要 reload Nginx 进程。这在发布频繁的业务场景里是刚需——以前 Kong 改一个路由可能要 reload 一次，流量在一瞬间会有毫秒级中断，虽然小，但大促前改配置总是让人心头一紧；APISIX 则完全消除了这个顾虑。
它把控制面数据存在 etcd 里，数据面通过监听 etcd 变更实时拉取新配置。这也是为什么 APISIX 能天然支持 Kubernetes 的 Ingress Controller，Ingress 资源一变，etcd 里的路由跟着变，数据面立刻生效。插件方面，APISIX 内置了一套覆盖面很广的常用插件，包括限流、熔断、WAF、日志、灰度和观测对接，而且都是开源协议直接提供的，没有把核心功能锁在商业版里，这一点相当能打动预算敏感的中小团队。
APISIX 的瓶颈也来自 etcd。etcd 本身是分布式 KV，但如果你只部署单节点，那它就是单点。etcd 一旦不可用，已加载进数据面的路由不会丢，但新的配置下发和变更全部瘫痪。我的建议是：生产环境至少三节点 etcd 集群，并且定时备份快照；同时把“通过管理接口改配置”的权限收敛给 CI/CD，避免在生成环境上直接动手改。很多团队栽在 etcd 上，不是 etcd 不够稳，而是没人把它当核心组件来运维。
2.4 两者的快速选择法
Kong 和 APISIX 的性能处在同一量级，常规硬件下都能跑出非常可观的 QPS。真正的分水岭在生态成熟度和云原生亲近度：Kong 插件生态大、企业支持完善，适合希望“少折腾、有商业兜底、已有 Postgres 运维习惯”的团队；APISIX 更强调动态化、云原生、开源完整度，适合已经拥抱 Kubernetes、希望网关配置像代码一样热同步的团队。如果硬要说一个倾向，近年新启动的微服务项目里，选 APISIX 的比例明显更高。
| 对比维度 | Kong | APISIX |
|---|---|---|
| 核心存储 | Postgres / DB-less | etcd |
| 配置热更新 | 部分（结合 decK/DB） | 支持，无需 reload |
| 插件生态 | 大而全，开源+商业分层 | 覆盖面广，开源默认内置 |
| 云原生集成 | 提供 KIC 和 Helm | Ingress Controller 集成更紧密 |
| 学习门槛 | 中，资料丰富 | 中，文档较新但友好 |
| 典型适用 | 需要成熟生态、有 Postgres 运维能力的团队 | Kubernetes 原生部署、追求动态化的团队 |
3. Spring Cloud Gateway：Java 生态的守门人，不该被拉去扛公网流量
3.1 它想做的是 Java 微服务内部的“总调度楼”
很多 Java 团队用 Spring Cloud Gateway 并不是因为它性能有多强，而是因为它和 Spring 生态无缝衔接。你在项目里已经有 Nacos 或 Eureka 做注册中心，有 Spring Security 做认证，有 Spring Boot 的配置管理体系，那再引入 Gateway，学习成本极低。它基于 Spring WebFlux，底层是 Reactor Netty，属于响应式编程模型，线程占用少，适合 IO 密集型场景。
它的核心模型是 Route（路由）、Predicate（断言）和 Filter（过滤器）。路由规则可以写在配置里，也可以通过代码定义。断言工厂很丰富，比如按 Path、Method、Header、Host、时间窗口、客户端 IP 等条件路由；过滤器链则能在转发前和转发后插入逻辑，实现鉴权、改写、限流等能力。给你看一份最小配置示例，感受一下它的使用方式：
spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/order/** filters: - StripPrefix=1 - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20这段配置的意思是：凡是 /api/order/** 的请求都路由到 order-service 这个注册中心里的服务，并去掉路径前缀，再套一个基于 Redis 的限流过滤器。对熟悉 Spring 的工程师来说，这套模型几乎没有理解门槛。这里要特别说明限流的实现：RequestRateLimiter 底层依赖 Redis 和 Lua 脚本计数，用的是令牌桶思路，所以你的限流能力受 Redis 吞吐影响。就有团队在网关压到好几万 QPS 时，发现 Redis 的读写延迟明显抬升，最后只能扩容 Redis 并做分片。
3.2 为什么 Java 团队总想拿它扛公网流量，然后翻车
如果说 OpenResty 系是冲锋衣，Spring Cloud Gateway 更像西服套装——得体、精致，但你不能穿着它去攀岩。公网流量入口的场景，核心诉求是三个：极高的并发吞吐、极低的转发延迟、极强的稳定性。Java 进程在高峰期会产生 GC 停顿，Reactor Netty 的网络处理能力虽然不错，但和 Nginx 比仍有量级差距。更现实的问题是：当路由规则很多、过滤链很长时，Java 的对象分配和框架开销会线性增长，而 Nginx 模式下的 Lua 开销要小得多。
这不代表 Spring Cloud Gateway 不好，而是它不应该待在公网边缘。如果你前面挂了一台高性能入口（Nginx、云负载均衡、Kong 或 APISIX），后面用 Spring Cloud Gateway 做内部服务聚合、灰度切换和 BFF 层，那它就是个好帮手。用它直接承接公网流量，配合 WAF、持久化限流、大流量风控这些需求时，你会发现开源版并不擅长，得自己堆很多定制代码，最后维护成本一点不比换网关低。
它的配置变更也不是热更新的。修改路由规则后，要么刷新上下文，要么重启服务，这在发布频繁的团队里是很别扭的一件事。相比之下，APISIX 和 Traefik 的动态更新体验就好得多。所以如果你所在的团队有“秒级发布”的诉求，Spring Cloud Gateway 先天就不太匹配，除非你愿意做二次开发实现自己的动态路由存储。
3.3 真正适合它的三个场景
结合我的观察，Spring Cloud Gateway 最适合以下三种场景：一是 Java 技术栈为主的团队，不希望在网关层引入新语言和新文化；二是服务数量多但流量不大（每秒几千到一两万请求以内）的内部路由编排；三是团队已经有 Nacos/Eureka、Sentinel 这类 Spring 生态组件，希望网关和它们无缝打通。
它的另一个突出优势是开发速度。Java 工程师对 Filter、Predicate 太熟悉了，做个路由改动，加上灰度策略，常常半天就能上线一套规则。而同样的功能在 Kong 或 APISIX 里，要么找现成插件，要么得学习 Lua 插件写法，沟通成本明显更高。所以我说它是“守门人”——管的是内部秩序，不是外面的洪峰。定位摆正了，它是一款效率非常高的工具；定位摆错了，它就会变成瓶颈本身。
4. Envoy 与 Traefik：云原生体系里的两种完全不同的哲学
4.1 Envoy：高性能数据面发动机，但它不是一台整车
Envoy 的设计哲学和前面几种截然不同。它是 C++ 写的高性能代理，工作在 L3/L4/L7 层，核心能力包括动态服务发现、负载均衡、TLS 终止、HTTP/2 和 gRPC 转发、熔断、限流、广泛的可观测性输出。它的出色性能几乎不需要质疑，配合 xDS 协议，控制面可以像下发配置一样动态调整代理的所有行为，包括监听端口、路由规则、集群成员、超时参数等。
但这里有个关键点：Envoy 本身不是“开箱即用的 API 网关”。它没有一个管理 API 让你去创建路由、配置插件、看日志，只有原始的数据面和一套 xDS 协议接口。你想把它用成 API 网关，必须有一个控制面去生成 xDS 配置，这个控制面可以是服务网格产品、云厂商托管的网关，甚至是你自己开发的服务。换句话说，Envoy 是发动机，不是整车，你得自己造驾驶舱、方向盘和仪表盘。
所以 Envoy 适合的是这样的团队：有较强的平台工程能力，愿意投入时间构建控制面；流量规模大到需要极致性能和连接管理；业务中已经存在 gRPC、多协议、大量长连接等复杂网络需求。对大多数业务团队来说，直接上 Envoy 更像开赛车——性能是好，但维护成本不是一般团队能长期扛住的。我见过一个团队推进 Envoy 后，前期三个月都在和 xDS 配置、集群资源管理搏斗，期间网关一有风吹草动就得回查一大串配置链。
4.2 Traefik：把“能自动跑起来”写进基因的轻骑兵
和 Envoy 相反，Traefik 的出发点非常务实：让网关在容器环境里“能自己跑起来”。它用 Go 实现，天生对 Docker、Kubernetes 等平台的服务发现机制有深度集成。你只要给容器打上标签，或者在 K8s 的 Ingress 资源上写几条注解，Traefik 会自动生成对应的路由和负载均衡规则，连 TLS 证书都能自动申请续期。
对很多中小规模团队来说，Traefik 的入门体验是无敌的。不需要设计路由表，不需要管理配置中心，容器起停、服务上线，路由自动更新。它也有中间件机制，可以完成限流、熔断、认证、改写之类的常见操作。用 Kubernetes 时，你甚至可以不装其他 Ingress Controller，直接让 Traefik 接管入口流量。
Traefik 的短板也很明显：相比 Kong/APISIX，它的插件生态和治理深度要薄一些；如果要面对复杂的多租户权限、细粒度流控、企业级审计，开源版需要不少扩展开发。性能方面，Go 实现的代理单实例能扛住的 QPS 并不低，但在极端峰值下和 Nginx/Envoy 这类底层架构相比仍有差距。不过很多团队的瓶颈根本不是网关，所以 Traefik 足够用了。对“想快速在 K8s 里有一个能用网关”的团队，Traefik 就是那个最省心的选项。
4.3 一张表看清 Envoy 与 Traefik 的分工
| 对比维度 | Envoy | Traefik |
|---|---|---|
| 定位 | 高性能数据面组件，需配控制面整车 | 开箱即用的云原生边缘/入口网关 |
| 上手难度 | 高，需理解 xDS 与控制面 | 低，K8s/Docker 自动发现 |
| 性能 | 极强，适合大流量、长连接、gRPC | 中等偏上，普通业务足够 |
| 扩展生态 | 通过控制面和自定义过滤器扩展 | 中间件机制，生态较年轻 |
| 典型使用 | 服务网格数据面、云原生大流量入口 | Kubernetes 场景快速接入、中小规模网关 |
两者经常被放一起比较，是因为都属于云原生新时期的产物，都强调动态配置，但一个偏“底层能力强、控制面复杂”，另一个偏“上手快、运营简单”。理解了这个分工，就不会再被“Envoy 是不是 Traefik 的升级版”这种问题带偏了。它们服务于不同体量和不同能力的团队，硬比高下反而没有意义。
5. 五款网关核心能力横向对比：不要被纸面参数骗了
5.1 性能、扩展、治理的六维对照
下面这张表是结合公开资料和实际踩坑经验整理的，关注的是“架构源生能力”而非“宣传话术”。务必记住，数据只是量级参考，实际差距受硬件、路由规则数量、日志打开程度影响巨大。
| 维度 | Kong | APISIX | Spring Cloud Gateway | Envoy | Traefik |
|---|---|---|---|---|---|
| 基础架构 | OpenResty/Lua | OpenResty/Lua | Java/Reactor Netty | C++ | Go |
| 配置热更新 | 部分 | 强 | 弱（需刷新） | 强（xDS 动态） | 强（provider 自动） |
| 服务发现集成 | DNS/Consul/K8s 等 | DNS/Nacos/Consul/K8s | Nacos/Eureka 等 Spring 生态 | 原生支持集群发现 | Docker/K8s/Consul 等 |
| 限流能力 | 插件多，需选型 | 内置令牌桶等，较强 | Redis+Lua，受 Redis 影响 | 内置较基础，需控制面配合 | 中间件限流，简单够用 |
| 可观测性 | 插件对接主流 | SkyWalking/Prometheus 等 | Spring 生态成熟 | 原生高吞吐指标 | 基础 metrics，扩展靠中间件 |
| 单实例性能量级 | 几十万 QPS | 几十万 QPS | 1-2 万 QPS 以上仍可，但瓶颈明显 | 极高（数十万至百万级） | 中等偏高 |
入门容易度和治理深度其实是反比关系。Traefik 和 Spring Cloud Gateway 入门最快，但治理深度有限；Envoy 治理潜力最大，但入门成本最高；Kong 和 APISIX 是“性能、生态、复杂度”三者平衡得最好的两个选项，这也是它们能占据市场份额的原因。
5.2 “性能”这个指标最容易被误读
我见过不少团队选型时只盯着压测数据拉踩，看完 Nginx 系的数据就觉得稳了。但真实线上的瓶颈很少出现在网关，多半在下游业务服务和数据库。网关一旦变成瓶颈，往往意味着架构成问题——把所有请求都灌进了网关，而网关连一个简单的透传都扛不住。压测时建议把下游服务用固定延迟桩代替，单纯测量网关自身的转发能力和 CPU/内存占用，这样才能得到接近真实的数据。
另外，“性能”也要拆开看。如果是几百个并发连接的场景，Java 网关完全够用；如果是一万以上并发连接，Nginx 系优势明显；你要处理的是几十万连接的长连接推送服务，那么 Envoy 这种为高连接数设计的代理才合适。脱离流量模式和连接特征谈 QPS，没有参考价值。还有一点容易被忽略：开启全量日志、WAF 规则、详细指标采集后，任何网关的性能都会打折，所以压测时要用接近生产的配置来测。
5.3 一张自检清单，帮你看清团队的真实需求
- 网关要接入公网流量吗？如果只做内部路由，性能权重可以大幅下调
- 团队对配置变更频率要求多高？有秒级热更新需求的，优先 APISIX这类动态控制面方案
- 是否需要和云原生基础设施深度集成？已有标准 K8s 集群的，Traefik/APISIX 的 Ingress 方案最顺
- 是否需要 WAF、风控、限流之外的高级安全管控？需要的话，OpenResty 系插件优势明显
- 有没有专职网关运维？没有的话，Traefik 或托管类网关更适合，Envoy 要谨慎
把这些问题答完，往往不用做几十页对比 PPT，选型方向已经很清楚了。
6. 按团队基因选型：四步决策法
6.1 先划流量性质，再谈技术栈
我把决定口径做成了四步决策法，你可以在评审会上直接拿来引导讨论：
- 判断流量性质。公网边缘流量入口、需要扛瞬时峰值，基本淘汰 Spring Cloud Gateway，优先考虑 Kong/APISIX/Envoy（或者云负载均衡加网关的组合）；流量只发生在内网微服务之间，Java 团队直接用 Spring Cloud Gateway 是合理选择。
- 看团队运维能力。能管理好 etcd 集群并愿意接受配置中心概念的，APISIX 或 Envoy 都算匹配；希望配置就是 Git、回滚靠 CI 的，Kong DB-less 或声明式 Traefik 更好。
- 数清功能需求。需要插件开箱即用的场景，从 Kong/APISIX 的插件市场里挑即可；需要深度定制网关行为的，Kong 和 APISIX 都支持 Lua 插件，Envoy 则需要你理解过滤器链模型，Traefik 的中间件扩展面较窄。
- 考虑长期演进。团队未来会不会引入服务网格？如果会，Envoy 作为数据面的兼容性更平滑，因为它是网格生态里更主流的选择。
这套流程的核心是“先划流量性质，再谈技术栈”。如果一上来就聊“我喜欢 Go”“我讨厌 Lua”，讨论就会变成技术偏好之争，而不是选型决策。把流量性质和运维成本放在最前面，技术栈偏好退后一步，最后落到功能需求的匹配度上，结论会清晰得多。
6.2 那“如果只选一个”呢？
我经常被人追问：“如果只选一个，你推荐哪个？”我的回答是：不存在通用的唯一答案。但如果被逼在一个大而全的选项里做选择，我会倾向 APISIX——它在性能、动态化、开源完整度、云原生集成这四个维度上都站得住脚，没有明显短板。它不像 Kong 那样依赖版本来限制高级能力，也不像 Spring Cloud Gateway 那样不适合大流量，更不像 Envoy 那样需要庞大控制面投入，治理深度也比 Traefik 更强。这个选择的前提是你愿意接受 etcd 作为配置存储，并且有一定 Kubernetes 运维能力。
如果你的团队是纯 Java 且永远不想碰 Lua、etcd 这些词，那么 Spring Cloud Gateway 确实是你团队的“真香”，只要你别把它放到公网边缘；如果你想要极致的性能和极简运维之间的平衡，Traefik 的兜底能力也很强；如果你正在搭建服务网格或需要处理百万级连接，那 Envoy 的优势无可替代。说到底，选型不是比谁参数高，而是比谁和团队基因更合拍。
7. 踩坑实录：六条来自现场的网关翻车经验
7.1 用 Spring Cloud Gateway 扛公网流量，高峰期直接雪崩
这个案例来自一个做电商的朋友团队。他们的网关用 Spring Cloud Gateway，平时 QPS 不高，一切安好，但大促场景下瞬时流量冲到两三万，先是 Redis 限流链路的延迟飙升，接着 Reactor Netty 的事件线程池被打满，部分请求进入队列，最终一路超时传导到下游。排查结论很直白：Java 网关不适合公网峰值流量场景，尤其是带长过滤链和 Redis 限流时。他们最后的方案是在公网入口加了 OpenResty 系网关扛流量，Spring Cloud Gateway 退回到内部 BFF 层，问题才彻底解决。
7.2 APISIX 的 etcd 单点：配置中心不能用“能用就行”的心态配
有一个团队把 APISIX 的 etcd 部署成了单节点，想着数据量也不大，没必要上集群。结果一次节点重启，etcd 数据目录损坏，虽然网关转发没中断，但任何路由变更都无法生效，运维团队只能通过数据面节点手工改配置临时止血。之后他们上了三节点 etcd 集群，并定期备份快照。经验是：基于 etcd 的组件，高可用不是“重要”而是“必须”，别在这个环节省成本。etcd 看似只是存储，实际上它是整个控制面的心脏。
7.3 Kong DB-less 下配错插件，回滚晚了十几分钟
Kong 的 DB-less 模式配合 decK 很好用，但如果你把配置写坏，可没有管理 API 让你一键改回来，得靠 Git 回滚版本后重新 apply。我见过一个同事写配置时少了一个逗号，CI 没检查出来，部署上去后网关直接返回 500，由于团队没有提前做“配置校验+金丝雀部署”，恢复花了十几分钟。现在他们加了两道保险：decK diff 先预览变化，CI 里跑配置的 schema 校验，生产发布时先灰度一台数据面节点。这样的流程多花不了多少时间，但能把事故影响面缩小到一台机器，而不是整个网关集群。
7.4 Envoy 控制面配置错误引发全集群路由抖动
Envoy 的 xDS 配置是强一致下发的，一旦控制面生成的配置有误，错误会被分发到所有数据面节点，影响面是全局的。某个基础架构团队在调整路由优先级时，把一条路由的 VirtualHost 写错，导致该域名的流量全部打到错误后端。好在他们在控制面侧增加了配置 schema 校验、diff 预览和分批下发机制，很快定位了问题。Envoy 不是“写错了重来”的游戏，控制面必须有完善的校验和发布流程。想用它做网关就要接受这个前提：平台工程能力是硬门槛，不是锦上添花。
7.5 Traefik 开源版的高级治理缺口：业务复杂后就只能缝缝补补
一个使用 Traefik 做 K8s 入口的团队，前期一切都很顺利，直到业务开始需要多租户权限、细粒度审计、按消费者维度的差异化流控，发现开源版里没有直接可用的方案，只能靠中间件组合和外部组件拼凑。后来他们还是迁移到了功能更全的网关产品。教训是：如果你预见到业务一年后会复杂起来，选型时就要把治理深度放到和性能同等重要的位置，不要只看“能不能跑起来”。所谓“先跑起来再说”往往意味着几个月后的迁移成本。
7.6 通用铁律：观测先行，灰度后上，配置入 Git
无论最后选哪一款，这三个动作都是保命符。观测先行——网关上线第一天就要有完整的日志、指标、链路追踪，没有这些信息，遇到故障就是盲人摸象。灰度后上——任何配置变更都先发一台节点验证，再扩大范围，哪怕是加一条路由规则也要走这个流程。配置入 Git——网关的所有配置都用代码管理、走 CI 校验、支持一键回滚。听起来是常识，但我在不同团队里至少见过三次因为忽略它们而付出代价的案例。把这些当成本能，比选对一款网关更重要。
写完这些，我还是要说一句个人体会：网关选型这个事，做任何对比都不如拿真实流量做一次压测来得实在。挑一个几周后的低峰窗口，把候选网关接入镜像流量或灰度流量，起一套压测脚本，看看实际转发延迟、CPU 占用、连接数，你就知道纸面参数和现实的差距有多大了。选型的答案不会因为你把 PPT 翻到最后一页出现，它一定会在你们团队的实际场景里长出来。
