网关

概述

网关（Gateway）是分布式系统中的边界控制平面，负责在"外部世界"与"内部系统"之间建立一条可治理、可观测、可控的流量通道。它既是请求生命周期的入口层，也是策略执行的集中节点，更是协议与能力的组合与编排层。

本质

驱动力

系统分布式后，需求方与提供方的交互界面存在粒度不匹配：

本质

网关是以单一入口换取需求方与提供方拓扑解耦的架构组件。

解决的问题是：粒度不匹配导致的耦合，以及横切关注点分散导致的治理割裂。

机制

需求方 → [网关：路由 + 聚合 + 策略执行] → 提供方群

网关负责聚合与治理收敛，不承载业务逻辑。

原则

网关模型

网关模型回答"网关如何被组织"，从三个架构层面抽象：

控制平面 / 数据平面模型

平面职责关注点
控制平面（CP）策略配置、路由规则、插件管理可管理性、可扩展性
数据平面（DP）流量处理、协议转换、策略执行延迟、吞吐量、稳定性

分离的本质是让变化节奏不同的组件各按其节奏演进，互不干扰。

管道模型

扩展机制以管道形式组织，按生命周期顺序执行：

Inbound Filters → 路由决策 → 服务调用 → Outbound Filters

每个 Filter 独立，可插拔。管道模型是网关可扩展性的基础。

边界模型

边界模型用来确定网关在系统拓扑中的位置，拓扑定位决定职责边界：

Client → LB / Gateway → 提供方群

网关可前置（合设）或后置（独立）：

网关能力体系

接入

治理

路由

聚合

观测

配置

各阶段按处理顺序组织，治理贯穿全程。

网关类型体系

完整的类型划分应遵循三维度：

按"流量方向"分类

南北向网关（North-South Gateway）

外部 ↔ 内部流量如：API Gateway、BFF、Ingress

东西向网关（East-West Gateway）

服务 ↔ 服务内部流量如：Service Mesh 中的 Sidecar / egress-gateway

按"协议层级"分类

按"能力范围"分类

流量网关（Traffic Gateway）

应用网关 / API Gateway

BFF Gateway

数据/IoT 网关

网关与周边系统的边界关系

网关 vs 反向代理（Nginx 等）

项目反向代理网关
关注点转发、负载、缓存策略、管理、治理
粒度网络层与基础能力应用层能力
场景静态资源、简单负载均衡API 体系治理

网关 vs Ingress Controller（K8s）

Ingress 更像 L7 LB，而非 API Gateway。

网关 vs Service Mesh（Istio/Envoy）

架构演进

拓扑复杂度催生边界解耦需求，治理需求催生控制面独立，两者交叉推进网关架构演进。

复杂度来源本质原理架构响应
提供方 N×M 互联边界解耦单一入口
协议异构协议归一多协议解析层
横切关注点分散治理收敛策略执行中心
策略变更频发关注点分离控制平面独立
云原生标准化接口标准化Ingress / Gateway API
终端碎片化接口适配分离BFF

网关选型方法论

维度一：协议兼容性

协议需求选型原理
需要 gRPC / MQTT 等非 HTTP 协议必须选 L7 网关（Envoy/APISIX）
仅 HTTPL4/L7 皆可，权衡性能与功能

维度二：治理复杂度

策略数量与变更频率选型原理
少量策略，低频变更单实例网关足矣，控制平面是过度设计
多团队、多策略、高频变更控制平面独立是必要投资

维度三：组织约束

约束类型选型原理
已有 Spring 技术栈SCG 降低接入成本
已有 K8s 集群Ingress / Gateway API 是最低摩擦路径

维度四：性能边界

场景选型原理
高吞吐、低延迟优先L4/L7 混合架构（Envoy、HAProxy）
需要业务层聚合裁剪BFF 独立，不在网关上做
IoT 特殊协议专用协议网关，不强求统一网关

决策框架

协议兼容性 ───→ 是否需要多协议？    ↓治理复杂度 ───→ 策略变更频率？团队数量？    ↓组织约束 ───→ 现有技术栈？K8s 成熟度？    ↓性能边界 ───→ 延迟敏感度？吞吐量量级？

每一步回答后，下一步才进入，最终收敛到具体技术方案。

反模式与误区

核心原则

网关是策略中心，不是业务容器。网关是边界防线，不是唯一防线。

反模式 1：网关成为业务容器

表现：在网关上堆砌业务逻辑、复杂聚合、数据转换。

问题：网关复杂度爆炸；变更风险集中；成为单点瓶颈。

正确认知：将业务逻辑从网关移除；聚合仅限于数据组合；复杂业务下沉到独立服务。

原则：网关只做跨边界治理，业务逻辑留在服务层。

反模式 2：网关成为单点故障

表现：所有流量经过网关，但网关自身无高可用设计。

问题：网关宕机 = 全系统不可用；容量评估不足导致过载；缺乏熔断保护级联崩溃。

正确认知：多实例负载均衡、独立健康检查、自动故障转移、容量规划考虑网关瓶颈。

原则：网关是流量咽喉，必须比后端服务更稳定。

反模式 3：混淆 API 管理与 API 网关

表现：将 API 生命周期管理（发布、版本、文档）混入网关实现。

问题：网关职责膨胀；管理平面与数据平面混淆。

正确认知：API 网关是技术组件（数据平面），API 管理是平台能力（控制平面）。

原则：网关专注流量治理，API 管理独立建设。

反模式 4：忽视东西向流量治理

表现：只在南北向部署网关，内部服务调用无治理。

问题：服务间通信缺乏安全控制；内部故障无法追踪。

正确认知：南北向用 API 网关，东西向用 Service Mesh，定位不同，相辅相成。

原则：网关管入口，Mesh 管内部。

反模式 5：网关变更影响所有业务

表现：中心化网关的逻辑变更影响所有业务。

正确认知：网关演进路径：中心化 → 去中心化 → Mesh 化；大部分工作量在灰度、回滚、监控。

原则：网关变更必须可控、可回滚、可灰度。

反模式 6：滥用网关卸载

表现：将所有通用功能往网关上堆（包括业务相关逻辑）。

问题：网关膨胀、性能下降、业务逻辑与治理逻辑耦合。

正确认知：只卸载跨切面通用能力（SSL、Auth、限流），业务相关逻辑在服务层。

原则：卸载的是横切关注点，非业务逻辑。

误区 1：有了网关就不需要 Mesh

真相：网关处理南北向（可控），Mesh 处理东西向（解耦），定位不同，互补非替代。

原则：两者相辅相成，不是替代关系。

误区 2：网关延迟可以忽略

真相：额外跳转带来延迟，对高频交易场景影响显著。

原则：网关适合 API 治理，不适合高速交易链路。

误区 3：网关安全是唯一防线

真相：需要多层防御：网关（边界）+ 服务间认证（mTLS）+ 数据安全 + 应用层安全。

原则：纵深防御，网关是入口而非全部。

关联文档