网关

概述

网关（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）
仅 HTTP L4/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）+ 数据安全 + 应用层安全。

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

关联文档