微服务架构中 API 网关的作用是什么？
简化版
API 网关是微服务系统对外流量的统一入口，负责路由转发、认证鉴权、限流、灰度、协议转换、日志监控等横切能力。它的价值是把公共入口逻辑从业务服务中抽出来，让后端服务专注业务。
详细版
API 网关常见职责包括：
- 统一入口：客户端只访问网关，不直接暴露内部服务。
- 路由转发：根据路径、Header、版本、租户等规则转发到目标服务。
- 认证鉴权：校验 Token、签名、权限、租户身份。
- 限流与熔断：保护后端服务，防止突发流量打垮系统。
- 灰度发布：按用户、比例、地域、版本把流量切到新服务。
- 协议适配：对外 HTTP，对内 RPC 或不同 HTTP 接口。
- 统一观测：记录访问日志、指标、TraceId。
网关不应该承载太多复杂业务逻辑，否则会变成新的“大单体”。业务判断应尽量留在业务服务，网关只做入口层通用能力。
完整版教学
一、为什么微服务需要网关
没有网关时，客户端要直接知道很多后端服务地址：
App -> 用户服务
App -> 商品服务
App -> 订单服务
App -> 支付服务这样会带来几个问题：客户端和后端拓扑强耦合；服务拆分或迁移会影响客户端；认证、限流、日志等逻辑要在每个服务重复做；内部服务地址暴露给外部也不安全。
网关把这些问题收口：
客户端 -> API 网关 -> 内部微服务客户端只关心统一入口，后端服务可以在内部演进。
二、网关的核心职责
网关首先是路由层。它根据请求路径、域名、Header、参数、用户身份等信息决定流量去哪里。例如：
/api/users/** -> user-service
/api/orders/** -> order-service
/api/pay/** -> payment-service其次是安全入口。网关可以统一校验 JWT、OAuth2 Token、签名、防重放、黑白名单，把非法请求挡在业务服务之前。
再次是流量治理。比如某个接口每秒最多 1000 次请求，超过后直接拒绝或降级，避免后端被冲垮。
最后是可观测入口。网关天然处在请求入口，适合生成或透传 TraceId，记录请求耗时、状态码、流量来源。
三、网关和负载均衡有什么区别
负载均衡更偏四层或七层流量分发，关注“把请求分给哪台机器”。API 网关更偏应用入口，关注“这个请求有没有权限、应该进哪个业务服务、是否命中灰度、是否需要限流”。
| 能力 | 负载均衡 | API 网关 |
|---|---|---|
| 主要目标 | 分摊流量 | 管理 API 入口 |
| 关注层次 | 网络/连接/实例 | 请求/用户/接口/版本 |
| 常见能力 | 轮询、权重、健康检查 | 鉴权、路由、限流、灰度、协议适配 |
| 是否理解业务 API | 通常较少 | 通常较多 |
实际系统里二者经常一起出现：外层 Nginx 或云负载均衡接公网流量，内层 API 网关做应用级治理。
四、网关不能做什么
网关最容易犯的错误是塞太多业务逻辑。
例如订单是否能取消、优惠券是否可用、用户是否满足风控条件，这些规则应由订单、营销、风控等业务服务判断。网关最多负责“这个用户有没有访问该接口的权限”，不应该负责“这笔订单在业务上能不能操作”。
如果把业务规则放进网关，会出现两个问题：
- 网关越来越胖，所有团队都要改网关。
- 业务规则分散在网关和服务里，排查和维护困难。
所以网关适合放横切能力，不适合放领域业务规则。
五、网关高可用设计要点
网关是入口，挂了影响面很大，所以要避免单点。
常见设计包括：多实例部署、前置负载均衡、无状态化、配置动态下发、限流规则灰度生效、关键路径降级、指标告警完善。
同时，网关自身也要控制复杂度。规则太多、插件太重、脚本动态执行太泛滥，都会让网关成为性能瓶颈或稳定性风险。
六、常见误区与追问
这道题要紧扣「API 网关」本身回答，不能把它混成泛泛的微服务架构套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖服务边界、通信方式、网关/BFF、数据归属、版本兼容和部署治理。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | API 网关是外部流量进入微服务体系的统一入口，承担路由、鉴权、限流、协议转换和观测等横切能力 | 不要停在名词解释 |
| 流程机制 | 客户端请求网关 -> 执行认证鉴权 -> 匹配路由规则 -> 限流和灰度 -> 转发后端服务 -> 记录日志指标 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | 网关可以统一给 100 个后端服务做 JWT 校验和限流，但不应把复杂业务编排都塞进网关 | 微服务提升团队自治和独立演进能力，但会带来分布式调用、数据一致性、依赖治理和运维复杂度 |
API 网关 面试拆解：
1. 客户端请求网关
2. 执行认证鉴权
3. 匹配路由规则
4. 限流和灰度
5. 转发后端服务
6. 记录日志指标记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「API 网关」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：API 网关就是 Nginx 反向代理。 网关还承担认证、限流、灰度、协议转换、观测和治理策略。
- 误区：所有业务逻辑都可以放网关。 网关应保持薄，复杂业务编排应放 BFF 或业务服务。
- 误区：网关单点问题不重要。 网关是入口关键路径，必须多副本、限流、熔断和降级。
- 追问：网关和 BFF 区别？ 网关偏通用入口治理，BFF 偏面向端的业务聚合。
- 追问：网关如何做高可用？ 多实例部署、负载均衡、无状态化、健康检查和配置灰度。
- 追问：网关容易成为瓶颈吗？ 会，所以要容量规划、连接池、异步 IO、限流和观测。
七、加强记忆
API 网关可以记成“微服务的大门口”：外部请求先到这里做身份检查、路线选择、流量控制和入口记录；但大门口不应该替每个业务部门做业务决策，否则网关会从入口层变成新的业务大单体。