微服务接入层的两层网关：概念、界线与全产品图谱
发表架构44 分钟读完 (大约6665个字)0次访问

微服务接入层的两层网关：概念、界线与全产品图谱

在微服务架构中，入口网关是绕不开的核心基础设施。从早期的 F5 硬件负载均衡，到 Nginx 一统江湖，再到 Spring Cloud Gateway 成为 Java 生态标配，直到如今云原生时代 Ingress Controller 与 Service Mesh（服务网格）百花齐放——接入层技术栈虽日新月异，但其内在的逻辑分层从未改变：外层抗流量，内层治业务。

本文不聊具体产品的选型对比，只梳理硬核架构知识：两层网关的本质界线在哪，L4 与 L7 如何分工，以及在从传统数据中心（IDC）向 Kubernetes（K8s）演进的过程中，市面上的硬件、开源软件、商业产品及云厂商托管服务应该如何合理排布。

一、 核心界线：静态 Upstream vs 动态服务发现

1.1 经典接入拓扑

1
2
3
4
5
6
7
8
9
公网
│
▼ L4 流量网关  ── DDoS 防护、CPS 限速、并发连接控制、四层 LB
│               F5 / LVS / 云厂商 NLB (网络负载均衡)
▼ L7 流量网关  ── TLS 卸载、WAF 防护、CC 防御、Path/IP 流控、静态路由
│               Nginx / Kong / APISIX / Higress
▼ 微服务网关    ── 服务发现路由、业务鉴权、API 限流、灰度发布、熔断降级
│               Spring Cloud Gateway / ShenYu / Kong / APISIX / Higress
▼ 业务服务      ── 注册在 Nacos / Eureka / Consul / K8s Service

1.2 定位与界线对比

维度流量网关（L4 + L7）微服务网关
架构位置最外层，直面公网流量流量网关之后，贴近业务集群
上游类型（核心分水岭）静态 IP / VIP / 域名
（Upstream 手工维护或依赖静态 DNS）		动态服务注册表
（Nacos / Eureka / Consul / K8s Endpoints）
路由依据L4：网络五元组（源/目的 IP、源/目的端口、协议）
L7：域名 + Path + Header		服务名（如 lb://order-service）
+ Path / Header / 权重控制
是否对接服务发现❌ 不直接接入✅ 必须原生接入
流控粒度L4：带宽、CPS、连接数
L7：基于 IP/Path/Header 维度的 QPS 防御		API QPS、线程隔离、服务级熔断、退避重试
（精准控制到服务实例维度）
防护对象DDoS（L4 泛洪）、WAF 注入与恶意刷量（L7）业务域：防刷接口、防服务过载、故障隔离
业务耦合度无（Path 仅作为字符串匹配，不感知业务语义）紧耦合（感知服务名、API 契约、业务鉴权体系）

📌 那条核心分水岭：

  • proxy_pass http://10.0.0.1:8080; → 流量网关（硬编码或静态配置）。
  • proxy_pass http://cluster.local; → 流量网关（虽然依赖 K8s 内部 DNS 解析，但对网关内核而言仍是标准的静态域名配置，无法动态感知后端 Pod 实例的实时变更）。
  • lb://order-service 并从 Nacos/Eureka 实时拉取/订阅实例列表 → 典型微服务网关。

判断的标准只有一个：Upstream 的地址列表是静态配置/静态 DNS 解析的，还是动态从注册中心 Watch/拉取出来的。

二、 流量网关：L4 与 L7 的职能拆分

2.1 L4（四层）流量网关

工作在传输层（TCP/UDP），不对 HTTP 等应用层协议内容做深包解析。其流控与负载均衡策略完全基于传输层状态：带宽、CPS（每秒新建连接数）、并发连接数等。

类别代表产品形态授权模式当前主流地位（社区与采用面）
硬件F5 BIG-IP LTM专用硬件商业收费行业传统老大，金融及大型企业数据中心标配
硬件Citrix NetScaler (ADC)专用硬件商业收费金融、电信行业传统高可用方案多见
硬件A10 Thunder ADC专用硬件商业收费传统政企、大型私有云数据中心
硬件Array APV专用硬件商业收费国内部分政企与传统行业偶见
软件LVSLinux 内核模块开源免费传统大厂自建软负载的高性能标配方案之一
软件DPDK 系用户态 LB软件部分开源超大厂自建、追求极致单机四层性能的主流方向
云托管AWS NLB / 阿里云 NLB / 腾讯云 CLB / 华为云 ELB云原生托管按量付费公有云环境基础设施的事实标准

2.2 L7（七层）流量网关

能够深度解析应用层协议（HTTP/HTTPS/gRPC/HTTP2 等），负责 TLS 卸载、WAF 防护、CC 防御和高级静态路由。只要它不直接对接服务发现注册中心，其充当的就是 L7 流量网关的角色，传统如纯 Nginx 容器即属于此类。

类别代表产品核心内核授权模式当前主流地位
软件NginxC核心开源 / Plus 商业互联网 L7 流量层的绝对统治者
软件HAProxyC开源 / 企业版订阅纯粹、极致的高性能七层负载均衡器
软件OpenRestyNginx + LuaJIT开源免费Nginx 生态可编程扩展的事实标准
软件KongOpenResty / Lua开源 / 企业版收费开源 API 网关的老牌标配，插件生态极其丰富
软件Apache APISIXNginx + etcd + Lua开源免费国内大厂、云原生高并发架构的热门首选
软件HigressEnvoy + Wasm开源免费阿里生产环境沉淀，AI 时代演进极迅速
软件TraefikGo开源 / Enterprise 收费紧跟云原生微服务生态，配置简单且开箱即用
云托管AWS ALB / 阿里云 ALB / 腾讯云七层 CLB / 华为云七层 ELB云原生托管按量付费云上便捷首选，通常与各云厂商的 WAF 深度联动

⚠️ 关于“两栖”跨类网关产品的特别说明：

读者会发现 Kong、APISIX、Higress 这三款产品同时出现在了 L7 流量网关和微服务网关的列表中。

  • 当你将它们作为 Nginx 的替代品，在配置文件中写死静态 Upstream IP 或集群 VIP 时，它们扮演的是 L7 流量网关。
  • 当你开启它们的服务发现插件（如对接 Nacos），或者让它们在 K8s 中直接 Watch Pod Endpoints 时，它们就演变成了 微服务网关。

这种“两栖”特性，正是如今业界提倡的 “融合网关” 或 “云原生网关” 的技术底座。

三、 微服务网关：从服务名到业务治理

微服务网关不关心具体的底层物理 IP，它面向 服务名（Service Name） 编程。其核心任务是将请求中的业务标识（如 order-service）动态翻译成具体的 Pod 或 VM 实例列表，并在此基础上执行精细化的 业务治理 ：业务鉴权（JWT / OAuth2 / OIDC）、API 限流熔断、灰度发布（蓝绿/金丝雀）、重试机制与调用链追踪。

3.1 开源与商业软件

产品技术栈服务发现集成能力授权模式当前主流地位
Spring Cloud GatewayJava (WebFlux)✅ Nacos / Eureka / Consul开源免费Java 生态的传统标准，传统虚拟机架构下应用面极广
Netflix Zuul 2.xJava (Netty 异步)✅ Eureka开源免费虽有异步版本，但在国内微服务社区已基本边缘化
Apache ShenYuJava✅ Nacos / Eureka / Consul开源免费国内 Java 生态中主打多协议转换的网关备选方案
KongOpenResty / Lua⚠️ 插件式扩展 (Consul / K8s)开源/商业云原生网关老牌三强之一，企业级应用广泛
Apache APISIXNginx + etcd + Lua⚠️ 插件式扩展 + K8s CRD开源/商业现代高性能网关标配，迭代高度活跃
HigressEnvoy + Wasm✅ Nacos / ZK / Consul / K8s开源免费阿里开源新秀，云原生与 AI 网关方向的代表性产品
Envoy（原生内核）C++✅ 必须依赖控制面 (Istio 等)开源免费现代服务网格与新型云原生网关的数据面事实标准

3.2 云厂商原生托管产品（API 网关）

云厂商托管产品名称架构定位与备注
阿里云云原生 API 网关最新整合品类。全面合并了原「经典 API 网关」与基于 Higress 的「MSE 云原生网关」，主打流量、微服务、安全、AI 四合一的高度融合托管形态
腾讯云云原生智能网关（MCP网关）旗下整合两条托管产品线：基于开源 Kong 演进的云原生网关，以及原生集成了 AI 治理、大模型路由与 MCP 协议的 AI 网关
华为云APIG (API 网关) 专享版核心政企方案。其**【专享版】**规格原生提供了完全隔离的物理实例，具备跨 VPC 打通内部容器网络并动态 Watch K8s 集群服务 Endpoints 的专属能力
AWSAmazon API Gateway海外主流。配合托管 K8s (EKS) 时，通常通过 VPC Link 机制 与容器内部的私有四层/七层 LB 建立私有集成（Private Integration），将公网治理与集群微服务发现完美解耦
GCPCloud Endpoints / API Gateway深度融合 gRPC、OpenAPI 规范驱动的架构设计体系
AzureAzure API Management (APIM)侧重企业级 API 全生命周期管理、安全合规与资产化管理

四、 三种部署场景下的产品拓扑映射

部署场景L4 流量网关L7 流量网关微服务网关
传统 IDC / 虚拟机F5 / Citrix / LVSNginx / HAProxySpring Cloud Gateway / ShenYu
云 IaaS 虚拟机云厂商 NLB / 四层 LB自管 Nginx / Kong / APISIX on ECS自管 Spring Cloud Gateway / ShenYu on ECS
Kubernetes (K8s)云厂商 LB (Service Type=LoadBalancer)Ingress Controller
(Nginx / Kong / APISIX / Higress)		直接融进 Ingress 融合层
(Spring Cloud Gateway 在此场景下已深度边缘化)

五、 Kubernetes 带来的认知跃迁：Ingress 就是融合网关

这是理解现代微服务网关架构演进 最核心的质变点：Kubernetes 的 Service 与 Endpoints 机制，在基础设施层直接取代了传统微服务网关的“服务发现”职责。

对比两者的流量控制链条变化：

  • 传统 VM 架构中：
    Nginx (静态 IP 转发) ──> Spring Cloud Gateway (读取 Nacos 服务发现) ──> 业务实例 VM
  • Kubernetes 架构中：
    云厂商四层 LB ──> Ingress Controller (直接监听 K8s Service Endpoints) ──> Pod 实例

由于 Ingress Controller 运行在 K8s 集群内部，天然通过 API Server 实时 Watch 容器的 Endpoints（即动态变化的 Pod IP 列表）。这一改变带来了三大架构颠覆：

  1. Nginx Ingress Controller 不再是单纯的 L7 流量网关。虽然其内核依然是 Nginx，但它通过控制面组件动态刷新配置并感知 Pod 的扩缩容。它实际上已经把传统微服务网关的“路由动态发现”职责收入囊中。
  2. Kong / APISIX / Higress 在 K8s 中天然就是“融合网关”。它们通过自定义资源（CRD）或直接监听 API Server 处理服务发现，同时在同层处理 TLS 卸载、WAF 防护和高级业务路由，彻底打通了两层网关的边界。
  3. Spring Cloud Gateway 在纯 K8s 架构中显得臃肿且冗余，已被深度边缘化。

5.1 深度拆解：为什么有了 K8s 基础设施层，Spring Cloud Gateway 难逃被边缘化的命运？

很多从传统 Java 微服务体系转型到云原生的团队，往往习惯性地把 Spring Cloud Gateway 塞进容器集群中，但这在现代架构中是一种严重的“叠 Buff”误区：

  • 网络通信多了一次代理跳转（Hop）：流量打进 K8s 之后，已经经过了云厂商四层 LB 和 Ingress Controller 的七层解析转发。如果中间再夹一层 Spring Cloud Gateway，流量必须在容器集群内部再发起一次完全不必要的网络转发，平白增加了系统的整体响应延迟（Latency）。
  • 服务发现职责完全重叠：Spring Cloud Gateway 的历史使命是在 VM 时代通过 Eureka/Nacos 解决动态 IP 路由问题。而在 K8s 内部，Service 和 Endpoints 原生解决了这一痛点。现代云原生网关（如 Higress/APISIX）可以直接 Watch 集群 Pod IP，Spring Cloud Gateway 引以为傲的服务发现在底层基础设施面前沦为多余。
  • JVM 虚拟机的高昂性能开销与 GC 毛刺：网关是直面海量公网流量的“抗流大闸”，对性能要求极高。Spring Cloud Gateway 作为 Java 进程，空载即需数百兆内存，且在高并发大流量下会产生数以百万计的临时对象，极易引发频繁的垃圾回收（GC），从而导致网关层产生无法预测的瞬时毛刺抖动。这与基于 C++ 原生内核（Envoy/Higress）或 C+Lua 架构（Nginx/APISIX）单机仅需几十兆内存、零 GC 的极致稳定性相比，存在天然的技术代差。

5.2 厘清另一个关键的选型真相

既然 Spring Cloud Gateway 被边缘化了，那我们直接用官方自带的 Nginx Ingress Controller 就可以了吗？答案是否定的，大厂往往同样不倾向于直接使用它。

核心原因在于，Nginx Ingress Controller 仅仅把“底层路由发现”的活儿给干了，但在微服务网关更高级的“业务治理能力”上表现得非常薄弱。例如：企业级灰度发布（精细化权重控制与 Header 染色）、动态鉴权（JWT/OAuth2 动态集成）、分布式高阶限流、可观测性链路追踪以及最新演进的 AI 扩展能力，Nginx Ingress Controller 往往需要依赖复杂的动态修改配置文件（Reload 隐患）或硬编码的 Annotation 声明，运维心智和出错率都极高。

因此，在现代云原生架构中，最佳实践往往是直接选择 Kong、Apache APISIX、Higress 这一类“二合一”的云原生网关——向外替代传统 Ingress 作为高性能 L7 流量入口，向内通过丰富的原生插件（Lua/Wasm）完美接管微服务的高阶业务治理，彻底精简架构层级。

六、 进阶拓扑深化：云上 WAF 安全接入的流量真相

当我们在公有云上将 “流量网关与微服务网关” 合并部署为 K8s 内部的开源 Higress/APISIX 时，必然会面临一个致命的架构设计问题：云厂商的 Web 应用防火墙（WAF）该如何接入，对流量和证书配置有什么影响？

根据技术自主权的不同，业界演进出了两种完全不同的安全接入模型：

6.1 场景 A：自管开源网关（Higress/APISIX）+ 云厂商 L4 LB “透明接入” WAF

很多开发者对“透明接入”存在认知误区，认为 WAF 会解密流量后通过明文打给后端。实际上，现代云厂商（如阿里云 WAF 3.0 等）的透明接入采用的是“网络层镜像/Hook与旁路判定”机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
客户端 (加密 HTTPS 443)
 │
 ▼
云厂商 L4 LB (接管公网流量)
 │
 ├─── (物理复制流量) ──> 云厂商 WAF 侧 (需上传 SSL 证书到WAF侧) ──> 判定放行/阻断
 │                                                              │
 ▼ (原样投传：原始、未解密的加密 TLS 密文流) <──────────────────────┘
 │
 ▼
K8s 内部融合网关 (开源 Higress / APISIX / Kong) ─── 真正的 TLS 终结站（在此配置证书并终结解密）
 │
 ▼ (集群私网明文/内部加密)
业务 Pod
  • WAF 的真实定位（旁路审计）：为了让 WAF 具备应用层深度防护（防 SQL 注入、CC 攻击）的能力，需要将 LB 的监听类型配置为高级四层或七层检测（如将 TCP 改为关联 HTTPS 协议）。此时，你需要将 SSL 证书上传到 WAF 侧。不干扰主数据流，检测完成后向 LB 返回一个“放行（Pass）”信号。
  • 主数据流未被篡改：LB 最终转发给 K8s 集群内部开源网关（Higress/APISIX）的，依然是最初客户端发起的、完整的、未被拆包或重新加密的原始 TLS 加密流。
  • 证书与终结站：在这种架构下，后端的自管开源网关才是整条链路唯一真正的 TLS 终结节点（TLS Termination）。开源网关侧绝对必须独立配置一份 SSL 证书，用于真正的流量拆包并向微服务路由。
  • 架构优势：完美规避了传统反向代理（CNAME 接入）导致的“网关双重解密损耗”或“云私网明文传输（不合规）”的痛点。

6.2 场景 B：云厂商原生托管 API 网关（如阿里云全新的“云原生 API 网关”）

如果你选择完全拥抱云厂商的原生托管生态，整条安全与网络链条将被彻底基础设施化：

1
2
3
4
5
6
7
8
9
10
客户端 (HTTPS 443)  ──>  [ 云厂商统一接入层：集成了 L4 LB + L7 流量治理 + 阿里云证书 CAS ]
                                                           │
                                                           ▼ (内部原生一键打通，控制台托管免上传)
                                                [ 云厂商托管 WAF 安全中心 ]
                                                           │
                                                           ▼ (通过私网安全转发)
                                                [ 云原生 API 网关内核 (Higress 托管版) ]
                                                           │
                                                           ▼
                                                        业务 Pod

  • 证书生态全打通：在托管方案中，网关与云厂商的“数字证书管理服务（CAS）”原生打通，支持 DV 证书自动续期与一键绑定。

  • 免手动上传 WAF：因为网关、LB、WAF 全属于云厂商的统一接入控制面，当你在网关层绑定证书或一键开启 WAF 时，云厂商在底层基础设施内部自动完成了证书分发和安全流量清洗牵引。用户彻底告别了“既要在 WAF 传一遍证书，又要在网关传一遍证书”的运维碎片化痛点。

七、 全产品图谱速查

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
                流量网关 (L4/L7)                微服务网关
           ┌──────────────────────┐   ┌──────────────────────────┐
硬件       │ F5 / Citrix / A10    │   │ (极少硬件形态)             │
           └──────────────────────┘   └──────────────────────────┘
           ┌──────────────────────┐   ┌──────────────────────────┐
开源软件   │ LVS (L4)              │   │ Spring Cloud Gateway     │
           │ Nginx / HAProxy       │   │ Apache ShenYu            │
           │ Kong / APISIX / Higress│◄──┤ Kong / APISIX / Higress  │ ◄─── 这三家跨两类
           └──────────────────────┘   └──────────────────────────┘
           ┌──────────────────────┐   ┌──────────────────────────┐
商业软件   │ F5 / Citrix (硬件)     │   │ Kong Enterprise          │
           │ Nginx Plus / HAProxy Ent│   │ APISIX Enterprise (API7)│
           │ Traefik Enterprise     │   │ 阿里云云原生API网关 / TSE │ (云厂新一代)
           └──────────────────────┘   └──────────────────────────┘
           ┌──────────────────────┐   ┌──────────────────────────┐
云厂原生   │ AWS NLB/ALB           │   │ AWS API Gateway          │
           │ GCP Cloud LB          │   │ GCP Endpoints / API GW   │
           │ Azure App Gateway     │   │ Azure APIM               │
           │ 阿里 NLB/ALB          │   │ 阿里云云原生 API 网关     │
           │ 腾讯/华为 CLB/ELB     │   │ 腾讯云智能网关 / 华为APIG 专享版│
           └──────────────────────┘   └──────────────────────────┘

八、 时效扩展：看 Higress 与 APISIX 如何玩转 “AI 网关”

为了更直观地理解“网关功能融合”的必然趋势，我们可以脱离宏大的概念，直接看当前两大顶级开源网关在 LLM（大语言模型）智能路由、多模型平滑降级（Fallback）以及最新 Agent 协议支持上的落地案例。

8.1 Apache APISIX 的 ai-proxy-multi 多模型智能路由与容灾

在传统业务中，网关负载均衡的是一堆业务 Pod IP；而在 AI 时代，APISIX 负载均衡的对象变成了不同云厂商的 LLM API 接口（OpenAI、DeepSeek、Anthropic 等）。
APISIX 通过内置的 ai-proxy 和 ai-proxy-multi 插件，将 AI 治理能力上提至网关层：

  • 统一 API 契约：客户端仅需统一调用 APISIX 暴露的标准 OpenAI 格式接口，网关屏蔽底层异构模型差异。
  • 成本与质量路由（Cost-Aware Routing）：网关深度解析请求内容，默认将高频、后台批处理的请求分流给高性价比模型（如 DeepSeek-V3）；将需要极强逻辑推理的请求路由给 Premium 模型（如 OpenAI GPT-4o）。
  • 自动降级与熔断（Fallback & Failover）：当某一云厂商的 LLM 接口因并发过高触发 HTTP 429（限流）或服务宕机时，APISIX 能够在网关层实现秒级无缝 Fallback，自动将请求转发给备份模型供应商，业务层完全无感知。
  • Token 级精细流控：不同于传统网关基于 IP QPS 的限流，APISIX 支持基于 input_tokens 和 output_tokens 消耗速度的动态流控，有效防止企业 AI 账单超出预算失控。

8.2 Higress 对 MCP 协议的托管与“AI 插件化”生态

作为基于 Envoy 内核和 WebAssembly（Wasm）动态插件机制构建的网关，Higress 在 AI 原生支持上采取了更激进的架构设计。

  • MCP（Model Context Protocol）网关化：
    Anthropic 提出的 MCP 协议已成为 AI Agent 连接外部工具、上下文与数据的行业标准。Higress 在网关层直接支持 MCP 生态，充当 MCP Gateway。它能将企业现有的传统 OpenAPI 路由，一键转换并发布为合规的远程 MCP Server，供各种 AI 智能体（Agents）直接调用，打通了传统业务系统与大模型生态的最后一公里。
  • AI 语义缓存（Semantic Cache）：
    传统的 Nginx 缓存只能做到“HTTP 请求字符串完全一致”才命中。Higress 的 AI 插件支持语义缓存——请求进入网关后，通过内置向量化（Embedding）服务判断 Prompt 语义相似度。当两个用户的 Prompt 意思高度相近时（即使措辞不同），网关层直接通过向量数据库（如 Redis/Milvus）命中缓存并返回，不再向后端大模型发起请求。这不仅将大模型响应延迟从秒级直接压缩至十几毫秒，更大幅削减了企业的 Token 消耗成本。

写在最后

纵观整个接入层网关的演进史，其本质就是一部“分层合并、向基础设施收敛”的演进史。
从早期的硬件 F5 到软负载 Nginx，再到微服务时代引入独立的微服务网关，核心原因在于当时的基础设施（虚拟机 / 静态 IP 绑定）无法原生感知动态的业务服务实例。
而到了 Kubernetes 时代，基础设施（Service / Endpoint）终于看懂了“服务”的概念。Ingress Controller 顺理成章地承上启下，把流量网关和微服务网关合二为一。
现如今 Higress、Kong、APISIX 这几款产品之所以火热，是因为它们作为“融合网关”，既能完美贴合 K8s 云原生基础设施，又比传统的 Nginx Ingress 拥有更强的业务插件扩展能力（通过 Lua、Wasm 或 Go 插件支持）。
搞懂了这一层演进逻辑，再去看当下火热的“安全网关融合（Prod-to-Edge Security）”以及未来的“AI 网关融合（处理 LLM API、Token 限流、Prompt 路由、语义缓存）”，就会发现，技术演进不过是沿着“基础设施化”与“能力收敛”这条必然的道路，继续往下延伸罢了。

微服务接入层的两层网关：概念、界线与全产品图谱

https://blog.xsigeo.com/2026/06/24/microservice-gateways-map/

作者

守希

发布于

2026-06-25

更新于

2026-06-25

许可协议

#
分享到：微信新浪微博QQ空间更多

扫码关注我的公众号，了解更多的个人思考与观点。

关注我

分类

标签

AI Coding Agent2
AliCloud2
Ansible1
Architecture3
Azure DevOps1
Bitbucket1
CI/CD7
Cloud-Native2
Code Quality1
Docker1
Git4
GitLab1
GitOps1
Gitee1
Github1
Hexo1
Jenkins5
Kind1
Kubernetes4
LLM2
Minikube1
Podman1
Python1
SonarQube1
Stability/Aailability2
System Management1
TLS/SSL1
Terraform1
Windows1
×