1. 云原生网关概述

1.1 什么是云原生网关

云原生网关是面向微服务架构与容器化部署环境设计的统一流量入口层,它承担着南北向流量(客户端到服务端)的接入、路由、安全、可观测性等职责。与传统 API 网关不同,云原生网关从设计之初就与 Kubernetes、服务网格等基础设施深度集成,能够动态感知后端服务的扩缩容、健康状态与版本变更。

核心定义:云原生网关 = 流量代理 + 服务发现 + 动态路由 + 安全策略 + 可观测性,且全部以声明式 API(如 Kubernetes Ingress / Gateway API)进行配置管理。

1.2 与传统网关的核心区别

下表从架构、部署、运维三个维度对比传统网关与云原生网关的关键差异:

对比维度 传统网关(如 Nginx 静态配置) 云原生网关(如 Envoy / Kong / APISIX)
配置方式 手动编辑配置文件,重启或 reload 生效 声明式 API(Ingress / Gateway API),热更新无需重启
服务发现 依赖 DNS 或外部注册中心,变更延迟高 原生集成 Kubernetes Service / EndpointSlice,秒级感知
弹性伸缩 需手动扩缩容实例,或借助第三方编排 基于 HPA 自动扩缩,Pod 生命周期与路由同步
可观测性 依赖插件或外部日志收集,指标粒度粗 内置 Prometheus / OpenTelemetry,全链路追踪与细粒度指标
安全策略 IP 白名单、基础认证,策略静态 mTLS、OAuth2、JWT 校验、RBAC,策略动态下发
部署形态 物理机 / 虚拟机,固定 IP 与端口 容器化 Sidecar / DaemonSet,与集群网络扁平化

1.3 在微服务架构中的核心价值

云原生网关在微服务架构中扮演着流量枢纽与策略执行点的双重角色,其核心价值体现在以下五个方面:

  1. 统一入口与路由:所有外部请求经过网关,按 Host、Path、Header 等条件分发至对应微服务,消除客户端对后端拓扑的依赖。
  2. 流量治理:支持灰度发布、蓝绿部署、限流降级、熔断重试,保障服务稳定性。
  3. 安全防护:在网关层集中实施身份认证、TLS 终止、WAF 规则,避免安全逻辑散落在各个微服务中。
  4. 协议转换:将外部 HTTP/HTTPS 请求转换为集群内部的 gRPC、Dubbo 或 TCP 协议,适配异构服务。
  5. 可观测性:在入口处采集请求延迟、错误率、吞吐量等黄金指标,为 SRE 提供统一监控视图。
实践建议:在 Kubernetes 集群中,优先使用 Gateway API 替代传统 Ingress v1,以获得更精细的路由规则、跨命名空间支持和后端协议协商能力。

1.4 云原生网关架构示意

下图展示了云原生网关在 Kubernetes 集群中的典型部署位置与流量路径:

云原生网关架构图 外部客户端 云原生网关 路由 / 限流 / 认证 TLS 终止 / 协议转换 可观测性采集 微服务 A 微服务 B 微服务 C Sidecar Proxy (Envoy / Linkerd) Sidecar Proxy (Envoy / Linkerd) Sidecar Proxy (Envoy / Linkerd) 架构说明 云原生网关作为集群唯一入口,将外部请求路由至后端微服务;服务网格 Sidecar 负责东西向流量控制与 mTLS。

1.5 典型应用场景

  • 多环境统一入口:开发、测试、生产环境共用同一网关实例,通过路由规则隔离流量。
  • 金丝雀发布:将 5% 流量导向新版本服务,验证无误后逐步切量。
  • 跨集群路由:网关根据地理位置或延迟,将请求分发至不同区域的 Kubernetes 集群。
  • API 版本管理:通过 Header 或 URL 前缀区分 v1/v2 版本,后端逐步迁移。
注意:云原生网关并非银弹。对于内部服务间的东西向流量,应优先使用服务网格(Service Mesh)而非网关代理,避免引入不必要的延迟与单点瓶颈。