API网关核心架构：代理、负载均衡、限流、认证授权

谈到API网关的核心架构，我得先说说一个常见的误区：很多刚入门的朋友以为API网关就是个路由器，把请求转发到后端就完事了。其实，真正的难点在于——四个核心功能怎么有机地组合在一起。如果拆开来单独实现，每个都很简单，但把它们集成得高效又稳定，这里面可有不少门道。

代理模式

代理是API网关最基础的能力。说白了，就是前端请求和后端服务之间的一个中间层。我个人习惯把代理分为两种模式：正向代理和反向代理。在API网关场景下，我们讨论的几乎都是反向代理。

我记得在早期的一个项目中，后端用的是古老的XML-RPC协议，前端要统一走RESTful接口。如果没有网关做协议转换，每个前端团队都要自己去实现XML-RPC的解析器，想想就头疼。

这里有一个避坑指南：我曾经在配置代理路径重写时，把正则写错了，结果所有带有参数的GET请求都被转发到了错误的端点。调试了整整一个下午，才发现是路径匹配的优先级出了问题。所以，路径匹配规则一定要先写精确匹配，再写模糊匹配，这个顺序很重要。

负载均衡

负载均衡解决了什么问题？一句话：后端服务扛不住的时候怎么办。

常见的负载均衡算法，我在生产环境中基本都踩过坑，直接给你看一个对比表：

算法	适用场景	我踩过的坑
轮询(Round Robin)	后端实例配置相同，请求处理时间相近	某个慢节点会拖慢整体
最少连接(Least Connections)	长连接服务，请求处理时间差异大	短连接场景下频繁统计，性能损耗
IP哈希(IP Hash)	需要会话粘滞的场景	客户端通过NAT访问时，哈希效果失效
加权轮询(Weighted Round Robin)	后端实例配置不均匀	权重计算不当导致流量倾斜

你想想看，假设你有三台后端实例，其中一台是新扩容的，CPU性能比另外两台高一倍。如果还用普通的轮询，新机器就白浪费了。加权轮询这时候就派上用场了。

限流策略

限流，是API网关里最容易引发线上故障的功能——没有之一。

为什么这么说？因为我遇到过太多次因为限流阈值设置不合理导致的误杀事故。

常见的限流算法有三种，它们的优劣很明显：

• 令牌桶( Bucket)：可以应对突发的流量峰值，但实现稍复杂。我比较推荐这个。
• 漏桶(Leaky Bucket)：流量整形能力强，适合保护下游系统，但不够灵活。
• 滑动窗口(Sliding Window)：统计精度高，但内存开销大，分布式场景下不好做。

限流的阈值设置，建议从业务指标反推。比如，你的后端服务最大能承受2000 QPS，你可以试试：网关层先限制在1500 QPS，保留一些缓冲。

认证与授权

认证和授权，我习惯把它们分开来看：

• 认证(Authentication)：你是谁？——校验身份
• 授权(Authorization)：你能做什么？——校验权限

在API网关层做认证，常见的方式有几种：

认证方式	安全性	适用场景
Basic Auth	低	内部服务调用，配合HTTPS使用
	中	第三方开放API
JWT	高	分布式微服务架构
OAuth 2.0	高	第三方授权登录

我记得有一次，团队把JWT的签名密钥硬编码在配置文件中，结果被一位离职员工泄露了。从那天起，我坚持用专门的密钥管理服务，比如Vault或者云厂商的KMS，绝不把密钥放在配置文件里。

授权方面，细粒度的RBAC（基于角色的访问控制）是我比较推崇的方式。举个例子：

# 权限模型示例
role: admin
  - permission: api:/v1/users:GET
  - permission: api:/v1/users:POST
  - permission: api:/v1/users:DELETE

role: viewer
  - permission: api:/v1/users:GET

在API网关层做RBAC，重点在于权限缓存的更新机制。我建议不要每次请求都查一次数据库，那样性能太差了。可以用本地缓存配合Redis，缓存失效时间控制在5-10分钟。