从「多入口」到「统一入口 + 流量调度中心」
要理解网关，先看它解决什么问题：微服务拆多了，客户端要面对一堆服务地址、一堆认证和限流逻辑，维护和安全都难。网关就是放在最前面的统一入口和调度层——所有请求先到网关，再由网关转发到具体服务。下面按「架构位置 → 核心能力 → 为什么需要 → 常见实现 → 总结」用总分总的方式讲清。
一、网关在系统架构中的位置
先说一句：网关 = 内网与外网的桥梁
在更广义的理解里，网关本身就是内网和外网之间的桥梁：内网设备通过网关才能访问外网，外网要访问内网或内网要对外暴露服务，也经过网关。网关可以同时做两件事：
- 让内网访问外网：内网主机把「默认网关」设为网关设备（如家庭里的路由器），所有访问互联网的流量先发到网关，再由网关转发出去。
- 对外网流量做过滤、拦截：网关可以对进出的流量做防火墙策略——放行、限速、拦截恶意 IP、过滤敏感请求等，保护内网安全。
家庭网络就是典型例子：家里多台设备在内网（如 192.168.1.x），路由器通常就是网关（常见管理地址 192.168.1.1）。你上网时，流量先到路由器，再由它转发到运营商、再进互联网；路由器也可以做家长控制、访问限制等，本质上就是「流量过滤、拦截」。下文说的 API 网关，是在微服务/系统架构里的一种网关，负责「客户端（外）与后端服务（内）」之间的入口与调度，和「内网通过网关访外网、网关做防火墙」是同一类「内外桥梁」思路在不同场景的体现。
系统架构中的网关：单体 vs 微服务
单体时代：客户端直接访问一台服务器，路径简单：Browser → Server → Database。
微服务时代：系统拆成用户服务、订单服务、支付服务、商品服务等。若客户端直连每个服务，会变成：
- Browser → 用户服务
- Browser → 订单服务
- Browser → 支付服务
- …
带来的问题：
| 问题 | 说明 |
|---|---|
| 服务地址暴露 | 所有服务域名/端口对前端或外部可见，难以收敛与变更 |
| 客户端臃肿 | 要配很多 API 地址、不同环境的差异全在客户端 |
| 认证重复 | 每个服务都要做 Token/JWT 校验，逻辑重复、易不一致 |
| 难以统一管理 | 限流、日志、监控分散，没有统一管控点 |
于是在客户端与后端服务之间加一层网关（Gateway）：
Browser → API Gateway → 用户服务 / 订单服务 / 支付服务 / 商品服务
客户端只认一个入口（如 https://api.example.com），由网关按规则把请求转发到对应服务。可以类比：网关 = 城市大门 + 安检 + 交通调度，所有「进城」的请求都先经过这里。
二、网关的核心能力
网关不只是「转发」，它通常承担系统的基础设施能力，可理解为「系统入口 + 请求调度中心」。
1. 统一入口
所有请求先进网关，再按路径等规则分发，例如：
/api/user/*→ 用户服务/api/order/*→ 订单服务/api/pay/*→ 支付服务
好处：客户端只记一个域名；服务地址不暴露；结构清晰。
2. 路由转发
按路径、域名、Header 等规则把请求转到不同服务，类似快递分拣：包裹先到分拣中心，再按目的地分发。
3. 身份认证与权限控制
在大系统里，认证往往收口到网关：Token 校验、JWT 验证、OAuth 等。请求先经网关验签，合法则转发，非法则直接 401，各业务服务不必重复写鉴权。
4. 限流与防护
为防止被恶意或突发流量打满，网关做限流（如每秒最多 1000 请求），常用令牌桶、漏桶等算法，应对爬虫、DDoS、流量尖刺。
5. 日志与监控
作为全流量入口，网关适合做统一日志：谁访问、什么路径、耗时、是否失败，用于性能监控、排障和用户行为分析。
6. 协议转换
客户端与后端协议不一致时（如前端 HTTP/REST，后端 gRPC），可在网关做协议转换，对前端透明。
7. 灰度发布与流量分配
发布新版本时，网关可按比例分配流量（如 10% 走新版本、90% 走旧版本），实现灰度发布（Canary），降低上线风险。
三、为什么微服务一定需要网关
服务数量到几十、上百时，若没有网关：
- 客户端要维护大量服务地址，复杂度高；
- 认证、限流、监控分散，安全与可观测性差；
- 任何服务地址或路由变更都要推给客户端，维护成本大。
有网关后：Client → Gateway → Services，客户端只访问一个入口（如 api.example.com），复杂逻辑集中在网关。因此几乎所有大型互联网系统都会在微服务前加一层网关。
四、常见的网关实现
1. Nginx
Nginx 是很多系统的第一层入口，做反向代理、负载均衡、限流、HTTPS。不少公司直接用 Nginx 当网关，或 Nginx 前置、后面再接专业 API 网关。
2. 专业 API 网关
在微服务架构中常用专用 API 网关，例如：
- Kong、APISIX：开源，插件丰富，动态路由、认证、限流、监控
- Spring Cloud Gateway：与 Java/Spring 生态集成
- AWS API Gateway：云上托管，与 AWS 服务打通
这类产品通常提供插件体系、动态路由、统一认证、限流与监控能力。
3. BFF（Backend For Frontend）
BFF 是一种「为前端定制的网关」：不同客户端（Web、App）用不同的 BFF 聚合接口、做数据裁剪，减少前端请求次数、简化前端逻辑。架构上可看作：Browser → Web BFF / Mobile BFF → 各微服务。
五、总结
说白了就四条：
- 网关是什么：系统的统一入口 + 请求调度中心，所有请求先经网关再进具体服务；可类比「城市大门 + 安检 + 交通调度」。
- 核心能力：统一入口、路由转发、认证鉴权、限流防护、日志监控、协议转换、灰度/流量分配，把跨服务的公共能力收口到一层。
- 为什么需要：微服务多了以后，没有网关则地址暴露、认证重复、难以限流与监控；有网关则客户端只认一个入口，复杂度与风险集中在网关，便于运维与安全。
- 常见实现：Nginx 做反向代理与负载均衡；Kong/APISIX/Spring Cloud Gateway 等做专业 API 网关；BFF 为前端做聚合与裁剪。整体链路可简化为：客户端 → 网关 → 微服务 → 数据库，网关已成为微服务架构里不可缺少的一层基础设施。