4.5 API 网关与微服务中的 REST
4.5 API 网关与微服务架构中的 REST
本节摘要：网关是所有入口请求的"调度台"——统一认证、限流、聚合、路由、协议转换，让下游各服务的 REST 接口对外呈现一个整洁门面。本节用一张网关在微服务中的位置图，讲清网关的职责、为"对外统一对外 REST、对内服务自治"，再用一次多服务聚合演练理解网关如何遮住后端的复杂度。
学习目标
阅读完本节，你应当能够：
- 说出 API 网关的典型职责：路由、认证、限流、聚合、协议转换。
- 解释网关如何让外部客户端只看到一个门面，看不到下游服务的四分五裂。
- 辨析"内部 REST 自治"与"对外统一 REST 契约"的分工。
- 权衡网关是"入口穿透所有请求"还是"只放必要请求"。
微服务架起来，门面却碎了一地
当你把单体拆成订单服务、用户服务、商品服务，每个服务各自有一套 REST 接口。从外部客户端看，它要记住 N 个服务的地址、N 种认证、N 份错误格式——门面碎了一地。API 网关就是那个把所有入口请求接进来、集中处理、再分发给下游的"调度台"。
二、一张图看网关站在哪
图：API 网关在微服务架构中的位置
三、网关六职责：调度台管什么
把网关的活儿落到可执行清单：
- 路由分发：按路径把请求派给对应下游服务。
- 统一认证：外部先过一遍认证与令牌校验，下游不必各做一套。
- 限流熔断：控制入口吞吐，超阈值熔断，防下游被打爆。
- 响应聚合：一个页面对应多个服务，网关把多次调用聚合成一次对外响应。
- 协议转换：对外是 REST/JSON，对 RPC 型下游转换成内部协议。
- 指标监控：入口统一采集流量、延迟、错误，服务治理有第一手数据。
其中最容易理解偏的是"做什么生效"：治理横切（认证、限流、熔断、监控）在网关做，几乎是共识，因为它们在每条入口请求上都该有；业务编排（把订单、商品、库存拼成一个页面）则要看价值——高频且稳定才值得在网关聚合，否则塞进网关就是给所有请求背上一个重担。这条边界后面练习里再验证。
四、一次多服务聚合演练
背景：商品详情页需要用户信息 + 商品信息 + 库存。若客户端直接打三个服务各取一段，又慢又要跨源。
操作：网关暴露一个 GET /productpage/{id}，内部去订单服务、商品服务、库存各取所需，聚合成一份对外 JSON 返回。
结果：客户端一次请求拿到全部，页面的"一次调用成型"体验顺滑；同时，限流、认证、监控在网关这一层统一做了，下游三个服务保持各自自治的简单接口。
解读：网关把"纵向的业务编排"和"横向的治理横切"同时收进来，对外呈现一个整洁的罗盘，对内让每个服务只管自己那摊，这正是"对外统一 REST、对内服务自治"的分工要义。
从契约角度看，这份聚合响应本身就是一份新契约：它对客户端是"一个 /productpage/{id} 资源"，对内部却可能是三次子调用。设计时要让网关的对外 schema 稳定、内部服务契约各自独立——对外改动要升网关层的版本，对内服务改字段不惊动客户端。网关因此既是一个调度台，也是契约边界的一道翻译岗。
变式：若这里改成网关每次都在那绕一圈、重复聚合热点页面，反而会成瓶颈，可以把高频聚合结果在网关层做短期缓存，或下沉成一门专用聚合服务。
网关还会牵出一条常被忽视的边界：熔断与重试的位置。入口流量惊险，如果对下游的每个失败请求都在网关疯狂重试，下游没崩也被重试打崩；正确做法是结合第 3.3 节的状态码语义——对 4xx（客户端问题）绝不重试，对 5xx 才带退避重试，并有熔断阈值挡住"下游已经快挂了还继续往里塞"。这些治理开关放在网关统一配，能大幅压低"连锁雪崩"的概率。调度台不只在"接线"，还在"刹闸"——这是网关作为横向治理枢纽，比单纯的路由转发更深的一层价值。
五、不是所有系统都需要网关
把网关吹上天之前，先问一句：你这个体量撑不撑得起一个网关。网关本质是"一个集中的单点"，进了网关，全站流量都要经过它——一旦它挂、它慢，整个门面跟着塌一半。所以要不要网关，取决于你有没有"非集中不可"的理由：
- 服务确实很多、很碎：三五个服务的单体微服务可以先不加网关，客户端直连，减少一层；
- 有跨服务的横切需求：JWT 要在所有服务前先验一遍、要在入口统一限流，才值得把它们收进网关；
- 你只有对内 API、没有第三方调用：往往内网直连 + 各服务自管认证够用，网关带来的是多余一跳。
判断的法子是列出"认证、限流、聚合、监控"四类需求，如果你在每一类都能找到一个必须集中的硬理由，上网关才划算；一样都找不到，就别让网关成为"多一层故障面"。这与你是否用了微服务本身无关——很多系统工程上简化后，发现把同类逻辑留在各服务里反而更干净。网关是治理工具，不是虚荣标志。
真到了要上网关的时候，市面上无非两大方向：把网关做成一个独立部署、集中治理的层，还是把网关能力以注入式库（sidecar）的方式并进每个服务。前者是你最熟悉的"一台机器管所有入口"的形态，集中好管但单点风险在前；后者（如服务网格）把限流、熔断、观测做进每个服务旁边，失却中央单点，但引入 sidecar 的部署与开销复杂度。小规模团队往往先走集中网关，等真到了大规模多团队共享、想彻底去掉单点故障时才考虑服务网格。网关没有"唯一正确答案"，只有"贴合当前治理压力的那一个"。
⚠️ 常见坑：让网关变成"万能转发 + 透传一切"，结果每加一个能力都往网关里塞一层，拖着整条入口性能。职责要做分层：治理横切（认证、限流、熔断、监控）放网关，业务编排视聚合价值决定放网关还是放服务。
💡 关键直觉：网关的意义是"把后端的四分五裂折叠成对外的一个门面"。治理该在网关集中、业务该在下游自治——想清楚这条边界，网关就成了调度台而非泥潭。
本节要点回顾
- 要点一：网关让外部只认一个统一入口，内部服务各自自治。
- 要点二：典型职责包路由、认证、限流熔断、聚合、协议转换、监控。
- 要点三：多服务聚合把 N 次调用折叠成一次对外响应。
- 要点四：治理横切放网关，业务编排视价值决定位置。
- 要点五：避免网关变成万能透传的瓶颈与泥潭。
- 要点六：对外统一 REST、对内服务自治，是微服务门面的分工要义。
调度台接好线，最后一道关卡是给浏览器签一张跨域通行证——CORS 配置的谱系与实例见下节。