2、API网关核心概念解析：路由、过滤、限流、鉴权与日志
API网关这东西，说白了就是所有外部请求进入系统的「第一道门」。我在做内部开发者平台时，最常被问的一个问题就是：「网关到底干了啥？」
其实就五件事：路由、过滤、限流、鉴权、日志。这五个概念就像网关的五脏六腑，缺一个都会出问题。今天咱们一个一个掰开看。
2.1 路由（Routing）——请求该去哪
路由是网关最基础的能力。客户端访问网关，网关根据请求的路径、方法、头部等信息，把请求转发到后端的某个服务实例。
我习惯这么理解：路由就是一个「交通警察」。你看，每个请求都带着目的地（URL），网关根据这张「地图」（路由表），告诉它该走哪条路。
2.2 过滤（Filter / Interceptor）——请求的安检
过滤，就是请求经过网关时，被执行的一系列「安检」操作。比如修改请求头、校验签名、记录耗时、熔断降级等。
大部分网关（像Zuul、Spring Cloud Gateway、Kong）都支持过滤器链。你可以理解成一个管道，每个过滤器干自己的事，排队执行。我个人习惯把过滤器分为三类：
- 前置过滤器：请求转发到后端之前执行，比如鉴权、参数校验。
- 后置过滤器：后端返回响应后执行，比如打日志、修改响应头。
- 路由过滤器：在路由匹配和转发时执行，比如重写路径、限流。
2.3 限流（Rate Limiting）——别让流量冲垮你
限流是保护后端服务的最后一道防线。你想想看，如果突然有100万次请求涌进来，后端服务不直接被打挂了？
常见的限流算法有四种：令牌桶、漏桶、滑动窗口、计数器。我项目中用得最多的是令牌桶，因为能应对突发流量，而且实现简单。
| 算法 | 特点 | 适用场景 | 缺点 |
|---|---|---|---|
| 令牌桶 | 允许一定突发，平均限流 | 大多数API | 突发可能超出预期 |
| 漏桶 | 平滑输出，严格限流 | 数据库写入 | 无法处理突发 |
| 滑动窗口 | 精度高，内存友好 | 秒杀、抢票 | 时间片粒度不好调 |
| 计数器 | 最简单，内存最小 | 低并发场景 | 临界点拥塞 |
2.4 鉴权（Authentication & Authorization）——你是谁，能干什么
鉴权分为两个层面：认证（你是谁）和授权（你能做什么）。网关一般只做认证，授权丢给业务服务自己处理。
常见的认证方式有：
- JWT：无状态，适合微服务。我建议里只放用户ID和角色，不要放敏感信息。
- OAuth2 / OIDC：适合第三方接入，有授权码、密码等流程。
- ：简单，但不安全，适合内部服务间调用。
- Basic Auth：过时了，尽量别用。
嗯，这里要特别注意一点：绝不要在网关层做完整的权限校验。权限是业务逻辑，网关层只校验是否有效、角色是否匹配即可。细粒度的权限（比如查这个订单是不是自己的）交给业务服务，否则网关会变成性能瓶颈。
2.5 日志（Logging）——干了什么都要记
日志这东西，平时没人看，一但出问题就是救命稻草。网关日志需要记录什么？我个人习惯记录这几项：
- 请求ID：每个请求生成一个唯一ID，串联所有上下游日志。
- 客户端IP、User-Agent：用于溯源和安全分析。
- 请求方法、路径、参数：关键输入。
- 响应状态码、耗时：用来分析性能。
- 错误信息：有异常时要把堆栈或错误码记录下来。
我曾经遇到过线上某个接口突然变慢，查了半天找不到原因。最后靠网关日志发现，该接口平均耗时从50ms飙到了800ms，而失败率几乎为零。进一步查下去，原来是后端服务里某条SQL没走索引。你想想看，没有网关日志，这问题可能到被用户投诉都发现不了。
2.6 核心概念关系图
我把这五个概念画了一张图，方便你理解它们之间的关系：
2.7 总结：这五个概念如何协作
一个请求进入网关后，实际的处理流程通常是这样：
- 路由匹配：根据URL匹配到对应的后端服务配置。
- 前置过滤：执行鉴权、参数校验、请求头改写等操作。
- 限流检查：判断是否超出限流阈值，超出则直接返回429。
- 转发请求：把请求发送到后端服务。
- 后置过滤：处理响应、记录日志、添加审计信息。
- 响应返回：把最终结果返回给客户端。
你看，这五个概念是串在一起的。你如果在项目里自己实现一个简易网关，记住这个顺序准没错。