/api/users 的 GET 请求路由到用户管理服务的特定接口。按接口/路径限流 针对不同API接口设置独立的限流阈值。例如:
/api/login 接口限制每秒100次请求。
/api/orders 接口限制每秒50次请求(因涉及数据库操作,需更严格限制)。
按用户/客户端IP限流 防止单个用户或IP发起过多请求。例如:
单个用户每分钟最多调用 /api/pay 接口10次。
单个IP每秒最多访问 /api/search 接口20次。
按服务/应用限流 对整个服务或租户进行全局流量控制。例如:
某第三方应用的API调用总量限制为每小时10,000次。
固定窗口计数器(Fixed Window Counter) 将时间划分为固定窗口(如1秒),统计窗口内的请求数。简单但可能出现临界问题(如窗口切换时瞬时流量激增)。 示例:1秒内最多允许100次请求,若第1秒最后10ms有90次请求,第2秒前10ms又有90次请求,则实际200次请求被放行。
滑动窗口日志(Sliding Window Log) 记录每个请求的时间戳,实时计算窗口内请求数。精确但内存消耗较大。 示例:维护一个时间窗口(如1秒),记录所有请求时间戳,超出阈值则拒绝。
令牌桶算法(Token Bucket) 以固定速率向桶中添加令牌,请求消耗令牌。允许突发流量(桶中有剩余令牌时)。 示例:桶容量100,每秒添加10个令牌,则允许瞬时100次请求,后续按10次/秒匀速处理。
漏桶算法(Leaky Bucket) 以固定速率处理请求,超出速率的请求排队或拒绝。流量平滑但无法应对突发需求。 示例:无论请求速率如何,均以5次/秒的速率处理。
/api/order 的限流阈值。/api/payment 错误率超过50%,则暂停该接口服务5分钟。# 示例:YAML格式的API限流配置
api:
/api/login:
rate_limit:
algorithm: "token_bucket" # 使用令牌桶算法
rate: 100 # 每秒生成100个令牌
capacity: 100 # 桶容量
/api/orders:
rate_limit:
algorithm: "fixed_window" # 固定窗口计数器
window_size: 1s # 时间窗口1秒
limit: 50 # 窗口内最多50次请求# 示例:Nginx配置IP限流(需云网关支持)
limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s; # 每秒20次请求
server {
location /api/ {
limit_req zone=perip burst=50 nodelay; # 突发流量允许50次,无延迟
}
}// 示例:全局限流配置(JSON格式)
{
"global_limit": {
"algorithm": "leaky_bucket",
"rate": 1000,
"burst": 2000
}
}/api/users 开头的请求转发到用户管理服务,以 /api/products 开头的请求转发到商品管理服务。这种配置方式简单直观,适用于大多数基于RESTful API的应用场景。api.example.com 的请求时,将其转发到特定的后端服务集群;而 admin.example.com 的请求则转发到管理后台服务。这种方式常用于多租户系统或需要对不同域名进行区分管理的场景。/api/products 的GET请求,可能转发到获取商品列表的服务;而POST请求则转发到创建新商品的服务。这有助于对不同类型的操作进行精细化的路由控制。/api/orders/{orderId} 的路由规则中,{orderId} 是一个参数,网关可以根据不同的 orderId 值将请求转发到不同的订单处理服务实例,或者根据订单的状态、类型等参数进行更细致的路由决策。内存缓存:每个网关节点内置内存缓存(如Redis、Guava Cache),存储高频访问的响应数据(如静态配置、热门API结果)。
特点:低延迟(微秒级响应),但数据仅在单个节点有效,需配合其他机制保证一致性。
共享缓存集群:通过Redis Cluster或Memcached实现跨节点缓存共享,确保所有网关节点访问同一份数据。
特点:解决本地缓存的数据一致性问题,适合共享数据(如全局配置、公共API结果)。
静态资源缓存:与CDN结合,将静态文件(如图片、CSS、JS)缓存到边缘节点,减少回源请求。
动态加速:对动态内容(如API响应)通过边缘节点预取或回源缓存,降低延迟。
唯一标识:基于请求的URL路径、查询参数、请求方法(GET/POST)、Headers(如Authorization)等生成唯一缓存键。
示例:/api/users?id=123&role=admin → 缓存键 users:123:admin。
固定TTL(Time-To-Live):为缓存设置固定的过期时间(如5分钟),到期自动失效。
动态TTL:根据业务需求动态调整TTL,例如热点数据延长缓存时间,冷数据缩短时间。
主动失效:当后端数据更新时,通过事件通知或版本号机制主动清除缓存(如发布新商品时清除商品详情缓存)。
写穿透(Write-Through):数据写入后端时同步更新缓存,保证强一致性,但可能增加写入延迟。
写回(Write-Behind):先更新缓存,异步批量写入后端,提升写入性能但存在短暂不一致风险。
失效优先(Cache Aside):读取时先查缓存,若未命中则回源后端并更新缓存;写入时直接操作后端并使缓存失效。
本地+分布式+CDN:优先从本地缓存读取,未命中则查询分布式缓存,最终回源到后端。
示例:用户请求 /api/products 时,先查网关内存缓存 → 未命中则查Redis → 仍未命中则调用商品服务。
启动预加载:网关启动时预先加载热点数据到缓存,避免冷启动性能问题。
定时刷新:通过定时任务定期刷新缓存(如每日凌晨更新商品列表缓存)。
互斥锁(Mutex):当缓存失效时,使用分布式锁(如Redis的SETNX)确保只有一个请求回源后端,其他请求等待结果。
永不过期策略:对关键数据设置逻辑过期时间(如标记过期时间但保留数据),后台异步更新。
随机TTL:为缓存设置随机的过期时间(如基础TTL±随机值),避免大量缓存同时失效。
多级降级:缓存失效时返回降级数据(如默认值或旧数据),保证服务可用性。
数据版本号:后端数据变更时递增版本号,网关缓存记录版本号,读取时校验版本一致性。
ETag/Last-Modified:通过HTTP头实现弱一致性校验,减少不必要的数据传输。
消息队列通知:后端数据变更时发布事件到消息队列(如Kafka),网关订阅并更新缓存。
数据库Binlog监听:通过解析数据库变更日志(如MySQL Binlog)实时同步缓存。
允许短暂不一致:对非关键数据采用最终一致性模型,优先保障性能。
人工干预机制:提供缓存手动刷新接口,供运维在异常时干预。
记录缓存命中/未命中次数,计算命中率(命中率=命中次数/总请求次数)。若命中率低于阈值(如80%),需优化缓存键或调整TTL。
监控缓存响应时间、内存占用、CPU消耗等指标,避免缓存成为性能瓶颈。
根据流量自动扩展缓存容量(如Redis Cluster节点扩容),确保高并发下的稳定性。
缓存商品详情和库存信息,设置动态TTL(如商品更新后5分钟失效),通过版本号保证一致性。
缓存用户时间线数据,采用写穿透策略确保新动态实时可见,配合多级缓存降低数据库压力。
对频繁调用的只读API(如天气查询、汇率转换)直接缓存响应结果,减少后端计算开销。