2、网关基础概念：网关的作用、网关在微服务中的位置、常见的网关模式（BFF、API Gateway）
好，咱们正式开始聊网关。说实话，很多刚接触微服务的同学，第一个困惑就是：我服务都拆好了，为什么还要加一个网关？ 这不是多了一层调用，反而变慢了吗？
嗯，这个问题我当年也问过。记得我第一次把单体拆成十几个微服务后，客户端直接懵了——它不知道该调哪个地址，每个服务还要单独处理认证、限流、日志……那叫一个乱。后来我才明白，网关不是累赘，而是微服务的“总开关”。
2.1 网关到底干了什么？
说白了，网关就是一个统一的入口。所有外部请求先打到网关，再由网关转发给后端的各个微服务。
它的核心作用，我归纳为四点：
- 路由转发：根据请求路径、Header、参数，把请求送到正确的服务。比如
/api/user/**转到用户服务，/api/order/**转到订单服务。 - 认证鉴权：在网关层统一校验 Token、API Key，不用每个服务都写一遍认证逻辑。我在项目里就吃过这个亏——每个服务自己搞认证，结果密钥管理乱成一锅粥。
- 限流熔断：防止某个突发流量把后端打垮。比如双十一大促，网关直接拦住 90% 的请求，保证核心交易链路不崩。
- 协议转换：比如外部用 HTTP，内部服务用 gRPC，网关可以帮你做转换。客户端不用关心后端用什么协议。
一句话总结：网关是微服务架构的“门卫+前台+调度员”。没有它，你的微服务就像一栋没有大门的写字楼——谁都能直接闯进各个办公室。
2.2 网关在微服务中的位置
你想想看，一个典型的微服务架构长什么样？
客户端（App、浏览器、IoT设备） → 网关 → 各个微服务（用户服务、订单服务、商品服务…） → 数据库、缓存、消息队列。
网关就夹在客户端和后端服务之间。它屏蔽了后端的复杂性，客户端只需要知道网关的地址，不用管背后有多少个服务、它们部署在哪里。
我个人习惯把网关放在反向代理层（比如 Nginx）之后。Nginx 负责最基础的负载均衡和 SSL 卸载，网关负责更精细的路由和业务逻辑。这样分层，各司其职，出了问题也好排查。
一个小建议：不要把网关和业务逻辑耦合太深。网关只做“通用”的事情——路由、认证、限流、日志。业务相关的校验、转换，尽量放在后端服务里。否则网关会变得越来越重，最后变成“单体网关”，又回到了老路上。
2.3 常见的网关模式
聊完位置，咱们看看网关有哪些“玩法”。实际项目中，我见过三种主流模式：
2.3.1 API Gateway（传统网关）
这是最经典的模式。一个网关，对接所有客户端。不管是 Web、iOS、Android，都走同一个入口。
优点：统一管理，简单直接。
缺点：所有客户端的需求都揉在一起，网关容易变得臃肿。比如 Web 端需要返回完整的 HTML 片段，而 App 端只需要 JSON 数据，网关就得同时支持两种输出。
我曾经在一个电商项目里用过这种模式。刚开始还好，后来业务方提了十几个定制化需求，网关代码越来越复杂，每次发布都提心吊胆。嗯，这就是“通用网关”的痛点。
2.3.2 BFF（Backend For Frontend）
BFF 模式，说白了就是为每种客户端单独建一个网关。
比如：
- Web BFF：负责给浏览器提供接口，返回 HTML 或 JSON。
- Mobile BFF：给 App 提供接口，数据格式更精简，减少流量。
- IoT BFF：给物联网设备提供接口，协议可能是 MQTT 或 CoAP。
每个 BFF 只关心自己对应的客户端，逻辑可以做得非常“专”。
为什么需要 BFF？ 你想想看，一个 App 的首页可能需要聚合 5 个服务的数据，而 Web 端只需要 3 个。如果共用同一个网关，网关就得写一堆条件判断——如果是 App 就调这 5 个，如果是 Web 就调那 3 个。时间一长，代码里全是 if clientType == "mobile"，维护起来想哭。
BFF 模式就把这个问题解决了。每个 BFF 只服务一种客户端，代码干净，职责单一。
注意：BFF 不是银弹。如果客户端类型太多（比如十几个），每个 BFF 都要重复实现认证、限流等基础功能，反而增加了运维成本。我建议：客户端类型超过 3 种时再考虑 BFF，否则传统 API Gateway 就够用了。
2.3.3 混合模式
实际项目中，我更多用的是混合模式：
- 一个核心网关，负责所有客户端的通用逻辑（认证、限流、路由）。
- 多个轻量级 BFF，负责客户端特定的聚合和转换逻辑。
核心网关把请求路由到对应的 BFF，BFF 再调用后端服务。这样既统一了基础能力，又保留了 BFF 的灵活性。
举个例子：
客户端 → 核心网关（认证+限流） → Web BFF → 用户服务、商品服务
→ Mobile BFF → 用户服务、订单服务、推荐服务核心网关只做“通用”的事，BFF 只做“定制”的事。各层职责清晰，出了问题也容易定位。
2.4 三种模式对比
| 模式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| API Gateway | 客户端类型少（1-2种） | 架构简单，运维成本低 | 网关容易臃肿，定制化能力弱 |
| BFF | 客户端类型多（3种以上） | 职责单一，灵活定制 | 运维成本高，重复实现基础功能 |
| 混合模式 | 大型项目，客户端类型多且需求差异大 | 兼顾统一管理和灵活性 | 架构复杂，需要更多设计 |
我的经验：刚开始做微服务时，别一上来就搞 BFF。先用一个简单的 API Gateway 跑起来，等发现网关代码里出现大量 if-else 判断客户端类型时，再考虑拆成 BFF。过早优化是万恶之源，这话在网关设计上同样适用。
2.5 避坑指南
最后，分享几个我踩过的坑：
- 不要把网关当成“万能胶”：我曾经见过一个团队，把业务逻辑、数据转换、甚至部分计算都塞进网关。结果网关成了新的“单体应用”，每次改需求都要动网关，发布风险极高。记住：网关只做“通用”的事。
- 注意网关的高可用：网关是流量的唯一入口，它挂了，整个系统就挂了。一定要做多实例部署，配合负载均衡。我习惯用 Kubernetes 部署网关，至少 2 个副本，加上健康检查和自动重启。
- 限流要早做：别等线上出问题了再补。我曾经在一个项目里，上线第一天就被爬虫打爆了——因为没有限流。从那以后，我每个网关项目的第一行代码就是加限流中间件。
好了，这一章我们聊了网关的基础概念。下一章，我会带大家动手搭建一个真实的 API Gateway，用 Ocelot 还是 YARP？到时候再细说。