2. 传统网关 vs 云原生网关：架构差异对比与迁移痛点
API 网关从传统单体架构向云原生架构迁移，本质上是将集中式、有状态、静态配置的流量入口，转变为分布式、无状态、动态编排的云原生基础设施层。本章从架构模型、性能模型、稳定性保障和兼容性四个维度进行对比，并提炼出迁移过程中最常见的工程痛点。
2.1 架构模型对比：集中式 vs 分布式
| 对比维度 | 传统网关（如 Nginx/Kong） | 云原生网关（如 Envoy/K8s Ingress） |
|---|---|---|
| 部署形态 | 独立物理机/VM 集群，固定 IP，手动扩缩容 | 容器化 Sidecar/Deployment，自动弹性，声明式管理 |
| 配置管理 | 本地文件 + reload 或数据库 + 轮询 | 控制面 xDS 协议动态推送，热更新无 reload |
| 状态存储 | 本地内存/共享数据库（有状态） | 控制面集中管理，数据面无状态（Stateless） |
| 扩展性 | 插件/模块编译加载，重启生效 | Wasm/Filter 链动态加载，热插拔 |
| 服务发现 | DNS 轮询或手动配置 upstream | 原生集成 K8s Service/Consul/Eureka，自动感知端点变化 |
| 可观测性 | Access Log + 第三方 Agent 采集 | 内置 Metrics/Tracing/Logging，OpenTelemetry 原生支持 |
架构迁移核心认知： 传统网关是“胖实例 + 静态配置”，云原生网关是“瘦数据面 + 智能控制面”。迁移不是简单的版本升级，而是从“运维手动管理”到“平台自动编排”的范式转换。
2.2 性能模型差异：从“单机吞吐”到“网格延迟”
传统网关的性能指标以单机 QPS 和延迟 P99 为核心；云原生网关则更关注网格整体吞吐、Sidecar 资源开销和端到端链路延迟。以下为关键性能差异对比：
| 性能维度 | 传统网关 | 云原生网关 |
|---|---|---|
| 连接模型 | epoll 多进程/多线程，长连接复用 | 事件驱动 + 异步非阻塞，L4/L7 分离 |
| SSL 终止 | 硬件加速卡或 OpenSSL 软件卸载 | BoringSSL + 异步 SSL，支持 TLS 1.3 0-RTT |
| 路由匹配 | 前缀/正则匹配，O(n) 复杂度 | Trie 树/哈希匹配，O(1) 或 O(log n) |
| 限流/熔断 | 单机令牌桶，分布式需额外组件 | 全局分布式限流，基于 xDS 同步 |
| 资源开销 | 单实例 2-4 核，内存 2-8 GB | Sidecar 0.5-1 核，内存 128-512 MB |
| 延迟增加 | 通常 < 1ms（直连后端） | 通常 1-3ms（含 Sidecar 跳转） |
性能迁移陷阱： 云原生网关的 Sidecar 模式会引入额外的网络跳转（iptables 流量劫持），导致 P99 延迟增加 1-3ms。对于毫秒级敏感业务（如高频交易、实时音视频），必须在迁移前进行全链路压测，并考虑 eBPF 或 DPDK 加速方案。
2.3 稳定性保障差异：从“主备切换”到“声明式自愈”
传统网关依赖 Keepalived + VIP 主备或 LVS + Nginx 集群实现高可用；云原生网关则通过 K8s 控制器 + 健康检查 + 自动重启实现声明式自愈。以下为稳定性保障对比：
- 故障恢复时间： 传统网关主备切换需要 5-30 秒（含 VIP 漂移和健康检查）；云原生网关 Pod 重启仅需 1-3 秒，且由 K8s 自动完成。
- 灰度发布： 传统网关通过 upstream 权重调整或蓝绿部署，需要手动操作；云原生网关原生支持金丝雀发布、流量镜像、A/B 测试。
- 配置回滚： 传统网关回滚需要恢复旧配置文件并 reload，期间可能中断连接；云原生网关支持 xDS 版本管理，秒级回滚且连接不断。
- 熔断降级： 传统网关通常依赖 Hystrix 或自研熔断器；云原生网关内置熔断、重试、超时、限流等策略，且支持动态调整。
稳定性迁移建议： 迁移初期保留传统网关作为“冷备”，通过 DNS 权重或全局负载均衡（GSLB）逐步切流。当云原生网关出现稳定性问题时，可快速切回传统网关，避免全量故障。
2.4 兼容性痛点：协议、插件与运维习惯
兼容性是迁移过程中最容易被低估的环节。以下为三大常见兼容性痛点：
| 痛点类别 | 具体表现 | 典型场景 |
|---|---|---|
| 协议兼容性 | 传统网关支持 HTTP/1.1、gRPC、WebSocket、Dubbo 等；云原生网关对 Dubbo/Thrift 等私有协议支持不完善 | Dubbo 服务通过传统网关暴露，迁移后需要额外协议转换或自定义 Filter |
| 插件/扩展兼容性 | 传统网关的 Lua/Java 插件无法直接迁移到 Wasm/LuaJIT 环境 | 自定义鉴权、限流、日志插件需要重新开发或适配 |
| 运维习惯兼容性 | 运维团队习惯 SSH 登录修改配置、查看日志；云原生网关需要适应 kubectl、Dashboard、Grafana | 故障排查从“tail -f access.log”变为“kubectl logs + Jaeger 链路追踪” |
2.5 迁移常见痛点总结
综合以上分析，API 网关迁移过程中最常见的痛点可归纳为以下六类：
- 性能劣化： Sidecar 模式引入额外延迟，P99 从 1ms 升至 3-5ms，需通过连接池优化、本地缓存、eBPF 加速等手段补偿。
- 配置割裂： 传统网关配置与云原生网关配置并存，双写导致配置不一致，需引入配置同步中间层。
- 协议断层： 私有协议（如 Dubbo、Thrift）在云原生网关中缺乏原生支持，需开发自定义 Filter 或协议转换器。
- 可观测性断层： 传统网关的监控指标（如 Nginx stub_status）与云原生网关的 Prometheus Metrics 无法直接映射，需重新定义 SLO 和告警规则。
- 运维技能转型： 运维团队需要学习 K8s、Envoy、Istio 等新工具，短期内故障排查效率下降。
- 回滚复杂度高： 云原生网关配置错误可能导致全集群故障，回滚需要同时恢复控制面和数据面状态，比传统网关 reload 更复杂。