为什么一次网络请求要穿过多层网关？Nginx、Kong、Ingress、Istio 到底各司什么职责
<div class="quote"><blockquote><p><font size="4">当业务从单机网站，逐步演进到 Kubernetes 容器、微服务、服务网格架构，请求路上会依次遇到 Nginx、Kong、APISIX、Ingress‑Nginx、Envoy Gateway、Istio 等一堆代理 / 网关组件。很多开发者会疑惑：<strong>为什么要叠这么多层代理，不能用一个组件全部搞定？它们分别解决什么问题？</strong></font></p><p><font size="4">本文以一家网上网店业务的真实成长路径为例，通俗拆解每一层组件的定位、职责、适用边界，分清<strong>反向代理、API 网关、K8s 入口、服务网格</strong>的差异，理清外部南北流量与集群内部东西流量的区别火山引擎开...。</font></p><blockquote><p><font size="4">提示：本文为云原生后端科普，不构成生产选型建议。</font></p></blockquote></blockquote></div><p><br></p><blockquote>
</blockquote><h2>业务演进：一家网店的架构变迁</h2><h3>阶段 1：初创，单台服务器</h3><p>早期网店流量小，一台机器同时部署 Nginx + 网站业务程序。</p><ul>
<li><strong>Nginx 角色：反向代理 + Web 服务器</strong>
用户 HTTP 请求直接打到 Nginx，静态文件由 Nginx 直接返回；动态请求转发给本机后端程序。</li>
</ul>
<blockquote>
<p>职责：负载均衡、静态资源、HTTPS 证书、基础限流。此时只有一层，架构简单。</p>
</blockquote><h3>阶段 2：业务增长，多台后端机器</h3><p>流量上涨，后端扩展多台业务服务器。单纯 Nginx 已经不够用，需要增加<strong>API 网关层（Kong / Apache APISIX）</strong>。
Nginx 依旧做最外层接入；API 网关承接更多业务能力：接口鉴权、JWT 校验、限流熔断、黑白名单、协议转换、接口版本管理、监控统计。</p><blockquote>
<p>分层逻辑：Nginx 负责高性能接入、防 DDoS、SSL 卸载；API 网关聚焦业务 API 治理。这一层处理<strong>来自公网的外部请求，行业叫南北向流量</strong>（外网 ↔ 集群内部）Kong Inc.。</p>
</blockquote><h3>阶段 3：全面上 Kubernetes 容器平台</h3><p>业务全部容器化，大量 Pod 动态扩缩容，Pod IP 会随时销毁重建。于是出现 <strong>Ingress（ingress‑nginx、APISIX‑Ingress、Kong Ingress Controller、Envoy Gateway）</strong>。
Ingress 是 K8s 集群的入口抽象资源。Ingress‑Controller（比如 ingress‑nginx）读取 K8s 的 Ingress、Service 资源，自动生成代理配置，把外部流量转发给集群内不断变化的 Pod。</p><blockquote>
<p>重点区分：
Ingress 不是一个可独立运行程序，它是 K8s 的资源规范；ingress‑nginx、Kong Ingress Controller 才是真正执行代理的控制器程序。
解决痛点：Pod 频繁销毁重建，不用人工改 Nginx 配置，通过 K8s CRD 声明式配置路由规则。</p>
</blockquote><h3>阶段 4：微服务爆炸，引入服务网格 Istio</h3><p>集群内部服务之间互相调用（服务 A 调用服务 B，服务 B 调用服务 C），这部分叫<strong>东西向流量</strong>（集群内部服务之间）。
业务需要灰度发布、金丝雀流量拆分、A/B 测试、服务之间 mTLS 双向加密、调用链追踪、超时重试、故障注入。
如果把这些逻辑写进每一个业务代码，每个服务都要重复开发一遍，成本极高。于是引入 <strong>Istio 服务网格（Service Mesh）</strong>。</p><p>Istio 以 Envoy 作为 Sidecar 边车代理，每一个业务 Pod 旁边附带一个 Envoy 代理。集群内部所有服务进出流量全部经过 Sidecar，<strong>业务代码不用修改一行，就获得流量治理、安全、观测能力</strong>Istio。</p><blockquote>
<p>注意：Istio 主要解决<strong>集群内部服务之间调用（东西流量）</strong>；它也提供 Ingress‑Gateway 网关处理外部南北流量，但并不替代 API 网关。</p>
</blockquote><h2>关键概念区分，不要再混淆</h2><h3>1.Nginx（反向代理 / Web 服务器）</h3><ul>
<li>定位：高性能 web 反向代理、负载均衡。</li>
<li>擅长：SSL 卸载、静态文件、高并发接入、连接复用。</li>
<li>短板：原生配置靠静态文件，改配置需要 reload；高级鉴权、限流、插件生态需要自己写脚本扩展，开箱即用的 API 治理能力弱。</li>
<li>适合：最外层流量接入层，也可以做简单内部代理Apache API...。</li>
</ul><h3>2.API 网关 Kong / Apache APISIX</h3><ul>
<li>定位：<strong>API 网关，专门治理对外暴露的业务接口（南北流量）</strong>，大多基于 OpenResty (Nginx+LuaJIT)。</li>
<li>擅长：动态配置，无需重载；JWT 鉴权、限流熔断、WAF 防护、接口版本、插件生态、可观测性；支持 gRPC、HTTP3 等多协议。</li>
<li>和普通 Nginx 区别：APISIX/Kong 有完整管理 API、仪表盘、大量开箱插件，配置存在 etcd / 数据库，支持毫秒级动态更新，不用改配置文件重启服务Apache API...。</li>
</ul><h3>3.Kubernetes Ingress 系列（ingress‑nginx、Kong‑Ingress、Envoy Gateway）</h3><ul>
<li>定位：K8s 集群入口控制器，专门适配容器动态 Pod 生命周期。</li>
<li>核心价值：监听 K8s API，Ingress 资源变更自动更新代理规则，适配 Pod 不断重启、伸缩。</li>
</ul>
<blockquote>
<p>误区：Ingress ≠ 软件，Ingress 是 K8s 资源定义；ingress‑nginx 是实现该规范的具体代理程序。</p>
</blockquote><h3>4.Istio 服务网格</h3><ul>
<li>定位：<strong>服务网格，重点治理集群内部服务之间调用（东西向流量）</strong>。</li>
<li>组件：控制平面 istiod + 数据平面 Envoy Sidecar。</li>
<li>能力：灰度金丝雀发布、流量拆分、mTLS 双向加密、重试、超时、熔断、故障注入、全链路指标采集。业务代码零侵入。</li>
<li>边界：虽然有 Gateway 可以处理外部入口，但它不是传统 API 网关，缺少面向公网接口的完整鉴权、WAF、接口生命周期管理能力，一般和 API 网关配合使用。</li>
</ul>
<p>表格</p><table><thead><tr><th>组件</th><th>主要流量方向</th><th>核心能力</th><th>典型使用场景</th></tr></thead><tbody><tr><td>Nginx</td><td>南北向</td><td>高性能反向代理、SSL、静态资源</td><td>最外层接入、负载均衡</td></tr><tr><td>Kong / APISIX</td><td>南北向</td><td>API 鉴权、限流、插件、动态配置</td><td>业务 API 网关，对外接口治理</td></tr><tr><td>Ingress Controller (ingress‑nginx 等)</td><td>南北向</td><td>K8s 动态 Pod 路由，声明式配置</td><td>K8s 集群外部流量入口</td></tr><tr><td>Istio(ServiceMesh)</td><td>优先东西向，也支持南北</td><td>内部服务灰度、mTLS、观测、熔断</td><td>微服务集群内部服务治理</td></tr></tbody></table><h2>一条完整请求的路径（大型网店生产示例）</h2><p>用户浏览器发起请求：</p><ol>
<li>云厂商公网 SLB 负载均衡 →</li>
<li>Nginx，做 SSL 卸载、DDoS 基础防护 →</li>
<li>APISIX/Kong API 网关：鉴权、限流、接口校验、监控统计 →</li>
<li>K8s Ingress‑Controller，按照 Host / 路径转发到对应 K8s Service →</li>
<li>流量进入 Istio 网格，到达 Pod 的 Envoy Sidecar 边车；</li>
<li>业务 Pod 内部处理；</li>
<li>业务需要调用另一个微服务，<strong>内部东西调用经过本 Pod Sidecar → 目标服务 Sidecar</strong>，完成灰度、加密、熔断等治理；</li>
<li>结果沿着原路逐层返回给用户。</li>
</ol><blockquote>
<p>不是所有业务都需要叠满全部层级。小型 K8s 业务，可以直接用 ingress‑nginx，跳过独立 API 网关；单体业务完全不需要 Istio。<strong>架构是跟着业务规模逐步叠加，不要上来把所有组件全部堆上</strong>。</p>
</blockquote><h2>常见现实疑问</h2><h3>Q1：为什么不能只用一个网关把所有事情干完？</h3><p>A：不同组件设计目标不同。</p><ul>
<li>Nginx 追求极致网络转发性能；</li>
<li>API 网关聚焦业务接口治理、鉴权限流插件；</li>
<li>Ingress 专注适配 K8s 动态 Pod；</li>
<li>Istio 专注集群内部微服务之间流量。
全部能力塞到一个程序，会变得臃肿，维护成本、故障面变大。业务小时可以用一个组件搞定；业务规模上涨，职责拆分分层，每一层只解决一类问题，便于独立迭代、独立扩容。</li>
</ul><h3>Q2：Istio 能不能替代 API 网关？</h3><p>A：不能完全替代。Istio Gateway 可以接收外部流量，但缺少面向公网 API 的完整能力：接口鉴权、API 版本管理、WAF、接口生命周期管理。业界标准做法：<strong>公网流量先走 API 网关，再进 Istio 网格；Istio 重点负责内部服务之间调用</strong>Kong Inc.。</p><h3>Q3：Ingress 和 API 网关怎么选？</h3><p>A：</p><ul>
<li>如果只是简单 http 路由，没有复杂业务鉴权限流，直接用 ingress‑nginx；</li>
<li>如果对外是大量业务 API，需要鉴权、限流、插件，优先选 APISIX / Kong，搭配对应的 Ingress‑Controller。</li>
</ul><h2>常见误区澄清</h2><p>❌误区 1：Ingress 就是一套可以直接运行的网关软件
✅真相：Ingress 是 K8s 的资源对象，ingress‑nginx、Kong‑Ingress 才是真正执行代理的程序。</p><p>❌误区 2：Istio 主要用来处理外部用户的公网请求
✅真相：Istio 最大价值是<strong>集群内部微服务互相调用（东西流量）</strong>，外部南北流量一般交给前置 API 网关。</p><p>❌误区 3：业务上 K8s 就必须上 Istio 服务网格
✅真相：Istio 会增加运维复杂度。小规模微服务不需要，只有当大量服务需要灰度、mTLS、统一可观测的时候才引入。</p><p>❌误区 4：Nginx 已经淘汰，全部改用 APISIX、Kong
✅真相：Nginx 依然是互联网最通用高性能接入层，很多 APISIX/Kong 底层内核本身就基于 OpenResty（Nginx）开发。</p><h2>全文总结</h2><p>业务从单机到 K8s 再到服务网格，请求路上一层层网关 / 代理，并不是工程师喜欢 “加层炫技”，而是业务规模扩大之后，<strong>职责拆分的必然结果</strong>：</p><ol>
<li>Nginx：高性能反向代理，做最外层接入、SSL 卸载；</li>
<li>Kong / Apache APISIX：API 网关，治理公网对外接口，鉴权、限流、插件扩展；</li>
<li>Ingress‑Controller：适配 K8s 容器动态 Pod，声明式路由；</li>
<li>Istio 服务网格：重点处理集群内部服务之间东西向流量，灰度发布、mTLS、熔断观测，业务代码零侵入。</li>
</ol><p>小型业务不需要把全部组件堆砌完整，按需选择。架构分层本质是：<strong>每一层只解决一类问题，各司其职，独立扩容、独立维护</strong>。分清南北向（外网进集群）、东西向（集群内部服务互调）两类流量，就能看懂大部分云原生网络架构。</p><p></p>
页:
[1]