为什么一次网络请求要穿过多层网关？Nginx、Kong、Ingress、Istio 到底各司什么职责

接好运鸭

当业务从单机网站，逐步演进到 Kubernetes 容器、微服务、服务网格架构，请求路上会依次遇到 Nginx、Kong、APISIX、Ingress‑Nginx、Envoy Gateway、Istio 等一堆代理 / 网关组件。很多开发者会疑惑：为什么要叠这么多层代理，不能用一个组件全部搞定？它们分别解决什么问题？

本文以一家网上网店业务的真实成长路径为例，通俗拆解每一层组件的定位、职责、适用边界，分清反向代理、API 网关、K8s 入口、服务网格的差异，理清外部南北流量与集群内部东西流量的区别火山引擎开...。

提示：本文为云原生后端科普，不构成生产选型建议。

业务演进：一家网店的架构变迁

阶段 1：初创，单台服务器

早期网店流量小，一台机器同时部署 Nginx + 网站业务程序。

• Nginx 角色：反向代理 + Web 服务器 用户 HTTP 请求直接打到 Nginx，静态文件由 Nginx 直接返回；动态请求转发给本机后端程序。

职责：负载均衡、静态资源、HTTPS 证书、基础限流。此时只有一层，架构简单。

阶段 2：业务增长，多台后端机器

流量上涨，后端扩展多台业务服务器。单纯 Nginx 已经不够用，需要增加API 网关层（Kong / Apache APISIX）。 Nginx 依旧做最外层接入；API 网关承接更多业务能力：接口鉴权、JWT 校验、限流熔断、黑白名单、协议转换、接口版本管理、监控统计。

分层逻辑：Nginx 负责高性能接入、防 DDoS、SSL 卸载；API 网关聚焦业务 API 治理。这一层处理来自公网的外部请求，行业叫南北向流量（外网 ↔ 集群内部）Kong Inc.。

阶段 3：全面上 Kubernetes 容器平台

业务全部容器化，大量 Pod 动态扩缩容，Pod IP 会随时销毁重建。于是出现 Ingress（ingress‑nginx、APISIX‑Ingress、Kong Ingress Controller、Envoy Gateway）。 Ingress 是 K8s 集群的入口抽象资源。Ingress‑Controller（比如 ingress‑nginx）读取 K8s 的 Ingress、Service 资源，自动生成代理配置，把外部流量转发给集群内不断变化的 Pod。

重点区分： Ingress 不是一个可独立运行程序，它是 K8s 的资源规范；ingress‑nginx、Kong Ingress Controller 才是真正执行代理的控制器程序。 解决痛点：Pod 频繁销毁重建，不用人工改 Nginx 配置，通过 K8s CRD 声明式配置路由规则。

阶段 4：微服务爆炸，引入服务网格 Istio

集群内部服务之间互相调用（服务 A 调用服务 B，服务 B 调用服务 C），这部分叫东西向流量（集群内部服务之间）。 业务需要灰度发布、金丝雀流量拆分、A/B 测试、服务之间 mTLS 双向加密、调用链追踪、超时重试、故障注入。 如果把这些逻辑写进每一个业务代码，每个服务都要重复开发一遍，成本极高。于是引入 Istio 服务网格（Service Mesh）。

Istio 以 Envoy 作为 Sidecar 边车代理，每一个业务 Pod 旁边附带一个 Envoy 代理。集群内部所有服务进出流量全部经过 Sidecar，业务代码不用修改一行，就获得流量治理、安全、观测能力Istio。

注意：Istio 主要解决集群内部服务之间调用（东西流量）；它也提供 Ingress‑Gateway 网关处理外部南北流量，但并不替代 API 网关。

关键概念区分，不要再混淆

1.Nginx（反向代理 / Web 服务器）

• 定位：高性能 web 反向代理、负载均衡。
• 擅长：SSL 卸载、静态文件、高并发接入、连接复用。
• 短板：原生配置靠静态文件，改配置需要 reload；高级鉴权、限流、插件生态需要自己写脚本扩展，开箱即用的 API 治理能力弱。
• 适合：最外层流量接入层，也可以做简单内部代理Apache API...。

2.API 网关 Kong / Apache APISIX

• 定位：API 网关，专门治理对外暴露的业务接口（南北流量），大多基于 OpenResty (Nginx+LuaJIT)。
• 擅长：动态配置，无需重载；JWT 鉴权、限流熔断、WAF 防护、接口版本、插件生态、可观测性；支持 gRPC、HTTP3 等多协议。
• 和普通 Nginx 区别：APISIX/Kong 有完整管理 API、仪表盘、大量开箱插件，配置存在 etcd / 数据库，支持毫秒级动态更新，不用改配置文件重启服务Apache API...。

3.Kubernetes Ingress 系列（ingress‑nginx、Kong‑Ingress、Envoy Gateway）

• 定位：K8s 集群入口控制器，专门适配容器动态 Pod 生命周期。
• 核心价值：监听 K8s API，Ingress 资源变更自动更新代理规则，适配 Pod 不断重启、伸缩。

误区：Ingress ≠ 软件，Ingress 是 K8s 资源定义；ingress‑nginx 是实现该规范的具体代理程序。

4.Istio 服务网格

• 定位：服务网格，重点治理集群内部服务之间调用（东西向流量）。
• 组件：控制平面 istiod + 数据平面 Envoy Sidecar。
• 能力：灰度金丝雀发布、流量拆分、mTLS 双向加密、重试、超时、熔断、故障注入、全链路指标采集。业务代码零侵入。
• 边界：虽然有 Gateway 可以处理外部入口，但它不是传统 API 网关，缺少面向公网接口的完整鉴权、WAF、接口生命周期管理能力，一般和 API 网关配合使用。

表格

组件	主要流量方向	核心能力	典型使用场景
Nginx	南北向	高性能反向代理、SSL、静态资源	最外层接入、负载均衡
Kong / APISIX	南北向	API 鉴权、限流、插件、动态配置	业务 API 网关，对外接口治理
Ingress Controller (ingress‑nginx 等)	南北向	K8s 动态 Pod 路由，声明式配置	K8s 集群外部流量入口
Istio(ServiceMesh)	优先东西向，也支持南北	内部服务灰度、mTLS、观测、熔断	微服务集群内部服务治理

一条完整请求的路径（大型网店生产示例）

用户浏览器发起请求：

1. 云厂商公网 SLB 负载均衡 →
2. Nginx，做 SSL 卸载、DDoS 基础防护 →
3. APISIX/Kong API 网关：鉴权、限流、接口校验、监控统计 →
4. K8s Ingress‑Controller，按照 Host / 路径转发到对应 K8s Service →
5. 流量进入 Istio 网格，到达 Pod 的 Envoy Sidecar 边车；
6. 业务 Pod 内部处理；
7. 业务需要调用另一个微服务，内部东西调用经过本 Pod Sidecar → 目标服务 Sidecar，完成灰度、加密、熔断等治理；
8. 结果沿着原路逐层返回给用户。

不是所有业务都需要叠满全部层级。小型 K8s 业务，可以直接用 ingress‑nginx，跳过独立 API 网关；单体业务完全不需要 Istio。架构是跟着业务规模逐步叠加，不要上来把所有组件全部堆上。

常见现实疑问

Q1：为什么不能只用一个网关把所有事情干完？

A：不同组件设计目标不同。

• Nginx 追求极致网络转发性能；
• API 网关聚焦业务接口治理、鉴权限流插件；
• Ingress 专注适配 K8s 动态 Pod；
• Istio 专注集群内部微服务之间流量。 全部能力塞到一个程序，会变得臃肿，维护成本、故障面变大。业务小时可以用一个组件搞定；业务规模上涨，职责拆分分层，每一层只解决一类问题，便于独立迭代、独立扩容。

Q2：Istio 能不能替代 API 网关？

A：不能完全替代。Istio Gateway 可以接收外部流量，但缺少面向公网 API 的完整能力：接口鉴权、API 版本管理、WAF、接口生命周期管理。业界标准做法：公网流量先走 API 网关，再进 Istio 网格；Istio 重点负责内部服务之间调用Kong Inc.。

Q3：Ingress 和 API 网关怎么选？

A：

• 如果只是简单 http 路由，没有复杂业务鉴权限流，直接用 ingress‑nginx；
• 如果对外是大量业务 API，需要鉴权、限流、插件，优先选 APISIX / Kong，搭配对应的 Ingress‑Controller。

常见误区澄清

❌误区 1：Ingress 就是一套可以直接运行的网关软件 ✅真相：Ingress 是 K8s 的资源对象，ingress‑nginx、Kong‑Ingress 才是真正执行代理的程序。

❌误区 2：Istio 主要用来处理外部用户的公网请求 ✅真相：Istio 最大价值是集群内部微服务互相调用（东西流量），外部南北流量一般交给前置 API 网关。

❌误区 3：业务上 K8s 就必须上 Istio 服务网格 ✅真相：Istio 会增加运维复杂度。小规模微服务不需要，只有当大量服务需要灰度、mTLS、统一可观测的时候才引入。

❌误区 4：Nginx 已经淘汰，全部改用 APISIX、Kong ✅真相：Nginx 依然是互联网最通用高性能接入层，很多 APISIX/Kong 底层内核本身就基于 OpenResty（Nginx）开发。

全文总结

业务从单机到 K8s 再到服务网格，请求路上一层层网关 / 代理，并不是工程师喜欢 “加层炫技”，而是业务规模扩大之后，职责拆分的必然结果：

1. Nginx：高性能反向代理，做最外层接入、SSL 卸载；
2. Kong / Apache APISIX：API 网关，治理公网对外接口，鉴权、限流、插件扩展；
3. Ingress‑Controller：适配 K8s 容器动态 Pod，声明式路由；
4. Istio 服务网格：重点处理集群内部服务之间东西向流量，灰度发布、mTLS、熔断观测，业务代码零侵入。

小型业务不需要把全部组件堆砌完整，按需选择。架构分层本质是：每一层只解决一类问题，各司其职，独立扩容、独立维护。分清南北向（外网进集群）、东西向（集群内部服务互调）两类流量，就能看懂大部分云原生网络架构。