{"name":"网关","id":"软件工程-架构-系统设计-网关","content":"# 网关\n\n## 概述\n\n网关（Gateway）是分布式系统中的**边界控制平面**，负责在\"外部世界\"与\"内部系统\"之间建立一条可治理、可观测、可控的流量通道。\n它既是**请求生命周期的入口层**，也是**策略执行的集中节点**，更是**协议与能力的组合与编排层**。\n\n## 本质\n\n### 驱动力\n\n系统分布式后，**需求方与提供方的交互界面存在粒度不匹配**：\n- 提供方暴露细粒度能力，需求方需要粗粒度接口\n- 需求方数量 × 提供方数量形成 N × M 耦合\n- 横切关注点（安全、限流、观测）随拆分分散到各处\n\n### 本质\n\n**网关是以单一入口换取需求方与提供方拓扑解耦的架构组件。**\n\n解决的问题是：粒度不匹配导致的耦合，以及横切关注点分散导致的治理割裂。\n\n### 机制\n\n```\n需求方 → [网关：路由 + 聚合 + 策略执行] → 提供方群\n```\n\n网关负责聚合与治理收敛，不承载业务逻辑。\n\n### 原则\n\n- **单一入口** — 需求方不感知提供方分布\n- **策略内聚** — 横切关注点收敛于边界\n- **接口归一** — 对外接口数量远少于内部提供方数量\n\n## 网关模型\n\n网关模型回答\"网关如何被组织\"，从三个架构层面抽象：\n\n### 控制平面 / 数据平面模型\n\n| 平面 | 职责 | 关注点 |\n|---|---|---|\n| **控制平面（CP）** | 策略配置、路由规则、插件管理 | 可管理性、可扩展性 |\n| **数据平面（DP）** | 流量处理、协议转换、策略执行 | 延迟、吞吐量、稳定性 |\n\n分离的本质是让变化节奏不同的组件各按其节奏演进，互不干扰。\n\n### 管道模型\n\n扩展机制以管道形式组织，按生命周期顺序执行：\n\n```\nInbound Filters → 路由决策 → 服务调用 → Outbound Filters\n```\n\n每个 Filter 独立，可插拔。管道模型是网关可扩展性的基础。\n\n### 边界模型\n\n边界模型用来确定网关在系统拓扑中的位置，拓扑定位决定职责边界：\n\n```\nClient → LB / Gateway → 提供方群\n```\n\n网关可前置（合设）或后置（独立）：\n- **简单架构**：Gateway 直接接收请求\n- **大规模架构**：LB 在前做负载均衡，Gateway 在后做应用层治理\n- **高安全架构**：WAF/CDN 在最外层，Gateway 在内层做策略执行\n\n## 网关能力体系\n\n### 接入\n\n* 多协议解析（HTTP/gRPC/WebSocket/IoT）\n* L4 / L7 协议识别\n* 统一入口（单域名 / 多域名 / 多租户）\n\n### 治理\n\n* 访问控制（鉴权、限流、黑白名单）\n* 稳定性保障（熔断、重试、超时、降级兜底、幂等）\n\n### 路由\n\n* 静态路由 / 动态路由（服务发现）\n* 条件路由（Header、Path、Metadata）\n* 灰度分流（按比例、按用户分组）\n* 多目标路由（Fan-out）\n\n### 聚合\n\n* 多服务聚合\n* 响应加工与裁剪\n* 参数装配与转换\n* 缓存（请求与响应）\n\n### 观测\n\n* 指标（QPS、延迟、异常）\n* 日志（访问日志、审计日志）\n* 链路追踪（TraceId、Span）\n\n### 配置\n\n* 动态配置热更新\n* 灰度策略\n* 插件化管理\n\n各阶段按处理顺序组织，治理贯穿全程。\n\n## 网关类型体系\n\n完整的类型划分应遵循三维度：\n\n### 按\"流量方向\"分类\n\n#### 南北向网关（North-South Gateway）\n\n外部 ↔ 内部流量\n如：API Gateway、BFF、Ingress\n\n#### 东西向网关（East-West Gateway）\n\n服务 ↔ 服务内部流量\n如：Service Mesh 中的 Sidecar / egress-gateway\n\n### 按\"协议层级\"分类\n\n* **L4 网关**（TCP/UDP，性能更高）\n* **L7 网关**（HTTP、gRPC，语义能力更强）\n\n### 按\"能力范围\"分类\n\n#### 流量网关（Traffic Gateway）\n\n* 侧重安全、流控、攻击防护\n* 类似 WAF / 高性能转发器\n\n#### 应用网关 / API Gateway\n\n* 侧重 API 管理、策略治理、生命周期管理\n\n#### BFF Gateway\n\n* 面向前端体验的聚合与裁剪层\n\n#### 数据/IoT 网关\n\n* 面向 MQTT、CoAP、RTMP、摄像头流等特殊协议\n\n## 网关与周边系统的边界关系\n\n### 网关 vs 反向代理（Nginx 等）\n\n| 项目  | 反向代理        | 网关       |\n| --- | ----------- | -------- |\n| 关注点 | 转发、负载、缓存    | 策略、管理、治理 |\n| 粒度  | 网络层与基础能力    | 应用层能力    |\n| 场景  | 静态资源、简单负载均衡 | API 体系治理 |\n\n### 网关 vs Ingress Controller（K8s）\n\n* Ingress 是 **K8s 网络入口规范**\n* 网关是 **应用级策略、认证、治理体系**\n\nIngress 更像 L7 LB，而非 API Gateway。\n\n### 网关 vs Service Mesh（Istio/Envoy）\n\n* Mesh 负责 **服务间通信治理（东西向）**\n* 网关负责 **外部入口流量治理（南北向）**\n\n## 架构演进\n\n拓扑复杂度催生边界解耦需求，治理需求催生控制面独立，两者交叉推进网关架构演进。\n\n| 复杂度来源 | 本质原理 | 架构响应 |\n|---|---|---|\n| 提供方 N×M 互联 | 边界解耦 | 单一入口 |\n| 协议异构 | 协议归一 | 多协议解析层 |\n| 横切关注点分散 | 治理收敛 | 策略执行中心 |\n| 策略变更频发 | 关注点分离 | 控制平面独立 |\n| 云原生标准化 | 接口标准化 | Ingress / Gateway API |\n| 终端碎片化 | 接口适配分离 | BFF |\n\n* **统一网关**：边界解耦的终极形态——以单一入口收敛所有拓扑复杂度\n* **数据/控制分离**：治理与执行关注点分离的持续深化\n* **Mesh 融合**：南北向与东西向治理在原理上同构，最终殊途同归\n* **AI 驱动**：治理复杂度超出人工决策边界，自动适配成为必要\n\n## 网关选型方法论\n\n### 维度一：协议兼容性\n\n| 协议需求 | 选型原理 |\n|---|---|\n| 需要 gRPC / MQTT 等非 HTTP 协议 | 必须选 L7 网关（Envoy/APISIX） |\n| 仅 HTTP | L4/L7 皆可，权衡性能与功能 |\n\n### 维度二：治理复杂度\n\n| 策略数量与变更频率 | 选型原理 |\n|---|---|\n| 少量策略，低频变更 | 单实例网关足矣，控制平面是过度设计 |\n| 多团队、多策略、高频变更 | 控制平面独立是必要投资 |\n\n### 维度三：组织约束\n\n| 约束类型 | 选型原理 |\n|---|---|\n| 已有 Spring 技术栈 | SCG 降低接入成本 |\n| 已有 K8s 集群 | Ingress / Gateway API 是最低摩擦路径 |\n\n### 维度四：性能边界\n\n| 场景 | 选型原理 |\n|---|---|\n| 高吞吐、低延迟优先 | L4/L7 混合架构（Envoy、HAProxy）|\n| 需要业务层聚合裁剪 | BFF 独立，不在网关上做 |\n| IoT 特殊协议 | 专用协议网关，不强求统一网关 |\n\n### 决策框架\n\n```\n协议兼容性 ───→ 是否需要多协议？\n    ↓\n治理复杂度 ───→ 策略变更频率？团队数量？\n    ↓\n组织约束 ───→ 现有技术栈？K8s 成熟度？\n    ↓\n性能边界 ───→ 延迟敏感度？吞吐量量级？\n```\n\n每一步回答后，下一步才进入，最终收敛到具体技术方案。\n\n## 反模式与误区\n\n### 核心原则\n\n> **网关是策略中心，不是业务容器。**\n> **网关是边界防线，不是唯一防线。**\n\n### 反模式 1：网关成为业务容器\n\n**表现**：在网关上堆砌业务逻辑、复杂聚合、数据转换。\n\n**问题**：网关复杂度爆炸；变更风险集中；成为单点瓶颈。\n\n**正确认知**：将业务逻辑从网关移除；聚合仅限于数据组合；复杂业务下沉到独立服务。\n\n**原则**：网关只做跨边界治理，业务逻辑留在服务层。\n\n### 反模式 2：网关成为单点故障\n\n**表现**：所有流量经过网关，但网关自身无高可用设计。\n\n**问题**：网关宕机 = 全系统不可用；容量评估不足导致过载；缺乏熔断保护级联崩溃。\n\n**正确认知**：多实例负载均衡、独立健康检查、自动故障转移、容量规划考虑网关瓶颈。\n\n**原则**：网关是流量咽喉，必须比后端服务更稳定。\n\n### 反模式 3：混淆 API 管理与 API 网关\n\n**表现**：将 API 生命周期管理（发布、版本、文档）混入网关实现。\n\n**问题**：网关职责膨胀；管理平面与数据平面混淆。\n\n**正确认知**：API 网关是技术组件（数据平面），API 管理是平台能力（控制平面）。\n\n**原则**：网关专注流量治理，API 管理独立建设。\n\n### 反模式 4：忽视东西向流量治理\n\n**表现**：只在南北向部署网关，内部服务调用无治理。\n\n**问题**：服务间通信缺乏安全控制；内部故障无法追踪。\n\n**正确认知**：南北向用 API 网关，东西向用 Service Mesh，定位不同，相辅相成。\n\n**原则**：网关管入口，Mesh 管内部。\n\n### 反模式 5：网关变更影响所有业务\n\n**表现**：中心化网关的逻辑变更影响所有业务。\n\n**正确认知**：网关演进路径：中心化 → 去中心化 → Mesh 化；大部分工作量在灰度、回滚、监控。\n\n**原则**：网关变更必须可控、可回滚、可灰度。\n\n### 反模式 6：滥用网关卸载\n\n**表现**：将所有通用功能往网关上堆（包括业务相关逻辑）。\n\n**问题**：网关膨胀、性能下降、业务逻辑与治理逻辑耦合。\n\n**正确认知**：只卸载跨切面通用能力（SSL、Auth、限流），业务相关逻辑在服务层。\n\n**原则**：卸载的是横切关注点，非业务逻辑。\n\n### 误区 1：有了网关就不需要 Mesh\n\n**真相**：网关处理南北向（可控），Mesh 处理东西向（解耦），定位不同，互补非替代。\n\n**原则**：两者相辅相成，不是替代关系。\n\n### 误区 2：网关延迟可以忽略\n\n**真相**：额外跳转带来延迟，对高频交易场景影响显著。\n\n**原则**：网关适合 API 治理，不适合高速交易链路。\n\n### 误区 3：网关安全是唯一防线\n\n**真相**：需要多层防御：网关（边界）+ 服务间认证（mTLS）+ 数据安全 + 应用层安全。\n\n**原则**：纵深防御，网关是入口而非全部。\n\n## 关联文档\n\n- [/计算机网络/网络安全/安全性.md](/计算机网络/网络安全/安全性.md) - 网关的安全防护能力与网络安全体系密切相关，包括认证、授权、安全策略执行、安全协议等方面的内容\n- [/计算机网络/网络安全/安全架构.md](/计算机网络/网络安全/安全架构.md) - 涉及网关在整体安全架构中的作用，包括边界安全、访问控制、安全策略执行等方面\n- [/计算机网络/网络安全/认证与授权.md](/计算机网络/网络安全/认证与授权.md) - 网关承担着重要的认证与授权功能，是访问控制的第一道防线\n- [/软件工程/架构/系统设计/可观测性.md](/软件工程/架构/系统设计/可观测性.md) - 网关需要具备完整的可观测性能力，包括指标监控、日志记录、分布式追踪等，以实现对跨边界流量的全面治理\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) - 网关在分布式系统中承担着流量治理、服务发现、负载均衡等关键职责，是分布式架构的重要组成部分\n- [/软件工程/微服务/微服务.md](/软件工程/微服务/微服务.md) - API网关是微服务架构中的重要组件，提供统一入口、服务治理、策略执行等功能\n- [/软件工程/微服务/ServiceMesh/ServiceMesh.md](/软件工程/微服务/ServiceMesh/ServiceMesh.md) - 服务网格与网关在流量治理方面有密切关系，东西向流量通过Sidecar处理，南北向流量通过网关处理，二者相辅相成\n- [/软件工程/微服务/服务治理/服务容错.md](/软件工程/微服务/服务治理/服务容错.md) - 网关承担熔断、降级等容错策略的执行，是服务治理策略的边界执行点，与服务容错机制共同构成系统的运行时保护体系\n- [/软件工程/架构/系统设计/流量控制.md](/软件工程/架构/系统设计/流量控制.md) - 网关具备强大的流量控制能力，包括限流、熔断、降级等策略，是系统稳定性的重要保障\n- [/软件工程/架构/系统设计/高并发.md](/软件工程/架构/系统设计/高并发.md) - 网关在高并发场景下需要具备高性能的流量处理能力，通过负载均衡、缓存、限流等手段支撑系统的高并发需求\n- [/软件工程/架构/系统设计/可用性.md](/软件工程/架构/系统设计/可用性.md) - 网关是系统可用性的关键节点，通过健康检查、故障转移、容错等机制保障系统的高可用性\n- [/软件工程/架构/系统设计/伸缩性.md](/软件工程/架构/系统设计/伸缩性.md) - 网关需要具备良好的伸缩性，能够随着业务增长进行水平扩展，支撑系统的弹性伸缩需求\n- [/软件工程/架构/Web前端/前后端分离.md](/软件工程/架构/Web前端/前后端分离.md) - API网关和BFF模式是前后端分离架构中的重要组件，用于统一入口与服务聚合\n- [/中间件/web中间件/Nginx.md](/中间件/web中间件/Nginx.md) - Nginx作为主流反向代理和负载均衡器，在功能上与网关有重叠，但网关注重策略治理，而Nginx更偏向流量转发\n- [/运维/K8s.md](/运维/K8s.md) - Kubernetes Ingress控制器是云原生环境下网关的重要实现形式，提供了标准化的流量管理接口\n- [/软件工程/架构/系统设计/分布式/分布式.md](/软件工程/架构/系统设计/分布式/分布式.md) - 网关是分布式架构中的关键组件，承担着边界控制、流量治理、服务协调等职责","metadata":"tags: ['中间件', 'API', '分布式系统']","hasMoreCommit":true,"totalCommits":11,"commitList":[{"date":"2026-05-19T22:03:34+08:00","author":"MY","message":"docs(gateway): 重构网关设计文档结构并完善内容","hash":"4db330f9d67b79f6f2385890afc45aecb129da25"},{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2025-11-16T21:30:56+08:00","author":"MY","message":"docs: 统一并精简文档标签","hash":"21362e9d7aeb62e05364cd5e7f3a3c24d7e293c7"},{"date":"2025-11-14T17:06:34+08:00","author":"MY","message":"docs(gateway): 更新网关系统设计文档","hash":"0d78287bab086bf712888978e4634acb4a70b34e"},{"date":"2025-10-20T10:26:06+08:00","author":"MY","message":"docs(gateway): 重构网关设计文档内容与结构","hash":"ca1e3eb89579d7a9ce28a5c25a06db6c9c8f1edc"},{"date":"2024-11-22T10:28:56+08:00","author":"MY","message":"📦网关","hash":"c73adf1561b5dc9412f163b8b546d08fba8cd07b"},{"date":"2024-11-01T16:02:53+08:00","author":"MY","message":"✏网关","hash":"76c604c05aba160eddcb9dd5345c257b2ecf07e7"},{"date":"2022-06-14T17:39:12+08:00","author":"cjiping","message":"📦整理 网关","hash":"15fefb641d041567d5abbb51209147d58b39b1a6"},{"date":"2022-01-27T11:38:09+08:00","author":"cjiping","message":"📦整理随手","hash":"f5ec44c039a7d8dec55ca7b4885582d06c059e22"},{"date":"2020-11-19T15:29:14+08:00","author":"MY","message":"✏更新 网关","hash":"73984906001daad12fbacafc182744c271cfc403"}],"createTime":"2020-07-21T09:30:25+08:00"}