基础定位： API Gateway 是后端系统统一入口，核心分成两层：路由能力 + 治理能力。
- 路由转发：请求进来后首先要知道该去哪个服务 → 按 Path / Host / Method 等规则匹配目标服务并转发
- 动态路由 + 负载均衡：服务实例会动态增减，而且一个服务通常有多个实例 →
- 简单模式直接路由到 K8s Service，由 Service 完成实例发现和基础负载均衡；
- 如果需要按 IP、User ID、版本、权重等做更细的调度，再由 Gateway 接 K8s API / 注册中心，自己维护实例列表并做负载均衡
- 认证鉴权：所有请求都经过网关，适合统一判断身份和权限 → 解析 Token / JWT / Cookie，不合法直接拦截
- 统一观测：网关处在所有请求入口，最适合统一收集运行状态 → 记录 QPS、RT、状态码、错误率、超时率等指标
- 多层限流：不同层级承载能力不同，需要防止流量把系统打垮 → 全局限流 + 服务级限流 + 接口级限流 + 用户/IP级限流
- 熔断：某个下游已经明显不健康，继续请求只会进一步恶化 → 根据错误率、超时率、RT 等指标判断，异常时暂时停止转发，之后再少量试探恢复
- 降级：系统压力过高或部分服务异常时，要优先保核心业务 → 关闭非核心功能、降低流量、返回缓存/默认值/兜底结果
- 动态配置：路由、限流阈值、熔断策略经常需要调整 → 通过配置中心动态更新，不依赖重启 Gateway
- 高可用：Gateway 自己不能成为单点 → 多实例部署，前面再由 LB 分发流量
最后整条思路可以记成：
先解决“请求去哪” → 路由转发 → 动态实例发现 + 负载均衡；再解决“请求能不能去、系统怎么保护” → 认证、观测、限流、熔断、降级；最后补动态配置和 Gateway 自身高可用。