核心功能解析：路由转发、负载均衡、认证鉴权、限流熔断
好，咱们今天来聊聊API网关的四大核心功能。说实话，这四块内容就像是网关的四肢和大脑，缺一不可。我在做网关选型的时候，经常看到一些团队只关注路由转发，结果上线后被流量打垮，或者被安全漏洞搞到焦头烂额。嗯，咱们一个一个来看。
一、路由转发：网关的“交通指挥员”
路由转发说白了，就是根据请求的特征，把它送到正确的后端服务去。我个人习惯把路由规则分成三类：
- 路径路由：根据URL路径匹配，比如
/api/users/*转到用户服务 - 域名路由：根据Host头匹配，比如
order.example.com转到订单服务 - 请求头路由：根据Header、Cookie等匹配，比如
X-Region: cn-east转到华东集群
你想想看，如果没有路由转发，客户端就得记住每个服务的具体地址。那微服务架构就变成“微服务灾难”了。
核心要点：路由转发要做到毫秒级匹配，支持动态更新。我曾经在项目中遇到路由规则变更需要重启网关的情况，那体验简直了——每次发布都提心吊胆。
这里给个简单的路由配置示例（以Kong为例）：
# 创建一个路由，匹配 /api/v2/orders 路径
curl -i -X POST http://localhost:8001/routes \
--data 'name=order-route' \
--data 'paths[]=/api/v2/orders' \
--data 'methods[]=GET' \
--data 'methods[]=POST'二、负载均衡：别让一台机器累死
负载均衡，说白了就是“把活分给兄弟们干”。我记得刚做网关那会儿，有个同事把所有流量都打到一台机器上，结果那台机器CPU飙到99%，其他机器闲得发慌。这就是典型的负载不均。
常见的负载均衡算法有这些：
| 算法 | 特点 | 适用场景 |
|---|---|---|
| 轮询 | 按顺序轮流分配 | 后端性能均匀 |
| 加权轮询 | 按权重分配 | 后端性能差异大 |
| 最少连接 | 分配给活跃连接最少的节点 | 长连接场景 |
| 一致性哈希 | 根据请求特征哈希分配 | 需要会话保持 |
我的经验：生产环境我一般用“最少连接+加权”的组合。为什么？因为后端服务的处理能力不可能完全一样，加权可以手动调优，最少连接能自动应对突发流量。
三、认证鉴权：把门看好了
认证是“你是谁”，鉴权是“你能干什么”。这两个概念我经常看到有人搞混。有一次面试，候选人说“我们用了JWT做鉴权”，我差点没忍住笑出来——JWT只是认证的一种方式啊兄弟。
常见的认证方式：
- JWT：无状态，适合分布式场景。但要注意JWT过期时间别设太长，我见过设7天的，那安全性...
- OAuth2：适合第三方授权场景，比如微信登录
- API Key：简单粗暴，适合内部服务
- Basic Auth：别用了，真的，明文传输密码太危险
鉴权的话，我建议用RBAC（基于角色的访问控制）。为什么？因为好管理。你想想看，如果每个用户单独配置权限，1000个用户就得配1000次，累不累？
避坑指南：我曾经在项目中遇到一个问题——认证通过了，但鉴权没通过，结果返回了401状态码。这是不对的！认证失败返回401，鉴权失败应该返回403。这个细节很多人会搞错。
四、限流熔断：保护你的系统不崩溃
限流和熔断，这两个经常被放在一起说，但其实是两回事。
限流是主动控制流量，防止系统被冲垮。常见的限流算法：
- 令牌桶：允许一定程度的突发流量，我比较推荐
- 漏桶：流量平滑，但响应可能变慢
- 滑动窗口：精确控制，但实现复杂一点
熔断是被动保护，当后端服务出问题时，快速切断流量，防止雪崩。说白了就是“别往火坑里跳”。
这里给个Sentinel的限流配置示例：
# 对 /api/orders 接口做限流，每秒最多100个请求
flow:
- resource: /api/orders
grade: 1 # QPS模式
count: 100
controlBehavior: 0 # 直接拒绝核心原则：限流要“快”，熔断要“准”。限流判断必须在毫秒级完成，熔断则要准确识别出真正的故障，别因为一次超时就熔断了——那叫“误伤”。
我记得有一次线上事故，某个服务响应变慢，熔断器连续触发三次后断开了。但问题是，熔断恢复时间设得太短，恢复后服务还没缓过来，又熔断了。这就形成了“熔断-恢复-再熔断”的死循环。后来我把熔断恢复时间改成了指数退避，问题才解决。
好了，这四大核心功能就聊到这儿。说白了，路由转发是基础，负载均衡是保障，认证鉴权是安全底线，限流熔断是最后一道防线。这四个功能配合好了，你的API网关才能扛得住生产环境的考验。