🎯为什么需要网关
没有网关时，客户端要直连几十个服务，每个服务都得自己做认证、限流、监控——重复、难维护、不安全。
一句话：网关是系统的门面 + 通用能力的沉淀点。客户端解耦于具体服务，服务也无需关心"谁来调用、是否合法"。
🧩核心职责（7 项）
① 路由（Routing）
按 URL/Header/路径，把请求转发到对应微服务（如
/api/order/* → 订单服务）。② 负载均衡
在网关层对下游服务做轮询/权重/一致性哈希等均衡，配合服务发现。
③ 认证鉴权
统一校验 Token/签名，把"是否合法"挡在网关，业务服务只管逻辑。
④ 限流熔断
保护后端不被打垮（见 resilience/rate-limiting）。第一道防线。
⑤ 协议转换
外部 HTTP/gRPC、内部可能 Dubbo/Thrift，网关做转换与聚合。
⑥ 日志/监控/链路追踪
统一埋点、生成 TraceID，便于全链路排查。
⑦ 灰度/金丝雀
按规则把部分流量导到新版本，支持平滑发布。
🏗️位置与请求生命周期
接入：客户端请求到达网关（通常前置 LB/SLB）。
预处理：认证、限流、日志、染色（加 TraceID）。
路由：查路由表 + 服务发现，定位目标实例。
转发：负载均衡选一个实例，协议转换后发出。
响应：聚合/转换响应，统一返回客户端，并记录指标。
关键点：网关应尽量薄——只做"横切关注点"，不写业务逻辑，否则会变成新的单体瓶颈。
🔀路由与负载均衡
| 策略 | 说明 | 适用 |
|---|---|---|
| 轮询 | 依次分发 | 实例均等 |
| 加权轮询 | 按机器性能分配权重 | 异构机器 |
| 一致性哈希 | 同 key 落同实例 | 有状态/缓存亲和 |
| 最少连接 | 发给最空闲实例 | 长连接/耗时不均 |
易错点：网关的负载均衡要与"服务发现"动态联动，否则实例上下线后路由表过期，会打到已下线的机器。
⚖️网关 vs 负载均衡 vs Service Mesh
| 组件 | 视角 | 关注点 |
|---|---|---|
| 负载均衡(LB) | 网络层 | 把流量分到多个实例，偏"连接级" |
| API 网关 | 应用层 | 路由/认证/限流/聚合，偏"API 级" |
| Service Mesh | 服务间 | sidecar 接管服务间通信、mTLS、细粒度治理 |
关系：LB 管"南北向入口分发"，网关管"南北向 API 治理"，Mesh 管"东西向服务间通信"。三者互补，不是替代。网关可基于 Mesh 的 sidecar 能力实现，也可独立部署（Spring Cloud Gateway、Kong、APISIX）。
🎯面试要点速记
定位：统一入口 + 通用能力沉淀（路由/鉴权/限流/日志/灰度）。
价值：客户端解耦服务；服务不用重复写横切逻辑。
职责：路由、负载均衡、认证、限流熔断、协议转换、监控、灰度。
请求生命周期：接入→预处理→路由→转发→响应。
要薄：只做横切，不写业务，避免成新瓶颈。
对比：LB(网络分发) / 网关(API治理) / Mesh(服务间)；三者互补。
必考题："网关和 Service Mesh 的区别？"——网关管南北向（外部→内部）的 API 治理；Mesh 管东西向（服务→服务）的通信治理。网关是"门"，Mesh 是"内部血管网"。