为什么需要在云原生中关注API网关
现代应用开发越来越依赖微服务，一个电商平台可能拆分成商品、订单、用户等多个独立服务。这些服务各自部署在容器里，通过Kubernetes管理，动态伸缩、频繁发布。如果没有统一入口，前端调用后端就像在迷宫里找门——IP变来变去，协议五花八门，权限规则也各不相同。
这时候API网关就派上用场了。它像小区的门禁系统，所有外部请求必须先经过它验证身份、记录访客日志、再转发到具体楼栋。在云原生环境下，这个“门禁”还得能自动识别新入住的楼栋（服务发现），支持高峰期加岗（弹性扩容），甚至能根据访客类型走不同通道（路由策略）。
核心设计原则：轻量、可扩展、自动化
传统网关往往是厚重的中间件，部署一套就得配专人维护。云原生要求的是“即插即用”。选型时优先考虑基于Envoy、Nginx Plus或Kong这类支持Sidecar或DaemonSet模式的方案。比如Kong可以作为Ingress Controller集成进K8s，配置变更通过CRD声明，不需要手动重启进程。
扩展性体现在插件机制上。登录验证、限流熔断、日志收集这些功能不应写死在网关逻辑里，而是以插件形式按需启用。比如促销活动前临时开启更严格的限流策略，活动结束就关闭，不影响其他业务。
典型配置示例
以下是一个Kong Gateway通过Kubernetes CRD定义路由和插件的例子：
apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
name: product-api-route
proxy:
protocol: http
path: /api/products
route:
methods: ["GET", "POST"]
hosts: ["shop.example.com"]接着绑定JWT认证插件：
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: jwt-auth-plugin
plugin: jwt-auth
config:
secret_is_base64: false与服务网格的边界划分
有人会问，Istio不是也有入口控制吗？确实，Istio的Gateway资源也能做类似事情。但通常建议：API网关负责南北向流量（外部进系统），服务网格处理东西向流量（服务间通信）。比如用户从App访问下单接口走API网关，而订单服务调用库存服务则由Sidecar代理完成。两者配合，各司其职。
可观测性不能少
网关一旦上线，就成了流量枢纽。每天多少请求、哪些接口响应慢、有没有异常暴增，都得看得见。集成Prometheus抓取指标，对接ELK输出访问日志，关键路径加上追踪ID透传。某次线上报错，通过trace ID一分钟定位到是鉴权服务延迟升高导致整体超时，这种排查效率远胜于翻几十个日志文件。
实际运维中还常遇到版本灰度问题。新版本接口只放行部分用户测试，可以用网关的条件路由实现。比如根据请求头中的app-version字段分流：
routes:
- name: v2-preview
protocols: ["http"]
paths: ["/api/"]
headers:
app-version: "beta"
service: user-service-v2