API网关统一鉴权与流量控制配置实操

每个微服务自己写鉴权逻辑，每个接口自己加限流代码——这种做法在小团队还能凑合，服务一多就失控了。鉴权逻辑散落在各处，改一次要动十几个仓库。限流策略各写各的，有的服务根本没加。API网关存在的意义之一，就是把这些横切关注点统一收口。

统一鉴权怎么配

以JWT为例，网关层做鉴权的流程是：客户端请求带上Authorization头，网关拦截请求，提取token，验证签名和过期时间，通过后把用户信息注入请求头转发给后端服务。后端服务不需要再验token，直接从请求头里取用户信息就行。

具体配置上，建议把公开接口和需要鉴权的接口分开管理。用路由前缀区分，比如/public/开头的跳过鉴权，/api/开头的强制JWT验证。在APISIX里可以用consumer和plugin的配合来实现，Kong里对应的是JWT插件和ACL插件组合。

还有个实操建议：token的刷新机制一定要在网关层处理。检测到access token快过期了，网关自动用refresh token换新的，对后端透明。这样后端完全不用关心token过期的问题。

流量控制三个维度

限流不是设个QPS上限就完事了。合理的流量控制要分三个维度来做。

维度一：全局限流。保护整个系统不被打垮，设一个总QPS上限，比如10000。超过的请求直接返回429。这是兜底策略。

维度二：按API维度限流。核心接口（支付、下单）给高配额，非核心接口（日志上报、埋点）给低配额。避免一个低优接口把全局配额吃光。

维度三：按调用方限流。不同租户或不同客户端设不同的限流策略。VIP客户的API调用配额可以高10倍，免费试用版限制100次/分钟。这需要网关支持基于consumer的限流，APISIX和Kong都支持。

熔断方面，建议配置错误率阈值和慢请求阈值。连续错误率超过50%触发熔断，慢请求超过2秒计入异常。熔断后半开状态的恢复时间设10-30秒，给后端服务喘息的机会。别设太短，否则后端还没恢复就被又打挂了。